Man kann in OsmHydrant v1 weiterhin bestehende Hydranten ansehen und zum Vergleich auch eine KML-Datei hochladen, deren Punkte dann als kleine Fadenkreuze dargestellt werden. Siehe mein Screenshot weiter oben. Nur in OSM einloggen (und damit auch bearbeiten) geht nicht.
Ich habe die Positionen wie gesagt verglichen und nur diesen einen Hydranten gefunden. Alle anderen sind bisher noch gar nicht erfasst, daher wäre der Import als Punkte nur mit emergency = fire_hydrant ohne weitere Tags meiner Meinung nach schon ein guter Schritt.
Evtl. könnte man noch fire_hydrant:type (BAUART in der KML-Datei; Unterflurhydrant → underground, Überflurhydrant → pillar) und nach genauerer Verifikation auch fire_hydrant:diameter (anscheinend NENNWEITE4 in der KML-Datei; unbekannt → Tag nicht setzen) importieren, aber die könnte man beide auch weglassen und dann z.B. StreetComplete-Benutzern vor Ort überlassen.
Dass @KS-Brandschutz den einen bestehenden Hydranten aus OSM einfach gelöscht hat, finde ich allerdings auch nicht gut; ich hätte ihn dann eher im Import ausgelassen.
Ich finde die Anzahl liegt in einem ungünstigen Mittelfeld zwischen „kann man ja einfach manuell vor Ort erfassen“ (das dauert bei 300 Stück schon ne ganze Zeit) und „dafür lohnt sich der Aufwand, die Import-Richtlinien komplett einzuhalten“…
So eine Feuerwehr besteht ja auch nicht nur aus einer Person. Zumal mit diesem Import ja auch erst Unter- und Überflurhydranten erledigt wären - das sind selten alle Entnahmestellen (Brunnen, Löschwassertanks etc.)
Hallo, vielen Dank für deine Bemühungen, aber ich finde es unglaublich was da geschrieben wird. Das ganze hat nichts mit KS-Branschutz zu tun ich hab es nur über diesen Mailadresse reingestellt, Ich selber bin seit 40 Jahre in der Feuerwehr, seit 2000 in der Führung und seit ca. 10 Jahre Stell. Kommandant, daher kenne die Hydranten sehr gut, das ganze währe eine Erleichterung wenn man es über diesen Weg einspielen könnte und ich die fehlenden Daten nachpflegen könnte. Es ist auch richtig das es in so einer Feuerwehr nicht nur eine Person gibt aber das Ehrenamt ist so stark belastet das man versucht den Kameraden Arbeit abzunehmen. Wir machen uns über die Bürokratie selber kaputt.
In solchen Fällen halte ich das nicht für einen typischen Import, da hier detaillierte Ortskenntnisse zu den Objekten vorliegen. Ich sehe das hier eher als technische Erleichterung der Erfassung der Hydranten in OSM. Deshalb bin ich der Meinung, dass eine einfache Zustimmung zu einem sorgfältigen Import durch die Mapper hier ausreichend sein sollte.
Wie schon von @flo2154 angesprochen könnten diese Merkmale importiert werden:
Vermutlich ist “im Straßenkörper” bei LAGE_DES_H eher nicht verwertbar, da wir bei fire_hydrant:position u.a. zwischen Fahrspur auf der Straße und Bürgersteig unterscheiden, “im Straßenkörper” meint aber vermutlich eher beides?
Was in der Kommunikation etwas unglücklich ist - dann meldet man sich nicht mit einem Nickname an, der eine andere Organisationsform suggeriert. Zudem du auch noch an anderer Stelle schreibst
Wie soll man denn dann darauf kommen, dass “du” die Feuerwehr Kirchzarten bist?
Dann sollte es dir ein leichtes sein, insbesondere und mindestens die fehlenden Nennweiten zu ergänzen.
Sorry, das was in den Bereich “Einsatzplanung” fällt, ist keine Bürokratie, sondern sinnvolle Beschäftigung mit örtlicher Infrastruktur - und das schaffen genügend Feuerwehren hier in OSM ohne Probleme. Gerade erst hier noch beschrieben: Planungshilfe gesucht: Straßenkarte mit Hydrantenübersicht. Ich will hier jetzt keinen gegeneinander ausspielen, aber mal zum Vergleich: FFWHol_Norimaki's Diary | OpenStreetMap : einzelne Person, rund 1500 Hydranten gepflegt - von Hand.
Danke dir, das werde ich mir die kommenden Tage mal anschauen. Aber nur damit wir hier keine doppelte Arbeit machen: hast du meinen anderen Thread bzgl. eines konkreten Import-Vorschlags inkl. Skript und erstelltem GeoJSON gesehen, den ich weiter oben verlinkt hatte?
Ich weiß nicht, warum du das für einen Import als zwingend notwendig ansiehst; diese Tags kann man doch auch danach via iD, OsmHydrant v2, MapComplete oder StreetComplete ergänzen?
Meinem Gefühl nach wird hier wegen des automatischen Imports etwas übertrieben. Wenn es ein deutschlandweiter Import wäre, der viel durcheinanderbringen kann, dann kann ich das gut verstehen und da wäre ich auch vorsichtig. Aber hier handelt es sich ja nur um gerade mal 300 Hydranten (also Nodes, die typischerweise mit nix anderem verbunden sind) auf einem kleinen Gebiet. Da sehe ich nicht, warum das genauso behandelt werden muss.
Zwei Punkte wären mir hier allerdings wichtig: Zum einen sollte man sicherstellen, dass man nicht gegen irgendwelche Lizenzen verstößt und zum anderen, dass bestehende Daten (sprich Hydranten) nicht gelöscht werden. Die folgende Tabelle zeigt die Positionen der sechs Hydranten, die ich im Datensatz vom 1.1. in Kirchzarten gefunden habe:
Länge
Breite
(Node-)ID
7.9222546
47.9721470
2979383354
7.9233936
47.9716236
2979383355
7.9245511
47.9707628
2979383356
7.9195622
47.9747848
2979383360
7.9189315
47.9749297
2979383361
7.9853888
47.9612703
7935389466
PS: Ich vermute mal, der Import betrifft nur den Kern von Kirchzarten, sodass die fünf Hydranten in Stegen nicht betroffen sind. Der sechste ist von dir vorgestern gelöscht worden. Mein Vorschlag wäre, diese Löschung zu revertieren, diesen entsprechenden Hydranten vom automatischen Import auszunehmen und dann die anderen Hydranten zu importieren.
Ich möchte mich hier nicht verkämpfen, schon gar nicht allein. Zu meinen Beweggründen noch mal etwas weiter ausgeholt:
Die relativ strengen Standards für Importe sind im Wiki beschrieben und allgemein bekannt.
Hydranten gehören aus meiner Sicht zu den kritischeren Objekten.
Bei Importen sehe ich bei der Datengrundlage eine Bandbreite von “Löschwasserkataster wurde vor einer Woche durch ein Ingenieurbüro nach Auslitern jedes einzelnen Hydranten erstellt” bis “das Wasserwerk hat immer mal wieder ein paar Hydranten in einer Excel-Tabelle gespeichert”.
Dazwischen gibt es ziemlich viel.
Was mir hier fehlt:
Eine Beschreibung der Abfragemethodik aus der Datenbank (was wurde denn bei den Stadtwerken angefragt?) und
die Beschreibung der Satzstruktur (wieso gibt es mehrere Nennweiten-Felder, wären z. B. Spülhydranten irgendwie erkennbar?).
Eine belastbare Aussage zur Aktualität.
In Kombination mit den fehlenden Nennweiten ist das kein Bild, bei dem ich sagen würde „Sieht super aus, das entspricht einer manuellen und aktuellen Erfassung vor Ort“. Und darum geht es doch – so habe ich es verstanden – bei unseren Importstandards.
Was dadurch entstehen kann (die Fälle habe ich nicht erfunden):
Es handelt sich nicht um einen Hydranten für die Feuerwehr
Hydranten sind beschädigt: Deckel fehlt, Dreck steht bis zu Oberkante oder Ventilstange ist nicht erreichbar.
Hydranten sind wegen Bauarbeiten vorübergehend nicht einsatzbereit.
Auf dem Hydranten steht dauerhaft ein Altpapiercontainer.
Der Straßenbauer hat den Leitungsbauer aus gutem technischem Grund davon abgehalten, den Hydranten zu installieren, er taucht aber trotzdem in der Datenbank auf.
Finde ich jetzt alles schlimmer als eine Straßenlampe, die nicht mehr existiert. Ich bin mit meinen Argumenten dann jetzt auch am Ende.
Nur eins noch:
Das wäre doch mal eine Aussage: alles, was nur einzelne Gemeinden betrifft (und das dürften 95% aller potentiellen Daten sein, nicht nur bei Hydranten), gilt als genehmigt. Dann können wir uns solche Diskussionen hier sparen.
Ich würde einfach sagen, lasst das mit dem Import. Ich werde die Hydranten von Hand eintragen. Alle Hydranten werden jährlich von der Feuerwehr begangen und gepflegt und es sind alles Hydranten für die Feuerwehr. Ich hätte es nicht gefragt wenn ich selber wüsste das die vorhanden Daten in Ordnung sind.
Dank allen für eure Bemühungen.
Mammi71
(One feature, Six mappers and still More ways to map it)
36
Genau das sind Aussagen, die im Rahmen eines Importprozesses geklärt werden und sich positiv auf den Import auswirken. Genauso wie vorher geklärt werden muss wie mit Duplikaten umzugehen ist.
Dazu gehört auch, im Zweifel offenzulegen, wer hinter dem Import steckt und die Freigabe der Daten schriftlich zu dokumentieren.
Und wenn Du dann noch erklärt hättest, dass Du und Deine Kameraden innerhalb eines Jahres im Rahmen der jährlichen Überprüfung die fehlenden Daten durch Vor-Ort-Erhebung mit einem der zur Verfügung stehenden Tools ergänzen, dann hätte einem Import glaube nichts mehr im Wege gestanden.
@KS-Brandschutz: Wofür benötigt ihr als Feuerwehr eigentlich die Daten in OSM? Ihr habt sie ja als private Daten (sicher vor Vandalismus) onehin schon vorliegen.
Den Thread hatte ich mir nicht angesehen, da ich nicht erkannt hatte, dass es hierbei um die selben Hydranten ging. Ich ging zunächst davon aus, dass alle relevanten Dinge in diesem Thread behandelt wurden.
Der Aufwand zur Erstellung des Skripts wäre mir für einen einmaligen Import doch etwas zu hoch gewesen. Mit JOSM hatte ich das in 1-2 Minuten durch einfache Analyse (JOSM zeigt u.a. an, welche Werte wie oft vorkommen), Ersetzungen (über die Suche) und einer anschließenden Overpass-Abfrage in JOSM zum Abgleich erledigt. JOSM kann die KML-Datei direkt öffnen.
Da muss man aber auch vorsichtig sein. Wenn irgendeine Behörde von Berlin sämtliche Straßen Berlins durch ihre eigenen Daten ersetzen will, wäre ich dagegen. Der Punkt hier ist, dass der Import sehr überschaubar ist. Zudem ist der Willen da, Fehler händisch zu korrigieren. Und, auch wenn du den Teufel an die Wand malst, ich den Eindruck habe, dass die Qualität der Daten gut genug ist. (Die Antwort von @KS-Brandschutz bestätigt das ja auch, aber auch ohne die Info hätte ich das geschrieben.)
Das ist vielleicht was für einen eigenen Thread,
aber da wir hier von einem “Mittleren Import” sprechen,
wo Handarbeit lästig ist und viel Formular und Code übertrieben, kam mir der Gedanke:
Könnte man in JOSM für sowas ein Plug-In erstellen, dass aus einer Tabelle lesen kann
und die einzelnen Änderungen noch mal manuell gesichtet und abgenickt werden.
Dazu ein “Formular” das alle Infos sammelt und im Change-Set Kommentar ablegt.