ich möchte nochmal was zu den Durchmessern sagen. Meiner Meinung nach ist „fire_hydrant:diameter=* (50, 80, 100, 150, 300, 400)" falsch und würde uns die Möglichkeit verbauen den Durchmesser des Hydranten (in Deutschland DN 50, 80, 100) vom Durchmesser der versorgenden Wasserhauptleitung (DN 50, 80, 100, 125, 150, 200, 250, 300, 400…, das was auf dem Hydrantenschild angegeben ist) zu unterscheiden. Grade auch der Durchmesser des Hydranten kann für die FW wichtig sein da der Anschluss für das Standrohr vom Durchmesser des Hydranten abhängig ist.
Richtig ist, die genaue Lage der Hauptleitung interessiert die FW nicht, aber die Nennweite der Wasserhauptleitung sollte die FWler interessieren, grade wenn auf der einen Straßenseite eine DN 80 liegt, aber in unmittelbarer Nähe eine DN 300 liegen würde, aus der über mehrere Hydranten viel mehr Wasser entnommen werden könnte bei geringerem Druckverlust in der Versorgungsleitung.
Richtig ist leider auch; Den Otto Normal-Mapper (wie mich in allen anderen Belangen) würde man wahrscheinlich mit den unterschiedlichen Durchmesser Angaben Hydrant/Rohrleitung eher verwirren und vom Mappen abhalten.
Es gibt doch mittlerweile auch einige Foren für Feuerwehren. Wären das nicht ideale Plätze, um dort Werbung für die OFM zu machen ?
Leider habe ich dort keinen zugang. Aber wie ich mittlerweile weiß, liest der eine oder andere von der Feuerwehr ja mit.
@ Joe-the-Bow (Ralf)
Deine Anmerkung wurde weiter oben in diesem Tread schon aufgegriffen und diskutiert. Im Prinzip hast du völlig recht. Es gibt dem nichts hinzuzufügen und die “Mehrzahl” der hier beteiligten FW-ler stimmt dir sicher zu.
Andererseits soll man nicht aus dem Blick verlieren für wen die OFM geschaffen wurde. In aller erster Linie für die Feuerwehren. Diese wissen sehr wohl den Unterschied zwischen dem Durchmesser des Standrohres/Überflurhydranten und dem der Leitung. In der Regel kommt in Deutschland eh der 80er Durchmesser zum Einsatz.
Sollten tatsächlich in einem Bereich mal ein oder zwei vom Standard abweichende Unterflurhydranten vorhanden sein, sind diese 100% der FW bekannt, denn speziell für diese Exoten müssen zusätzliche Standrohre mitgeführt werden.
Wenn man sich die Wiki-Seite genau ansieht, wird man feststellen das der Durchmesser mit <*2. Dimensioning (pipe diameter 65, 80, 100, 150 etc.) fire_hydrant:diameter=**> “erklärt” ist.
IMHO ist hier eindeutig gesagt das die Leitung im Untergrund gemeint ist.
Der Einfachheit halber sollte man die Bezeichnung fire_hydrant:diameter= belassen. Damit ist eine eindeutige Zuordnung zum Namensraum “Hydrant” gegeben. Die die es angeht (die FW’ler) wissen was gemeint ist und alle anderen wird es nicht stören.
Habe jetzt von der lokalen Feuerwehr und Wassergenossenschaft Pläne (grobe Lage) und Listen von Hydranten bekommen. Die werden wir dann in kürze mit dem GPS Logger gemeinsam vor Ort erfassen. Dabei wird auch gleichzeitig nochmal die Beschilderung überprüft. Anschließend sollen auch übersichtliche Karten für die Einsatzfahrzeuge etc. erstellt werden. Da geht also was. Bin mal gespannt wie das “kleine Projekt” dann entsprechend läuft un ob evtl. andere auch “Feuer fangen”
Evtl. sollte man im wiki nochmal deutlicher darauf hinweisen, das es sich bei Diameter um den Durchmesser der Wasserleitung handelt an den der Hydrant angeschlossen ist.
eigentlich nicht viel - die sind ja ziemlich umbeweglich.
Ab und zu wird mal einer beim Asphaltieren erwischt und bei uns ist auch gerade ein Schild abgefallen - das war’s.
Neuzugänge kann man ja nicht überwachen und Abgänge gibt es wohl nur, wenn ne Strasse abgerissen wird - aber das merken mer eh.
…aehm. Ich hätte mich genauer ausdrücken sollen. Ich meine nicht ‘plausible Veränderungen in OSM aufgrund der Realtität’ oder einen RSS Feed der Realität (ohne hin zu laufen und nachzugucken / RSS Feet ), sondern das überwachen nur in der OSM betreffs Veränderungen (löschen, verschieben, ändern von tags - also auch wenn kein Vandalismus vorliegt). Unabhängig davon das ich für den “Feuerwehrgebrauch” eine Kopie erstellt habe (und erstelle für die noch zu erfassenden) möchte ich doch die entsprechenden Daten in OSM im Blick haben.
Jau, da hast du Recht.
Dieser Schutz vor unerwünschten Änderungen in der DB wird ja noch von anderen “Zielgruppen” erwartet/verlangt. Dazu zählen Organisationen wie Rettungsdienste, manche Bereiche der öffentlichen Verwaltung, Firmen und andere OSM-Randgruppen, die dem Braten nicht trauen.
Wie das allerdings erreicht werden könnte, ist wohl noch unklar.
Werte Hydrantenprofis,
ich bekam gerade eine Anfrage von einem OSM User aus Polen: ein Rettungsdienst in Tatra Gebirgen würde gern OSM Karten verwenden. Der Bedarf an eine Hardware / Softwarelösung wäre:
a. Anzeige der OSM Karte inklusive Hydranten sowie wenn möglich:
b. Suche vom nächst gelegenem Hydranten
Es kommt immer darauf an was dann weiter damit geschehen soll. Wenn die Karten nur online betrachtet werden sollen, ließe sich das sicher schnell mit Openlayers und der Overpassapi erledigt werden.
Wenn es aber um offline Lösungen geht mit mäßigem Traffic, dann würde ich zu Ubuntu/Linux Mint tendieren mit dem dafür vorgesehenen Paket von Kai: http://wiki.openstreetmap.org/wiki/DE:Ubuntu_tile_server
Dort dann die Styles anpassen und fertig. Sollte auch auf nicht ganz aktuellen Laptops laufen. Vorteil: offline und belastet nicht die Infrastruktur von OSM. Nachteil ist sicher die Aktualität aber wenn es nur um einen Kreis (Wojewordschaft) geht, dann ist das aber schnell wöchentlich importiert. Für Sachsen brauchte ich weniger als eine Stunde mit Installieren.
Das Suchen nach dem nächstgelegenen Hydranten ist mit der Offlinelösung sicher auch machbar. Dort muss man dann nur über die Php eine Anfrage an die Datenbank den entsprechenden Punkt in der Datenbank abfragen und hervorheben.
Das ist wieder das Problem der Anwendung.
Ich habe das Serverpaket in einer virtuellen Maschiene laufen. Auf einem 4 Kern AMD Prozessor mit 8GB Ram.
Die Verzögerung beim rendering sind für neue Tiles bei 1-5 Sekunden. Sicher kann man sich die Tiles auch vorberechnen lassen und dann auch auf einem Webserver zwischenlagern. Damit würden die Tiles dann schneller ausgeliefert.
Im Allgemeinen gilt je mehr Ram desto besser.
Allerdings ist die Frage wie oft aktualisiert wird. Davon hängt dann auch ab wie oft gerendert wird. Denn das ist der eigentliche Aufwand.
Alternativ sollte man sich auch mal nach mobilen Lösungen für OSM Daten umsehen. GPSMid läuft zum Beispiel auf einem javafähigen Handy und rendert aus speziell vorbereiteten Daten live und hat auch Routing und Umgebungssuche drin.
Gleiches gibts natürlich auch für Android. Damit hätte man das “immer dabei” und hat obendrein nicht den Riesen Hardwareaufwand.
Wenn ihr nur mit overpassapi und Mapniktiles arbeitet, dann ist der Aufwand sicher sehr viel geringer. Nur die Umgebungssuche ist dann nicht so einfach.
Da ich bisher die Hydranten wieder von Hand mit JOSM aus der OSM gewurschtelt habe so das sie die Feuerwehr im garmin oder zum angucken in google earth etc. nutzen kann, gibt es denn eine einfachere Möglichkeit die für ein bestimmtes Gebiet mit allen zugehörigen tags zu extrahieren ? Im Wiki ist die Rede von einer geplanten exportfunktion als gpx etc. ?
Als Workarround bis zur Exportfunktion:
Es kommt darauf an in welchem Format die Dtaen dann vorliegen müssen. Im Prinzip ist es möglich mit Programmen wie OSMconvert und OSMFilter oder aber auch Ossmosis die Daten direkt aus den Extrakten herauszuschneiden und zu filtern. Anschließend hast du OSM Dateien. Wie du davon jetzt auf GPX kommst weiß ich allerdings nicht. Aber im Zeweifelsfall sollten die auch von Josm zu öffnen sein und dann im Zielformat zu speichern.
Bin mal gespannt wie das “kleine Projekt” dann entsprechend läuft un ob evtl. andere auch “Feuer fangen” 
), sondern das überwachen nur in der OSM betreffs Veränderungen (löschen, verschieben, ändern von tags - also auch wenn kein Vandalismus vorliegt). Unabhängig davon das ich für den “Feuerwehrgebrauch” eine Kopie erstellt habe (und erstelle für die noch zu erfassenden) möchte ich doch die entsprechenden Daten in OSM im Blick haben.