ich möchte euch ein neues Projekt vorstellen, an dem ich aktuell arbeite:
HydrantMap ist ein modernes Community-Projekt zur Darstellung und Pflege von Hydrantendaten aus OpenStreetMap, inspiriert von OsmHydrant, das viele vermutlich kennen.
Da OsmHydrant seit längerer Zeit nicht mehr aktiv weiterentwickelt wird und einige Funktionen inzwischen leider nicht mehr zuverlässig arbeiten, möchte ich die Grundidee in moderner Form weiterführen und langfristig offen für die Community erhalten.
Der Fokus liegt aktuell unter anderem auf:
schneller und moderner Weboberfläche,
guter Nutzbarkeit für Mapper,
mobiler Nutzung,
aktueller OSM-Datenbasis,
langfristiger Wartbarkeit,
einfacher Bearbeitung und Pflege von Hydrantendaten.
Geplant sind außerdem weitere Funktionen wie beispielsweise eine Integration von Hydrantenfotos direkt in die Plattform.
Das Projekt befindet sich noch im Aufbau und sicher ist noch nicht alles perfekt. Feedback, Ideen, technische Hinweise und Verbesserungsvorschläge aus der Community sind deshalb ausdrücklich willkommen.
Den ursprünglichen Entwickler von OsmHydrant habe ich vorab kontaktiert und positives Feedback zur Weiterführung der Idee erhalten.
Mir geht es ausdrücklich nicht darum, OsmHydrant zu kopieren oder zu ersetzen, sondern die Idee technisch modernisiert weiterzuführen und der Community wieder eine funktionierende Plattform bereitzustellen.
Ich war neugierig wegen Deiner Betonung auf “technisch modernisiert”. Ich dachte: Hat hier endlich mal einer die Sache vernünftig gelöst (mit einem effizienten eigenen Backend wie GitHub - giggls/osmpoidb · GitHub von der OpenCampingMap)? Dann war ich ein bisschen enttäuscht, als ich gesehen habe, dass es doch wieder “nur” Overpass ist. Ich verstehe ja, dass das der Weg des geringsten Widerstandes ist, aber zugleich bedeutet es: Je mehr Erfolg Dein Projekt hat, desto mehr Last entsteht auf dem öffentlichen, spendenfinanzierten Overpass-Server, und wenn der irgendwann einknickt, dann geht halt auch Deine Map nicht mehr. Für niemanden. Schau Dir doch mal die Arbeit von Sven mit der OpenCampingMap an, der hat eine super-schlanke Datenbank, die nur das speichert, was für den Zweck unbedingt gebraucht wird - also keine Riesenserver erforderlich.
Hey, Danke für die Einschätzung und Tipps. Ich habe genau das, was du beschrieben hast bereits gelesen, und an verschiedenen Stellen, auf verschiedenen Seiten wargenommen, dass es Sinnvoll wäre eine Art Cache zu haben. Tatsächlich habe ich im Backend angefangen, die dafür notwendigen Informationen in einer MariaDB zwischen zu speichern. Allerdings war es (bis jetzt) nicht zufriedenstellend für mich, da es einige Hindernisse gab.
Man muss das Rad ja nicht unbedingt komplett neu erfinden. Ich versuche mich unbedingt an deinem Tipp.
Also ich habe mich in den letzten 2 Tagen mal dran gesetzt und eine eigenes Backend dazu aufgebaut, aus Zeit und Platzgründen erstmal nur „de“ aber es scheint echt gut zu funktionieren. Als nächstes würde ich „eu“ machen und dann „planet“.
Ich bitte darum, mal zu testen und überprüfen ob das bisher gut funktioniert.
Gibt es weitere Hinweise und Ideen, um das Projekt zu verbessern und zu erweitern? Fehlende Funktionen?
Ich bin irgendwie daran gescheitert, Hydranten zu verschieben (oder zu löschen) – ich finde die Schaltfläche nicht. Entweder ich bin das Problem oder die Usability.
Das Symbol eines emergency=fire_service_inlet ist identisch mit emergency=suction_point
kurzes Update: es werden nun in akutell (noch) in Abstand von 30 min Weltweit (!) alle relevanten Daten in eine eigene DB gezogen. Overpass ist somit komplett raus. @woodpeck
Die grundsätzlichen Anforderunen von @rempshaener habe ich umgesetzt:
Das Clustering nahe beieinander liegender Hydranten wurde angepasst. In hohen Zoomstufen (18+19) werden Hydranten nicht mehr zu einem Cluster zusammengefasst.
Bei der Referenz ist jetzt klarer, dass damit die Hydrantennummer laut Schild gemeint ist. Siehe Info dazu.
Für fire_hydrant:diameter=* habe ich nicht einfach starr „mm“ in den Wert geschrieben, sondern einen Infotext ergänzt und die Eingabe etwas robuster gemacht: 100, 100 mm und DN100 werden sinnvoll behandelt/normalisiert, Inch-Angaben und bestehende nicht-numerische Werte werden nicht kaputtvalidiert. * Siehe Wiki
Die Fälle „fehlende Nennweite“ und „fehlende Hydrantennummer“ sind per Checkbox abbildbar.
Für fire_service_inlet gibt es jetzt ein eigenes Symbol. Außerdem wird dieser Typ nur angezeigt. Neu anlegen ist nicht möglich.
Zusätzlich habe ich amtliche DOP-/Orthophoto-Layer ergänzt: NRW, Niedersachsen, Bayern, Hamburg und Brandenburg. ESRI bleibt als weltweiter Fallback erhalten. Die amtlichen Luftbilder werden nur dort angeboten, wo sie räumlich sinnvoll sind.
Hydranten usw. lassen sich im Bearbeitungsmodus jetzt verschieben. Dafür wird ein Pin/Marker verwendet, dessen Spitze die genaue neue Position markiert.
Danke für die konkreten Hinweise, das war sehr hilfreich. Wenn ihr weitere problematische Beispiele oder Tagging-Fälle findet, gerne her damit.
Mir ist es irgendwie nicht gelungen, nach dem Verschieben zu speichern.
Was mir in dem Kontext noch einfällt: Bitte prüfen, ob der Hydrant Bestandteil eines way (meist highway, landuse oder building ist); das Verschieben würde die Geometrie zerstören.
Noch eine weitere Anmerkung zu field.pillarType (= pillar:type)
Das würde ich nur aufnehmen, wenn das Tool tatsächlich außerhalb von Deutschland eingesetzt werden soll. Wenn pillar:type in Deutschland gesetzt wird, dann meist falsch und mit Bezug auf einen möglichen Vorschieber; pillar:type bezieht sich aber auf den Hydranten selbst und ist in Deutschland in der Regel dry_barrel
Ok verstehe. Tatsächlich kann ich auch nicht mehr verschieben. Da muss ich nochmal ran.
EDIT 1: ok geht wieder.
Wenn der Hydrant Bestandteil eines ways ist, müsste ich dann vor dem Verschieben prüfen:
Hat der Node „Parent Ways“?
Falls ja:
Warnung anzeigen
Verschieben blockieren
oder zuerst den Node sauber vom Way entkoppeln (ist das erlaubt?)
EDIT 2: Ein Check wurde eingebaut und gibt Rückmeldung und sperrt ggf. direkt das verschieben.
Ich würde das Tool gleich so planen, das es überall nutzbar ist. Deshalb pillar:type nur dann abfragen wenn es ein Oberflurhydrant ist und dann sogar nur als „Schieberegler“ in der GUI also Standard nicht gesetzt, und dann nur „nass“ oder „trocken“ auswählbar. Oder lieber ganz weglassen?
Automatisiert ist das so ohne Weiteres nicht gut lösbar.
Entkoppeln geht problemlos nur dann ohne “Ersatz”-Node, wenn es sich um die erste Version handelt und angrenzende Nodes danach nicht verschoben wurden. Aber das gedanklich für alle Varianten zu durchdringen… Aber grundsätzlich ist es erst mal ein Erfassungsfehler, da ist eine manuelle Bearbeitung mit anderen Tools zumutbar.
Das löst zu Missverständnissen ein.
Nur meine Meinung: Ich halte es nicht für so wichtig.