Hallo,
ich vermute doch mal, das Häkchen "Ich möchte, dass jemand meine Bearbeitungen prüft" hast du versehentlich gesetzt? Ansonsten wäre es mir natürlich eine Ehre ;-)
Viele Grüße

Hallo,
bei fire_hydrant:type geht es rein um die Bauform. D.h. wenn aus dem (Bauform=)Überflurhydranten gesaugt wird, dann ist es trotzdem ein fire_hydrant:type=pillar.
Daher richtig: dann kann man auch bei einem Überflurhydranten fire_hydrant:pressure=suction taggen. (Und es am besten in "description" erläutern.)
Trotzdem noch einmal der Hinweis: emergency=suction_point ist in so einem Fall falsch. emergency=suction_point setzt ein offenes Gewässer ohne jegliche feste Verrohrung voraus.
Viele Grüße

Hallo,
ein Überflurhydrant wäre dann keine Saugstelle, siehe emergency=fire_hydrant#fire_hydrant:type=*_details
Wenn ich helfen kann: einfach melden.
Viele Grüße

Hallo,
ich schaue regelmäßig über emergency=suction_point, da diese doch eher exotisch sind.
Auf Grund deiner Beschreibung und dem Stichwort „Notstromeinspeisung“ tippe ich auf einen Tiefbrunnen mit Elektropumpe, das wird dann z. B. wie folgt erfasst:

emergency=fire_hydrant
fire_hydrant:type=pipe
fire_hydrant:pressure=yes
water_source=groundwater
couplings=1
couplings:diameters=A
flow_rate=XXX l/min

Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Die Erfassung von Postleitzahlen in dieser Form ist nicht üblich.
Details findest du hier: osm.wiki/DE:Key:postal%20code?uselang=de
Die dortige Feststellung „[...]in Deutschland nicht empfohlen, da die Postleitzahlen landesweit als Gebiete vorhanden sind“ ist richtig; das Objekt für die PLZ 99831 ist dieses hier: relation/1159897

Meine Empfehlung wäre, den Eintrag wieder zu entfernen.
Wenn du Fragen hast: bitte einfach melden.

Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Das access-Thema ist generell nicht ganz einfach...

Ohne die Gegebenheiten vor Ort zu kennen: Sofern eine explizite oder implizite Beschränkung besteht – letztere ist umstritten – reicht in der Regel ein access=private.
Das entspricht auch dem Tor (www.openstreetmap.org/node/12524313107), das so getaggt ist. D.h. Weg und Tor passen jetzt nicht mehr zusammen; letztlich wäre auch das Tor bereits ausreichend gewesen, da der eine Punkt die gesamte Zufahrt entsprechend sperrt.
Meine Empfehlung wäre, das access=no wieder zu entfernen.

Bei Fragen bitte melden.
Viele Grüße

Siehe note/4566414

Danke dir, war auch eher beiläufig drüber gestolpert.

Hallo,
nein, du hast alles Nötige erledigt.
Falls du wegen der OpenFireMap fragst: das dauert ein paar Tage, bis es dargestellt wird.
Viele Grüße

Hallo,
der OSM-Inspector wirft hier way/365813992 einen Fehler aus, weil sich die Teilflächen hier node/3686034663 berühren.
Das lässt sich m.E. leicht per Multipolygon beheben, das geht ja auch auch bei area:highway.
Viele Grüße

Hallo,
nein, das war kein Zufall, ich bin tatsächlich über die Seite von Pascal Neis auf die Bitte aufmerksam geworden.
Ich habe vor ein paar Monaten mal angefangen, dort regelmäßig reinzuschauen und eine Bitte täglich zu beantworten.
Ich finde eure Idee der systematischen Abarbeitung gut, würde aber trotzdem raten, da nicht zu viel Aufwand reinzustecken. Dafür sind es (auf Deutschland bezogen) gar nicht sooo viele Prüfbitten.
Viel Erfolg bei euren Bemühungen.
Viele Grüße

Hallo,
die Nennweite ist ja in der Regel durch Beschilderung leicht feststellbar und auch gleichzeitig ein wichtiges Datum. Ich hatte auch per Mapillary einige Positionen auf Lagegenauigkeit geprüft, da war die Nennweite teilweise auf dem Schild erkennbar.
Das lässt sich entsprechend leicht nachtragen, StreetComplete eignet sich z.B. sehr gut dazu.
Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Vorab eine förmliche Anmerkung: auf Grund des fehlenden Änderungssatzkommentars und der fehlenden Quellenangabe ist für andere Mapper kaum nachvollziehbar, wie die Daten zustande gekommen sind – auch auf Grund der immensen Größe des Changesets.

Ansonsten: das sieht sehr gut aus.

Schön wäre eine Ergänzung weiterer Daten, insbesondere der Nennweite (fire_hydrant:diameter).

Vielen Dank für deinen Beitrag.

Bei Fragen bitte melden.
Viele Grüße

ja, ist auffindbar ;-)

Hallo,
das ist schwierig zu lösen.
Eigentlich dürfte es dann kein Überflurhydrant sein, denn wozu dienen die B-Abgänge? Und ebenso sollen an Überflurhydranten keine Saugschläuche angeschlossen werden - das wäre hier zwar unproblematisch, aber genau deshalb gibt es entsprechende reine A-Verrohrungen.
Ich bin ein wenig ratlos.
Vielleicht lässt du es so, schreibst den Hintergrund aber in die “description”?
Viele Grüße

Danke, ich habe es umgestellt.
Viele Grüße

Das ist Entscheidung des Renderers - wenn er das nicht rendern möchte, erscheint es leider nicht. War auch schon einmal Thema, siehe https://github.com/gravitystorm/openstreetmap-carto/issues/3892
Viele Grüße

Hallo,
danke für die Info.
Dafür gibt es meines Wissens noch kein einheitliches Taggingschema, ergibt aber Sinn.
Wieder was gelernt.
Viele Grüße

Hallo,
ich habe eine kurze Frage: um was für Unterflurhydranten handelt es sich, die Grundwasser nutzen?
Viele Grüße

Hallo,

du hast bei node/12496602105 und node/7161244404 jeweils fire_hydrant:type=wall (Wandhydrant) gesetzt.
Ich vermute, du meintest bei beiden fire_hydrant:type=pipe.

Viele Grüße