Hallo,
vielen Dank dass du beschrieben hast, warum du die Objekte gelöscht hast. Das ist allerdings kein ausreichender Grund für die Löschung. Ich habe die Objekte daher vorerst reaktiviert.
Wenn du möchtest, kannst du dich hier intensiver mit den Hintergründen vertraut machen: osm.wiki/DE:Why_can%27t_I_delete_this_trail%3F
Viele Grüße

Daher mein Vorschlag des access=private. Wenn da jemand außerhalb der „Disziplinargewalt“ der Feuerwehr reinfährt, kann er/sie das tun - es gilt immer noch die Straßenverkehrsordnung.
Viele Grüße

Nachtrag: implizit vorstellbar wäre für das kürzere Stück ein access=private

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Zu den einzelnen Tags:

access=no, bicycle=no, horse=no, motor_vehicle=no
Das ist vor Ort (siehe Mapillary) so nicht ausgewiesen. Es wäre auch doppelt hinderlich: zum einen verhindert es z. B. das Routing auch für die Feuerwehr, zum anderen wäre es nur auf dem kurzen Stück zwischen Rad-/Fußweg und Tor richtig, da z. B. Radfahrer an dieser Stelle zwischen Radweg und Sorsumer Straße wechseln dürfen.

name=Feuerwehrausfahrt
Das ist kein Name, sondern eine Beschreibung.

oneway=yes
Das ist so nicht ausgewiesen. Ein Schild „Feuerwehrausfahrt“ hat damit erst einmal nichts zu tun. Zumal das Schild bei geöffnetem Tor nicht sichtbar ist. Es muss zwingend ein Schild "Einbahnstraße" ausgewiesen sein.

So wie es seit 2013 erfasst war, passte es meines Erachten.

Bei Fragen bitte melden.
Viele Grüße

Hinweis auf changeset/164027609

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Einen Radweg quer durch eine bestehende und stark verdichtete Innenstadtstruktur anzulegen ist für den Anfang eine sehr große Herausforderung.

Wie dir der Editor beim Speichern mitgeteilt hat, hast du allein 36 Fehler „warnings:crossing_ways:highway-highway“ und 5 warnings:crossing_ways:highway-railway eingebaut. D. h. Hier kreuzt die Linie andere Linien, ohne dass sich diese Punkte teilen (was sie müssen) oder dass diese Punkte mit gewissen Eigenschaften versehen wurden (insbesondere bei Kreuzungen mit der Straßenbahn wichtig).
Dann beginnt die Linie am Wehrhahn im Nichts – sie ist nicht mit dem Straßennetz verbunden.
An einigen Stellen ist die Linie mit anderen Objekten verbunden, hier z.B. www.openstreetmap.org/node/12696349460 mit einem landuse. Das sollte so nicht sein.
Die separate Fahrspur ist am Hauptway bereits z. B. mit
cycleway:lane=exclusive
cycleway=lane
angegeben.
Sofern eine separate Erfassung ohne bauliche Trennung überhaupt "zulässig" wäre, müsste das alles gegen cycleway:separate ersetzt werden.
Weiterhin fehlen Angaben hinsichtlich der Nutzbarkeit in beide Fahrtrichtungen, vermutlich oneway=yes.
An den Ampeln fehlen Angaben, dass die Ampeln auch für die Fahrradspur gelten.
Kurzum: ich möchte dich bitte, deine Anpassungen vollständig zurückzusetzen und dich für den Anfang erst einmal in osm.wiki/DE:Bicycle/Radverkehrsanlagen_kartieren einzulesen.

Bei Fragen bitte melden.
Viele Grüße

Ich bin gerade auch noch über note/4557978 gestolpert. Das ist genau die Frage: was ist das?

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Der von dir angelegte Node trägt kein funktionales Tagging. So ist es nur eine Adresse mit einem Namen, es fehlt die Beschreibung, um was es sich handelt. Also z.B. ein office=…

Bei Fragen bitte melden.
Viele Grüße

Hallo,
wenn du dir hinsichtlich der "Übersetzung" von Verkehrszeichen nicht sicher bist, kann ich dir ein Tool wie https://trafficsigns.osm-verkehrswende.org/DE empfehlen.
Viele Grüße

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

Das Feuerwehrhaus ist doppelt erfasst, einmal als Gebäudefläche (way/1109744782) und einmal als Punkt (node/1673845275). Am besten wäre es, das amenity=fire_station gleich am Gelände zu erfassen, also nicht nur als Punkt oder als Gebäude.

Bitte melde dich, wenn du Fragen hast.

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

Hallo und herzlich willkommen bei OpenStreetMap.
Du hast um eine Prüfung deiner Bearbeitungen gebeten.
Unabhängig davon, ob die Einrichtung eventuell bereits in der Bubatzkarte auftaucht oder nicht:
Statt
social_facility=childrens_centre
social_facility:for=juvenile

würde besser passen bzw. wäre richtiger:
amenity=community_centre
community_centre=youth_centre
community_centre:for=juvenile

Das wird übrigens auch definitiv von der Bubatzkarte berücksichtigt.

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

Hallo,

