Hallo,
wir reden über einen Brunnen, der aus einer grundwasserführenden Schicht Wasser bezieht? Der hat kein „Volumen“ – anders als ein Löschwasserbehälter. Wenn die Leistungsfähigkeit eingeschätzt werden soll, dann als Volumenstrom in l/min. Deswegen verstehe ich weder das water_tank:volume – es ist kein „water_tank“ - noch hat das „volume“.
Oder ist die nach Norm vorgesehene Fördermenge über zwei Stunden gemeint? Das passt dann aber auch nicht; bei 12.000 l wären das gerade mal 100 l/min – selbst die geringste Fördermenge beträgt 400 l/min.
Ich würde gerne verstehen, was das tatsächlich ist.
Und dann schauen wir mal weiter.
Viele Grüße

Hallo,

das wäre

emergency=fire_hydrant
fire_hydrant:type=pipe
fire_hydrant:pressure=suction
water_source=water_tank
water_tank:volume=218m³
couplings=1
couplings:diameters=A

Viele Grüße

Hallo,

das gesamte Tagging ist zu überarbeiten.
Hier sind so viele Widersprüchlichkeiten drin: Ein Brunnen, der aber ein festes Volumen hat?
Um was handelt es sich denn?

Viele Grüße

Hallo,

das gesamte Tagging ist zu überarbeiten.
Hier sind so viele Widersprüchlichkeiten drin: Ein Brunnen, der aber ein festes Volumen hat?
Um was handelt es sich denn?

Viele Grüße

Hallo,
ich habe einige Anmerkungen zu deinen Bearbeitungen.

Adresse:
Hydranten haben keine Adresse im Sinne des addr:*-Schemas.
Dass überhaupt Adressen an Hydranten erfasst werden, ist zumindest nicht unstrittig.
Sofern das unumgänglich ist, erfolgt dies mittels object:*-Schema, siehe osm.wiki/DE:Key:object:*
Für den Fall, dass du dies umsetzt, dazu folgender Hinweis:
„16/18“ ist kein zulässiger Wert für addr:housenumber.

Kupplungen:
Das Feld „couplings“ bleibt bei Unterflurhydranten leer, da es sich um die „Angabe der vorhandenen Anzahl an Schlauchanschlüssen“ handelt, siehe osm.wiki/DE:Key:couplings?uselang=de. Unterflurhydranten haben in der Regel nur mit Standrohr eine Schlauchkupplung.
Insofern sind auch die Angaben
couplings:diameters=Standrohr B;B
couplings:type=Standrohr
falsch. Bitte löschen.

Name:
Hydranten haben keinen Namen.
In diesem Fall sind die Daten auch verzichtbar, da vollständig redundant.

Geometrie:
Hydranten sollten nicht mit Straßen, Gebäuden u. ä. verbunden werden. Das lässt sich leicht beheben: in iD z. B. markieren und „E“ drücken – das löst den Hydranten von der Linie.

Viele Grüße

Hallo,
ich habe einige Anmerkungen zu deinen Bearbeitungen.

Adresse:
Hydranten haben keine Adresse im Sinne des addr:*-Schemas.
Dass überhaupt Adressen an Hydranten erfasst werden, ist zumindest nicht unstrittig.
Sofern das unumgänglich ist, erfolgt dies mittels object:*-Schema, siehe osm.wiki/DE:Key:object:*
Für den Fall, dass du dies umsetzt, dazu noch folgende Hinweise:
Straßen werden genau so eingetragen, wie sie bereits erfasst sind.
Hier heißt die Straße „St.-Andreas-Straße“, sie darf dann nicht als „St.Andreas Str.“ gespeichert werden.
„Kindergarten“ ist kein zulässiger Wert für addr:housenumber.

Name:
Hydranten haben keinen Namen.
In diesem Fall sind die Daten auch verzichtbar, da vollständig redundant.

Viele Grüße

P.S.: Auf dem Luftbild ist gut erkennbar, dass der Hydrant 5 m weiter am Zaun steht.

Hallo,
dann kann ich deine Herleitung nachvollziehen. So wie ich das verstehe, waren mit POI wahrscheinlich vorrangig Restaurants, Tankstellen etc. gemeint.
loc_name ist problematisch, da es erst einmal ein „name“ sein müsste – jedoch einer, der eben nur lokal genutzt wird. Dann vielleicht doch eher description. Das Beispiel "Der bei Meyer" habe ich so auch schon mal gesehen (ich meine als description); wenn das dann aber nicht gerade eine Kneipe oder ein Schreiner ist, wäre das ein Problem, wenn die Daten natürlicher Personen so in die Datenbank rutschten.
Weiterhin viel Spaß und viel Erfolg.
Viele Grüße

Hallo,

wenn ich fragen darf: Woher stammt die Empfehlung zu contact:*?
Sie ist eben nicht richtig. Einzig anerkanntes Schema ist object:*. Siehe z.B. https://community.openstreetmap.org/t/hydrant-adresse-bei-position-eingetragen/118634

Ich werbe dafür, auf Adressen ganz zu verzichten.

Ich verstehe durchaus die Genese: in den „Vor-GIS-Zeiten“ hatte ich eine Tabelle, anhand der ich abhängig vom Einsatzort und konsistenter Adressvergabe einen Hydranten raussuchen konnte. Aber heute: Die Verwendung einer hoffentlich angrenzenden Adresse, die dann ja selbst wieder georeferenziert ist, wäre dann „von hinten durch die Brust ins Auge“.
Ein paar Argumente gegen Adressen an Hydranten:
• Bei Freiluftobjekten: wonach bemisst sich die Adresse? Nach dem nächsten Eingang, nach dem Grundstück?
• Wer synchronisiert Änderungen? Objektstandorte können sich ändern, Adressen auch (z. B. im Rahmen der immer wieder vorkommenden Umbenennung von Straßen)
• Spätestens wenn an einer Adresse mehrere Objekte erfasst sind, geht die Eindeutigkeit verloren.
Entsprechend liegt die Häufigkeit von entsprechenden Daten (in Deutschland) unter 2 Promille.

