Hübsch - ich wüsste nur noch nicht, was ich damit anfangen sollte. hab ich mir mal abgespeichert für alle Fälle.
Natürlich kann man auch Bookmarks im Browser nutzen, das integriert sich aber nicht so schön in die Oberfläche.
Falls man übrigens das Kontextmenü des Browser öffnen möchte (z.B. für die Tile-URL), kann man die Shift-Taste beim Rechtsklick gedrückt halten.
Ich meinte das “Angeberthread” begeistert - ich finde, ihr baut mit Leaflet super Sachen! Ich guck da total gerne zu.
…und wollte einmal mit GIS-Wissen angeben. Hat nicht geklappt. :(
Kam bei mir total anders rüber - nun denn, das ist ja geklärt 
Nutzt du den GeoServer aktiv? Nur für den Fall, dass ich mal eine Frage haben sollte. Die Mailing Liste vom GeoSserver ist echt lahm, kein Vergleich mit dem Forum.
Gruss
walter
ps: mein Problemchen mit Font und Halo ist geklärt, wie man hier im “Contours”-Overlay sehen kann.
Ursache: Die Beispiele in der Doku waren falsch
Hallo cziher, Leaflet mit Overpass-Api?
Nicht unbedingt. Ich habe alle OSM-Daten in einer lokalen PostgreSQL/PostGIS-Datenbank und es gibt viele Methoden, die von da auf den Bildschirm zu “zaubern”. Der GeoServer ist halt derzeit das mMn modernste Tool dafür. Du dagegen brauchst deine Daten nur irgendwie mit Geookordinaten auf deinem Server zu halten und dann geht das schon - irgendwie.
Ja, bei den wenigen Location-Abfragen sollte das schon ok sein.
Stimmt, Leaflet ist wesentlich einfacher.
Mein Beispiel ist keine Lösung - das ist eine Experimentierbude 
Einer meiner offenene Wünsche wäre da eine Baumstruktur im Layerswitcher (EIN Button für Emergency, dann klappen 10 Unterpunkte für Hydranten, Feuerwachen, Rettungspunkte, … auf, EIN Button für Stadtmöbel und dann …)) das wird aber noch dauern.
wie ich schon oben schrieb: Die Daten können überall her kommen. Im Extremfall aus einer einfachen ASCII-Datei oder aus einem CSV mit einem Datum pro Zeile. Von der konkreten “Habe-keine-Datenbank-und brauch-auch-keine”-Lösung hab ich leider keine Ahnung. Ich bin mir aber 100%-ig sicher, dass auch das mit Leaflet geht.
Kein Problem, in OL oder auch Leaflet mehrere Basis-Layer auswählbar zu machen.
Tla, wenn du ein eigenes Layout haben willst, dann musst du rendern. Und dann hast du auch eine PostGIS-DB.
ich würde erstmal klein anfangen mit lokalen Daten und externen Layern. Dann kannst du irgendwann deinen eigenen Layer-Server (Renderer) aufsetzten und dann könntest du auch die Overlay-Daten aus der DB lutschen.
geschätzter Aufwand ohne Rendern 1-2 Monate, mit: das doppelte - wenn nicht sogar mehr.
gruss
walter
Bevor ihr einen eigenen Server für das OpenTopoMap-Rendering mit höheren Zoomleveln aufsetzt, könntet ihr auch mal mit dem Entwickler der OpenTopoMap sprechen. Vielleicht könntet ihr ihn unterstützen und dafür dann die Tiles zur freien Verfügung bekommen. Das dürfte wesentlich günstiger sein und würde bei der Entwicklung dieser tollen Karte helfen.
Es geht nicht nur um die Zoomstufe, sondern auch um fehlende Hausnummern. Und er ist bei einer freiwilligen Feuerwehr. Da macht er das Ganze schon ehrenamtlich.
Das ist aber ein grundsätzliches “Problem”, wenn man OSM nutzen möchte. Die Hausnummern werden auf jeder Karte fehlen.
Klar. Aber im Gespräch war das ggf. eigene Rendern von z18 und z19, diverse Layer etc. Das könnte man auf eine einfache Seite mit Leaflet mit minimalem Backend für die Layer (Hydranten und Co.) reduzieren, wenn man die OpenTopoMap unterstützt (notwendig wären ja vermutlich nur ein etwas leistungsstärkerer Server und ggf. Bandbreite). Ich rede hier nicht von ein paar hundert Euro im Monat, sondern eher das Finden von weiteren Sponsoren und ein paar Euro monatlich bzw. die Finanzierung eines ausreichenden Servers.
Wie viele Feuerwehren nutzen OSM? Wie viele betreiben einen eigenen Server und pflegen ihn? Wie viele hätten gerne die OpenTopoMap in höheren Zoomleveln? Wenn man keine Offline-Lösung braucht, könnte man hier gut zusammenarbeiten.
Da haben einige Feuerwehren schon ihre Jugend losgeschickt und ein paar Wochen später waren die Hausnummern in OSM komplett. Die freuen sich normalerweise, wenn sie irgendwas tun dürfen, was den “Großen” wirklich hilft.
Die OpenTopoMap hat in den vorhandenen Zoomstufen gar keine Hausnummern.
Baßtölpel
Für was genau wird der Aufwand eines eigenen (Offline-)Servers betrieben? Nur um die Hydranten und Rettungspunkte darzustellen? Wennja, käme man da nicht auch mit klassischen Karten an der Wand zu einem ähnlichen Ergebnis?
Gruß Klaus
Kein Problem:
- Hausnummern in OSM sauber erfassen - denn ohne die geht es halt nicht.
- Basismap auswählen, der einem einigermassen gut gefällt.
- Overlay aus den Adressdaten erstellen, der die Hausnummern/Adressen so darstellt, wie die Feuerwehr sie braucht. Also auch bei kleineren Zoom-Leveln als Mapnik sie anzeigt.
Nix rendern, nix eigener Tile-Server, “nur” ein Overlay-Server. Und da käme bei mir wieder der GeoServer ins Spiel. Oder auch der Qgis-Server oder der gute alte Mapserver. Aber mit lokalen Daten geht das auch relativ einfach, gerade weil es sich um ein begrenztes Gebiet handelt.
Selbst ein Popup bei Hover ist einfach machbar.
Gruss
walter
Das System hat er an anderer Stelle bereits ausführlicher beschrieben. Zu jeder Arlarmmeldung die reinkommt wird ein Kartenausschnitt erzeugt mit den dann notwendigen Informationen. Die Meldungen kommen offenbar elektronisch so das die Kamaraden dann die Beschreibung nebst Karte zusammen aus dem Drucker holen und losfahren und vor Ort die aktuelle OSM Karte mit den Hydranten haben.
Ein Plan an der Wand hilft nur der Einsatzleitung oder hängt im Feuerwehrhaus.
Hui, da sind ja schon ganz schön viele Antworten zusammen gekommen. Ich beantworte mal nacheinander:
Da war ich mir nicht so sicher ob ich da nicht den Rahmen sprenge. Wenn ich mal grob geschätzt 500 Hydranten habe und jedes Mal wenn jemand die Karte aufruft oder neu lädt wird eine Abfrage gestellt dauert das ja wahrscheinlich jedes Mal einige Zeit und ich belaste den Overpass-Api-Server nicht unerheblich, oder? Na ja, ich glaube aber es geht mittlerweile doch wieder zum eigenen Server. Siehe unten. Trotzdem Danke für die Antwort!
Werden so ca. 2 bis 5 pro Woche sein. Da mach ich mir auch keine Gedanken drum. Nominatim wird bei einer Alarmierung nur einmalig abgefragt. Der Kartenserver wird hingegen öfters befragt.
Na ja es gibt auf dem Server der dann genutzt werden soll sowieso schon ein paar MySQL-Datenbanken. Aber MySQL ist halt für GIS-Sachen eher unbrauchbar wie ich mir angelesen habe. Ich wollte halt wegen ein paar hundert Hydranten nicht extra ne PostGIS-DB haben.
Momentan betreibe ich ja schon einen Tile-Server unter Ubuntu 12.04 mit libapache2-mod-tile und Mapnik. Ich wollte halt nur versuchen das etwas zu verschlanken. Die Installation ist nicht das Problem, mir gehts eher darum mich nicht um die Wartung kümmern zu müssen wenn das Ding mal läuft.
Äh - also als ich vor ca. 3 Jahren meinen jetzigen Tile-Server installiert habe war die Grundinstallation an einem Abend erledigt und alles andere (einmal wöchentlich Daten-Update per Cronjob, Style-Anpassungen, Nominatim installieren) ein paar Tage später auch. Den Open-Topo-Map-Stil gibts ja bei Github, und den auf die höheren Zoomlevel erweitern kann ja jetzt nicht so das Hexenwerk sein, genauso wie die Hausnummern. Höchstens die UTM-Ref-Geschichte könnte etwas in Arbeit ausarten. Und Rendern will ich ja nur einen Landkreis, und auf den höheren Zoomleveln eigentlich nur meine Gemeinde (und bei Bedarf dann durch renderd ergänzen).
Korrekt. Wir sind schon froh um jeden Euro den wir so irgendwie kriegen. Privat habe ich sowieso einen vServer mit 6 GB Ram und ca. 400 GB ungenutzer Festplattenkapazität, das dürfte selbst für einen kompletten Landkreis in Z19 ausreichen denke ich.
Die Hausnummern gibt es schon, die habe ich (und zahlreiche andere Sachen) in wochenlanger Arbeit zusammengetragen. In der Mapnik-Karte werden die ja auch angezeigt. Nur halt in dem OpenTopoMap-Stil nicht standardmäßig.
Ursprünglich sollte der Server komplett offline funktionieren, damit auch bei einem Internet-Ausfall alle Dienste weiterhin funktionieren. Im Alarmfall werden die Daten von der Leitstelle als Fax empfangen, per Texterkennung ausgelesen und in eine MySQL-Datenbank geschrieben. Aus der Adresse wird durch Nominatim ein Koordinatenpaar erzeugt und dieses ebenfalls in die MySQL-Datenbank geschrieben. Dann werden die Einsatzdaten schön zusammengefasst ausgedruckt, inklusive einer Karte die die Anfahrt und die umliegenden Hydranten an der Einsatzstelle zeigt. Außerdem werden diese Informationen auf einem großen Bildschirm angezeigt.
Da es bisher aber zu keinem Internet-Ausfall kam (und ich vermute wenn wird das Fax auch nicht ankommen - selbst bei der Telekom geht ja mittlerweile alles über VOIP) denke ich dass eine ordentliche Aufbereitung für mobile Geräte mit einer anständigen Internetanbindung auf einem echten Server (und nicht etwa DSL 6000 über dynamisches DNS wie derzeit) wertvoller ist.
Hmmm… das hört sich wieder interessant an.
Ich habe aber nun noch ein bisschen herumüberlegt und werde (einfach aus Neugier) mal probieren den OpenTopoMap-Tileserver nachzubauen, ist ja im Prinzip auch nichts anderes als mit dem Standard-Mapnik, nur halt ein anderer Kartenstil. Falls es damit nix wird werde ich nochmal wambachers eben genannte Lösung versuchen.
Kurz und treffend beschrieben
Vielen Dank schonmal an alle Teilnehmer hier im Thread. Ich fange mal an und werde eine Statusmeldung mit Link zum Ansehen posten sobald ich zu ersten Ergebnissen gekommen bin.
Viele Grüße,
Christoph
Nee, das geht bei den Anforderungen auch mit MySql. Oder auch mit einem Shape-File. PostGis ist da total unterfordert.
Dann verstehe ich die ganze Aktion eh nicht. wenn du schon alles hast, dann verwende das doch auch. Wartung wirst du immer haben, da die Live-Daten in OSM sich permanent ändern.
Ich bin - auch aufgrund ziemlich anfängerhaften Fragen - davon ausgegangen, dass du bei Null anfängst.
Ja, wenn du schon eine DB hast, solltest du für Overlays den GeoServer verwenden. Der ist im Gegensatzt zum MapServer voll per GUI steuerbar und liefert dir die Overlays passend als WMS. Ein wenig Leaflet und einige Layerdefinitionen und Styles im GeoServer und du hast was auf dem Schirm. SQL macht der natürlich auch.
Mit den Overlays bist du bei einer bestehenden DB am schnellsten am Ziel. Zudem kommst du an die Daten interaktiv heran (Popups), wenn du Overlay verwendest, Hat auch seine Vorteile.
Aber eigentlich weist du selber noch nicht genau, was du eigentlich willst - was nicht schlimm, sondern bei den wirklich völlig unterschiedlichen Ansätzen verständlich ist. Selbst der Extremfall “Eigener Tileserver plus dynamische Overlays” wäre denkbar.
Gruss
walter
Verstehe … die Idee hinter meiner Frage war folgende: In diesem Thread http://forum.openstreetmap.org/viewtopic.php?id=31483 geht es um Druck von (großformatigen) OSM-Karten. Was da (primär) derzeit noch fehlt, ist ein Kartenstil mit den Informationen (Hydranten etc.) der Firemap. Dies erscheint mir aber erstmal nicht so schwierig. Der Nutzer erzeugt sich die Karten dann On-Demand, oder besser, regelmäßig im Vorfeld und hält sie für das Einsatzgebiet lokal vor. Von einer solchen Lösung hätten dann auch viele andere Nutzer etwas.
Gruß Klaus
PS: Die Diskussion der Idee bitte im o.g. Thread führen.
Also die ursprüngliche Idee war ja, die ganze Infrastruktur etwas zu verschlanken. Aber mittlerweile glaube ich dass ich meine Wünsche ohne eigenen Tile-Server nicht hinbekomme. Aber zumindest Nominatim hab ich ja schonmal eingespart.
Nach meiner ersten Installation des Tileservers habe ich alles so gelassen wie es ist (Never touch a running system). Ich habe zwar immer fleißig hier mitgelesen und geschrieben, aber halt nicht irgendwelche Sachen umgesetzt oder sonst groß “über den Tellerrand geschaut”. Ich wollte in meiner Ursprungsfrage einfach mal nachfragen ob ich noch anders zum Ziel komme, mit einer Methode die ich noch nicht auf dem Schirm habe.
Ja, das ist wahrscheinlich so. Ich versuche mich nun erstmal an der OpenTopoMap auf dem eigenen Tileserver, wie obenschon erwähnt. Da bin ich dann wenigstens auf einem Gebiet unterwegs auf dem ich mich schon halbwegs auskenne
Viele Grüße und Danke,
Christoph
Also ich denke, MySql ist einer klassischen Textdatei natürlich überlegen. Also wenn du Hydranten (und dann nur ca. 500 Stück) darstellen willst, ist das gar kein Problem.
Auch bei einem möglichen Adressen overlay sollte Mysql noch keine Poblem darstellen.
OSM hat ja auch einmal mit einer MYSQLDatenbank angefangen und dort eine extra Spalte für einen Koordinatenindex gepflegt.
Womit sich Mysql schwer tun dürfte und was die Stärken von Postgis sind Funktionen wie is_in (Flächen/Grenzen nicht nur BBoxen), Flächenberechnung und weitere für Geografische Abfragen nützliche Dinge.
Aber auch für Mysql gibt es dort bereits Erweiterungen. Nur nutzen die einem wenig, wenn man irgendwo einen Webspace mietet, weil sie dort selten installiert sind.
Aha, du hast das mit den Overlays also schon ausprobiert und bist mit dem Ergebnis nicht zufrieden? Sorry, aber eine “schlanke Lösung mit Tileserver” hab ich nicht im Angebot.
Ja, wenn das Ziel klar ist, kann man eine Lösung entwerfen.
Warum einfach, wenn es auch kompliziert geht.
So, jetzt mach ich aber Schluss, sonst trolle ich nämlich. Und das muss nicht sein.
Gruss
walter
Ich meine auch, dass das mit Mysql machbar sein sollte.
Nur ist es ja so, dass OpenLayers und Leaflet beim “Abholen” der Daten die BBox des gewünschten Ausschnittes (Tile) mit rüberschicken und das nicht ohne Grund.
siehe einen typischen WMS-Request:
https://osm.wno-edv-service.de/geoserver/wms?SERVICE=WMS&REQUEST=GetMap&VERSION=1.1.1
&LAYERS=osm%3Agsv_sirens&STYLES=&FORMAT=image%2Fpng8&TRANSPARENT=true
&HEIGHT=256&WIDTH=256&BUFFER=50&TIMEOUT=300&EXCEPTIONS=application%2Fvnd.ogc.se_inimage
&SRS=EPSG%3A3857
&BBOX=896453.4677285472,6465961.096699629,897676.46018111,6467184.089152193
Hier “sagt” &BBOX=896453.4677285472,6465961.096699629,897676.46018111,6467184.089152193 dem Server, dass nur Daten aus diesem Fenster benötigt werden. Diesen BBOX-Parameter benutzen die Server dazu, erst einmal danach zu filtern und nur die dort liegenden Daten zum Client zu schicken.
Daher sollte auf dem Server einen minimale spatiale Unterstützung vonhanden sein, da sonst der Server wirklich alle Daten, die er hat, schicken muß und der Client bei z.B. 500 Hydranten oder 20.000 Hausnummern am Block überfordert sein wird.
Das gilt übrigens nicht nur für den im Beispiel verwendeteten GeoServer, das gilt für alle “Datenquellen” und wenn es ein einfaches CSV ist. Irgendwie muss die Datenmenge eingeschränkt werden, sonst bricht der Client zusammen.
MySQL mit der optionalen Spatialen Unterstützung sollte das aber packen.
Gruss
walter