die Anmerkungen zu changeset/163856328 kommen auch hier zum Tragen.

Dazu noch ein weiterer Hinweis: Hydranten sollten nicht mit anderen Objekten (hier: Straßen) verbunden werden, siehe z. B. www.openstreetmap.org/node/12684592086.
Das ist leicht korrigierbar. Im Editor markieren und „E“ drücken – das war es schon.

Viele Grüße

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

Ich habe meine Anmerkungen in absteigender Relevanz sortiert.

ref
In das Feld ref gehört ausschließlich die Hydrantennummer und auch nur dann, wenn diese auf dem Hydrantenschild ausgewiesen ist. Zur Nennweite siehe fire_hydrant:diameter

fire_hydrant:diameter
In dieses Feld bitte die Nennweite in mm eintragen.

fire_hydrant:position
Die Position ist ebenfalls eine sinnvolle Angabe

couplings:type
Insbesondere dann, wenn (bei Überflurhydranten) „couplings“ bereits angegeben ist, sollten die (Storz-)Größen auch angegeben werden, z. B. „B;B“

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

Hallo,
so schnell wollte ich dann doch nicht aufgeben.
Ich haben den Relationstyp auf Multipolygon umgestellt, das ist eigentlich auch "richtiger", es ist schließlich ein Gesamtensemble. Die einzelnen Teile habe ich auf building:part umgestellt.
So ist es konzeptionell besser getroffen und löst auch gleichzeitig noch das Adressproblem.
Viele Grüße

Hallo,
zu diesem Unterflurhydranten haben ich nur folgende Anmerkungen.

In das Feld „ref“ gehört die Hydrantennummer, sofern eine vergeben wurde. Du meinst wahrscheinlich mit der 100 die Nennweite, die gehört nach fire_hydrant:diameter.
Die Anzahl der Kupplungen ergibt bei Unterflurhydranten grundsätzlich keinen Sinn, weil es ausschließlich um (anschlussfertige) Schlauchkupplungen geht.

Bei Fragen bitte melden.

Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.

Du hast um eine Prüfung deiner Bearbeitungen gebeten.
Zu diesem Überflurhydranten habe ich folgende Anmerkungen:

fire_hydrant:diameter
Besonders interessant ist die Nennweite (der Wasserleitung).

couplings:diameters
Neben der reinen Anzahl der Kupplungen (couplings=2) wäre auch noch von Interesse, um welche Größe es sich handelt, also wahrscheinlich couplings:diameters=B;B

Geometrie
Der Hydrant ist mit der Umrandung der Straßenfläche verbunden. Das ist nicht ideal, lässt sicher leicht beheben: im Editor „E“ drücken – fertig.

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

Viele Grüße

Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.
Ich habe nur eine Anmerkung: das Feld „note“ richtet sich vorrangig an andere Mapper. Beschreibungen für den Datenkonsumenten sind in „description“ besser aufgehoben.

Bei Fragen bitte melden.
Viele Grüße

Hallo,
danke, hab ich nicht gesehen, bin vom Konni-Ring gekommen. Habe nur das unclassified gegen residential getauscht.
Viele Grüße

Hallo,

ja, es gibt Lieferdienste, die OSM ganz oder in Teilen (Grundstückszufahrten, Adressen usw.) nutzen. Viele nutzen aber auch Lösungen, die auf zugekauften Adressdaten insbesondere des BKG beruhen.
Und hier liegt wahrscheinlich auch das Problem.
Solange es die Adresse Am Alten Bach 50 nicht offiziell gibt, wird es immer wieder zu Problemen kommen. Da ich immer mal wieder die amtlichen Adressdaten mit dem OSM-Bestand abgleiche, ist mir schon vor einigen Jahren die Abweichung zur offiziellen Adresse Horremer Straße 45 aufgefallen. Aus OSM-Sicht ist das okay: es gilt das On-the-ground-truth-Prinzip, und ausgewiesen vor Ort ist nun mal die Adresse “Am Alten Bach 50”.

Zu deinen Lösungsansätzen:
Das eine Problem ist der Renderer. Der “Standard-Stil” carto-osm rendert einfach in vielen Fällen keine Adressen. Völlig unproblematisch und vorhersehbar ist die Darstellung nur bei nodes und building-ways ohne Zusatztags (amenity, heritage usw.). Das ist aber das Problem des Renderers; ein “Erzwingen” wäre dann unerwünschtes Tagging für den Renderer (osm.wiki/DE:Taggen_f%C3%BCr_den_Renderer)
Das andere Problem ist Nominatim. Hier ist es ein bekanntes Problem (oder fehlendes Feature), was leider noch nicht gelöst wurde und vielleicht auch nicht so schnell wird, siehe https://github.com/osm-search/Nominatim/issues/463
Ich mache mir aber mal Gedanken, ob es noch andere Lösungen geben könnte.

Viele Grüße

Hallo,
das access=no hieße grundsätzlich „niemand“, was dann eigentlich auch z.B. für die Post gilt. Das wird dann zwar wieder durch das foot=private neutralisiert, da aber der „footway“ die Nutzbarkeit ohnehin einschränkt, ist ein access=private die deutlich einfachere Variante.
Viele Grüße