Viele Grüße

Am Beispiel node/13013005154:
Die Straße gibt es so nicht.
Bitte versuche, dich an bestehenden Strukturen zu orientieren.

Hallo,
bitte nicht contact:* verwenden.
Da man Hydranten nicht kontaktieren kann, ist das schlicht falsch.
Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.
Das sieht gut aus. Auch hier noch einmal der Hinweis: am besten gleich auch noch die Nennweite (der Zuleitung) und die Position erfassen.

Bei Fragen bitte melden.
Viele Grüße

Hello,
Unfortunately, I have only just seen the effects of this changeset.
How did you come up with the idea of ignoring the description (translates: „gas pipes: oxygen and nitrogen“) and the refs because you recognised „unusual substances“ (due to the semicolon), thereby duplicating the previously pragmatically „summarised“ pipeline? Without adjusting the tagging and – worst of all – swapping the pipes?
Please regard existing structures. It took you half an hour, but it has already taken me several hours.
Best regards

Hallo,
danke dir.
Viele Grüße

Hallo,

danke für den Link.

Interessant finde ich zwei Dinge:
1. Der VRR-Router routet nicht über den von dir angelegten sidewalk. Tut er das generell nicht oder liegt das daran, dass er von der stop_position ausgeht, nicht von der platform? Wäre das der Fall, hätte ich auch keine richtige Lösung. Ich bin weiterhin nicht arg begeistert, den Gehweg separat erfassen, habe aber trotzdem mal dieses Stück hier www.openstreetmap.org/way/1443439846 eingesetzt.

2. Ich habe mal die „üblichen“ OSM-Router laufen lassen.
osm.org/directions?engine=graphhopper_foot&route=51.181917%2C6.678295%3B51.181998%2C6.682045#map=19/51.181826/6.680165&layers=N
Nur Straße, trotzdem 4 min

osm.org/directions?engine=fossgis_osrm_foot&route=51.181917%2C6.678295%3B51.181998%2C6.682045#map=19/51.181839/6.680165&layers=N
Gehweg, 4 min

osm.org/directions?engine=fossgis_valhalla_foot&route=51.181917%2C6.678295%3B51.181998%2C6.682045#map=19/51.181822/6.680176&layers=N
Nur Straße, trotzdem 4 min

Dagegen https://www.vrr.de/fahrplan-mobilitaet/fahrplanauskunft/app/trip/2?formik=destination%3Dde%253A05162%253A20608%26origin%3Dde%253A05162%253A20118&lng=de&trip=multiModalitySelected%3Dpt
mit 3 min
Hat der VRR vielleicht eine zu hohe Geh-Geschwindigkeit? Berücksichtigt er Fußgängerampeln?

Viele Grüße aus Neuss

Hallo,

hier nur eine Anmerkung zu node/13083790882
Wenn es sich um einen offenen Wasserbehälter (=Wasserentnahme per Saugschlauch und Saugkorb) handelt, der vorrangig der Feuerwehr dient, würde auch
emergency=water_tank
water_tank:volume=60 m³
reichen.

Wenn nicht: einfach melden.

Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.
Du hast um eine Prüfung deiner Bearbeitungen gebeten.

Zu den Überflurhydranten habe ich nur die Empfehlung, als Mindestangaben auch noch die Nennweite (der Zuleitung) und die Position zu erfassen.
Bei Bedarf kämen auch noch Anzahl und Typ der Schlauchkupplungen hinzu.

Zu node/13245295229 habe ich eine grundsätzliche Anmerkung:
emergency=water_tank und man_made=storage_tank passt nicht so richtig zusammen. Bei Löschwasserentnahmestellen hat sich eher eingebürgert, von der Art der Entnahme auszugehen. Das ist diese Stelle, hier https://www.mapillary.com/app/?pKey=456800278744313&focus=photo&lat=47.718414008026&lng=10.555760083077&z=17&x=0.6492425073819292&y=0.6653006137631355&zoom=1.389261744966443, richtig?
Dann bietet sich folgendes Tagging an:
emergency=fire_hydrant
fire_hydrant:type=pipe
fire_hydrant:pressure=suction
couplings=1
couplings:diameters=A
water_source=water_tank
water_tank:volume=90 m³

Vielen Dank für deinen Beitrag und weiterhin viel Spaß beim Mappen.
Viele Grüße

Hallo,
kein Problem, bei Fragen bitte melden.
Viele Grüße

Hallo,
die Daten gehören nicht an das Gebäude, sondern an das Gelände (way/1026476011). Nun sind die Daten teilweise doppelt bzw. widersprüchlich gepflegt.
Würdest du die Daten bitte einmal "umziehen"?
Viele Grüße

Hallo,
ich habe zwei Anmerkungen zu deinen Bearbeitungen:

Nennweite:
fire_hydrant:diameter wird ohne Einheiten erfasst, also z. B. „100“ statt „100mm“.

colour=red:
Die Angabe von Farben ist bei Unterflurhydranten eher unüblich, u.a. auch, da nicht ganz klar ist, worauf sich die Farbe beziehen soll: den Decken, die Klaue oder die Schutzkappe. Für einige Straßenzüge liegen recht gute Mapillary-Bilder vor. Dort habe ich keine roten Objekte entdecken können. Wie kommt diese Angabe zustande?

Bei Fragen bitte melden.

Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.
Das sieht gut aus, ich habe keine Anmerkungen.

Bei Fragen bitte melden.
Viele Grüße