Hallo MattGPS, die Wende kann nicht als Taxistand genutzt werden. Die beiden Fahrbahnen sind mit durchgezogenen Linien (und Pflanzkübeln) getrennt. Nur an der Wendestelle sind die Linien auf 4 m durchbrochen und eine Fahrbahnmarkierung "Taxi" ist angebracht. Andere Hinweise gibt es nicht. Btw: In Backnang ist der Haupt-Taxiwartestand am Bahnhof. An der Bleichweise warten nur noch bei besonderen Anlässen Taxis. Bei Anruf kommt das Taxi in der Regel vom Bahnhof zur Bleichwiese gefahren. (Sind ja bloß ein paar Minuten).

Ich habe das korrigiert, weil ein Taxistand als "node"zu taggen ist und nicht als Fläche. der node ist zu setzen an der Stelle, wo das erste Taxi in der Reihe wartet (bzw. warten würde.) Die Anzahl der maximal wartenden Taxi-Fahrzeuge wurde mit capacity=6 angegeben. Der separate weg ist notwendig, weil nur die Taxis rechts an den Pollern vorbei auf die Obere-Bahnhof-Straße ausfahren sollen.

1. Das Tag natural=tree_row ist für andere Fälle vorgesehen.
2. Mit diesem tag sind die Bäume doppelt getaggt.
Bitte entferne natural=tree_row.

Hallo MattGPS, der Node "amenity=taxi" bedeutet, dass dort ein ein Taxistand ist. Dem ist nach meinem Kennstand nicht so. Die Wendemöglichkeit ist doch im benachbarten Way ausreichend beschrieben. Was meinst du?

Ich möchte zu diesem Revert eine sachliche Klarstellung geben.

Ein wesentlicher Punkt der Diskussionen in Kassel betraf das Parkplatz‑Mapping. Meine Änderungen basierten auf dem Wissensstand, den ich vor 3–4 Jahren aus dem Wiki und der gängigen Praxis kannte. Die Definition von service=parking_aisle im Wiki ist weiterhin unverändert und beschreibt Fahrgassen zwischen Stellplatzreihen.

In Kassel scheint sich zwischenzeitlich eine andere lokale Vorgehensweise etabliert zu haben, die jedoch weder im Wiki dokumentiert noch in Changeset‑Diskussionen oder Community‑Kanälen kommuniziert wurde. Die daraus entstandene Diskrepanz war ursächlich für die Missverständnisse.

Leider erhielt ich im Vorfeld keinen Hinweis darauf, dass hier eine abweichende lokale Praxis angewendet wird. Meine Änderungen waren nach offizieller Wiki‑Definition korrekt und nicht vandalistisch.

Der vorliegende Revert umfasst 16 meiner Changesets aus verschiedenen Regionen (u. a. Deggingen, Gruibingen, Kassel), die inhaltlich nichts miteinander zu tun haben. Eine pauschale Rücksetzung aller Änderungen eines Mappers ohne technische Einzelbegründung ist ungewöhnlich und aus meiner Sicht nicht angemessen.

Ich dokumentiere dies hier, damit die Hintergründe nachvollziehbar bleiben und keine falschen Eindrücke über meine Arbeit entstehen. Inhaltlich bin ich weiterhin bereit, sachlich über Tagging‑Fragen zu sprechen.

Aus meiner schon: Die Formulierung „grobe Fehler“ in der Revert‑Überschrift ist sachlich nicht zutreffend.
Meine Änderungen waren fachlich begründet und entsprechen den aktuellen Tagging‑Diskussionen.
Ich bitte darum, die Bewertung zu korrigieren oder neutral zu formulieren, damit meine Arbeit nicht durch unwahre Behauptungen abgewertet wird.

Damit wir die Diskussion zu einem klaren Abschluss bringen können, möchte ich nun festhalten, was aus meiner Sicht der nächste notwendige Schritt ist:

Du hast mehrfach betont, dass du dich nicht auf Einzelfälle einlassen möchtest, gleichzeitig aber eine Reihe voneinander unabhängiger Punkte aus verschiedenen Gebieten genannt.

Für die Bewertung eines Vollreverts ist jedoch entscheidend, welcher einzelne, konkrete Fehler in CS 185543300 deiner Meinung nach so gravierend war, dass ein vollständiger Revert notwendig wurde.

Die bisher genannten Punkte – ob landuse=industrial‑Teilflächen, Grünflächeninterpretation oder Multipolygonstruktur – sind selektiv korrigierbare Einzelthemen und rechtfertigen keinen umfassenden Rückbau.

Ich bitte dich daher um eine klare Aussage:
Welcher konkrete Fehler in diesem Changeset war aus deiner Sicht der ausschlaggebende Grund für den Vollrevert 185576401?

Erst wenn dieser Punkt eindeutig benannt ist, können wir beurteilen, ob der Revert fachlich gerechtfertigt war oder ob eine Rückabwicklung notwendig ist.

Hinweis zur aktuellen Situation:

In deiner letzten Rückmeldung hast du erklärt, dass die vier von zrop genannten Punkte alles seien, was an meinen Änderungen zu beanstanden gewesen ist.

Deine eigenen früheren Einlassungen – das angeblich zweifelhafte Zusammenfassen von landuse=industrial sowie das Übermappen breiter Straßen mit landuse=residential – hast du nicht erneut aufgeführt.

Damit stützt sich die Begründung für diesen Revert nun ausschließlich auf die vier Punkte von zrop. Diese Punkte (Brücke, Boulder, parking:left=separate, einzelne landuse=residential‑Fläche) sind jedoch isolierte, selektiv korrigierbare Einzelthemen und rechtfertigen keinen vollständigen Revert eines Changesets, das überwiegend korrekte und konsistente Flächenbereinigungen enthält.

Ich halte daher fest, dass die Grundlage für den umfassenden Revert nicht mehr nachvollziehbar ist

Hallo silversurfer83,

du hast diesen Revert mit der Begründung durchgeführt, ich hätte „hilfreiche Verbesserungen und grobe Fehler gemischt“.

Damit ich das nachvollziehen kann, bitte ich dich um eine konkrete Darstellung, welche Fehler du bei meinen Änderungen gesehen hast – insbesondere bei
– der Bereinigung und Vereinheitlichung der landuse=residential‑Flächen (u. a. Entfernen von boundary=census),
– sowie der Zusammenführung der landuse=industrial‑Flächen, die zuvor kleinteilig nach einzelnen Firmen getrennt waren.

Aus meiner Sicht waren diese Änderungen konsistent mit dem OSM‑Datenmodell und dienten der Verbesserung der Flächenstruktur in der Rösrather Innenstadt. Ein vollständiger Revert erscheint mir daher unverhältnismäßig, da er auch eindeutig korrekte Teile zurücksetzt.

Ich bitte dich daher um eine fachliche Begründung, warum ein umfassender Revert notwendig war und nicht eine selektive Korrektur der von dir als problematisch angesehenen Elemente.

Vielen Dank für deine Rückmeldung.

Hallo silversurfer83,

du hast diesen Revert mit der Begründung durchgeführt, ich hätte „hilfreiche Verbesserungen und grobe Fehler gemischt“.

Damit ich das nachvollziehen kann, bitte ich dich um eine konkrete Darstellung, welche Fehler du (nicht zrop) bei meinen Änderungen gesehen hast – insbesondere bei
– der Bereinigung und Vereinheitlichung der landuse=residential‑Flächen (u. a. Entfernen von boundary=census),
– sowie der Zusammenführung der landuse=industrial‑Flächen, die zuvor kleinteilig getrennt waren.

Aus meiner Sicht waren diese Änderungen konsistent mit dem OSM‑Datenmodell und dienten der Verbesserung der Flächenstruktur in der Rösrather Innenstadt. Ein vollständiger Revert erscheint mir daher unverhältnismäßig, da er auch eindeutig korrekte Teile zurücksetzt.

Ich bitte dich daher um eine fachliche Begründung, warum ein umfassender Revert notwendig war und nicht eine selektive detaillierte Diskussion der von dir als problematisch angesehenen Elemente.

Vielen Dank für deine Rückmeldung.

Zu den von "zrop" im cs-Kommentar 185537058 genannten vier „groben Fehlern“ möchte ich hier kurz Stellung nehmen, damit der Geamtzusammenhang kalr wird:

1. Brücke
Die betreffende Brücke wurde bereits vor über einem Jahr von crodthauser als razed:bridge=yes eingetragen. Aktuelle Luftbilder (NRW DOP, Bing) bestätigen den vollständigen Abriss. Eine Befahrung ist daher objektiv ausgeschlossen.

2. Boulder
Der von dir angesprochene 10(!) Jahre alte Boulder‑Eintrag war ein isolierter, leicht korrigierbarer Punktfehler, der keinen Einfluss auf die übrigen Flächenbearbeitungen hatte.

3. parking:left=separate
Auch hier handelt es sich um einen einzelnen Tagging‑Fehler von zrop, der problemlos selektiv korrigierbar gewesen wäre.

4. landuse=residential für ein einzelnes Gebäude
Dieser Punkt betrifft eine einzelne Fläche und ist ebenfalls kein struktureller Fehler, der einen vollständigen Revert rechtfertigt.

Keiner dieser vier Punkte stellt einen „groben Fehler“ dar, der einen umfassenden Revert notwendig macht. Alle wären einzeln und ohne Rückbau korrekter Änderungen behebbar gewesen.

Hallo Zrop, auf meine Nachfrage, ob wir über dieselbe Örtlichkeit sprechen – nämlich die seit über einem Jahr als razed:bridge=yes erfasste und laut aktuellen Luftbildern nicht mehr existierende Fußgänger-Brücke über die Sülz in Verlängerung der Walter‑Arendt‑Straße – habe ich keine Antwort erhalten.

Damit bleibt weiterhin unklar, welche konkrete Stelle du mit deiner Aussage meintest. Eine saubere abschließende Klärung des Sachverhalts ist ohne deine Rückmeldung leider nicht möglich.

Hallo Zrop,
nur zur Sicherheit: Sprechen wir über dieselbe Stelle – also die abgerissene Brücke über die Sülz in Verlängerung der Walter‑Arendt‑Straße?
Diese Brücke existiert ja nicht mehr.
Wenn du eine andere Örtlichkeit meinst, wäre eine kurze Konkretisierung hilfreich, damit wir nicht aneinander vorbeireden.

Zrop sagt: "das Gebäude befindet sich auf einem ausgewiesenen und erschlossenen Wohngebiet"
Ich sage. OSM bildet keine Liegenschaftskataster ab. Das nicht näher spezifizierte Gebäude liegt augenscheinlich inmitten eines verbuschten Geniets (Mapillary 2024)
zrop sagt: - beim Parkplatz hat silversurfer83 alles geschrieben
ich sage: Beim Tagging der am Parkplatz vorbei führenden Straße fehlte das tag "parking:left=separate". somit war der Parkplatz ein "stand alone"-Objekt und nicht mit dem Straßennetz verbunden.
Zrop sagt: - die Brücke war nie als "razed:bridge" erfasst und existiert real!"
Ich sage: Bitte die Änderungshistorie prüfen "Version 11" vor einem Jahr
Zrop sagt: - "barrier=boulder" wir 127x verwendet. Wenn Du es als falsch empfindest hättest Du den Wert ja ändern können
Ich sage: auch mit 127 Verwendungen bleibt das Tag "barrier=boulder" im Wiki undokumentiert und seine Verwendung fragwürdig. Was wohl ein Renderer mit diesem Tag anfängt? Ich kann es mir denken: nichts. er übernimmt es einfach nicht. Also ist dieser Tag nicht verarbeitbar. Auf dem Bing-Luftbild war in dem Bereich, wo die Linie gezogen verbuschtes Gelände mit überhängendem Blattwerk "scrub". Ich meine mich erinnern zu können, dass ich einen Vermerk eingestellt hatte, dass dort eine Vor-Ort-Überprüfung erfolgen sollte.

ticki_52

Abschließende Klarstellung:
Die vier Punkte wurden von mir bereits ausführlich beantwortet.
Die Wiederholung der selben Behauptungen durch zrop und silversurfer83 ändert nichts an den Fakten:
– Das Gebäude steht nach Mapillary 2024 isoliert im scrub, nicht in einem Wohngebiet.
– Die Parkfläche war geometrisch isoliert und ohne parking:lane‑Tag nicht erreichbar.
– Die Brücke war seit über einem Jahr als razed:bridge erfasst und existiert real nicht mehr.
– barrier=boulder ist kein gültiges OSM‑Tag; eine durchgehende Sperre ist nicht erkennbar.

Damit sind die Beanstandungen sachlich widerlegt.
Ich betrachte die Punkte als geklärt.

ticki_52

1. landuse=residential
Der frühere residential‑Block umfasste ein einzelnes Gebäude mit building=yes und vollständigen Adressdaten, das ohne erkennbare Zufahrt und ohne weitere bauliche Struktur mitten in Buschwerk steht. landuse=residential beschreibt eine zusammenhängende Wohnnutzung mit mehreren Gebäuden, Straßen, Parzellen oder sonstiger Siedlungsstruktur. Diese Voraussetzungen sind hier nicht gegeben. Das alte Polygon war eine grobe Altlast und entsprach nicht der tatsächlichen Nutzung. Für ein einzelnes, isoliertes Wohnhaus wäre place=isolated_dwelling grundsätzlich möglich. Dieser Tag beschreibt eine abgelegene Einzelansiedlung, die nicht Teil eines geschlossenen Siedlungsgefüges ist. Da das Gebäude jedoch bereits korrekt als building=yes mit Adresse erfasst ist und keine eigenständige Siedlungsfunktion besitzt, ist ein zusätzlicher place‑Knoten nicht zwingend erforderlich.

2. Parkplatz / parking=surface
Die vorherige Parkplatzfläche war geometrisch isoliert und nicht mit einem Weg verbunden, also in OSM nicht erreichbar.
Ein Parkplatz muss über einen Weg angebunden sein, damit Routing und Datenkonsistenz gewährleistet sind.
Ich habe daher die Fläche an den tatsächlichen Zufahrtsweg herangezogen – damit ist die Erreichbarkeit korrekt hergestellt.

parking=street_side ist nur dann passend, wenn Parkstände entlang einer Straße liegen.
Ein eigenständiges Parkplatzpolygon ist dagegen parking=surface.
Das reine Setzen von parking=street_side ersetzt keine korrekte geometrische Anbindung; die Erreichbarkeit muss über Wege hergestellt sein.

3. razed:bridge / Wegende
Die Brücke existiert real nicht mehr und ist korrekt als razed:bridge erfasst.
Der verbliebene Wegabschnitt war weiterhin als highway=residential eingetragen, führte aber bis direkt ans Ufer der Sülz.
Ab dem Poller ist der Weg nicht mehr befahrbar, sondern ein Fußweg – daher wurde dieser Abschnitt in highway=path geändert.
Das gesetzte noexit=yes war hier nicht sinnvoll, da der Weg nicht „endet“, sondern lediglich an der ehemaligen Brücke ins Gelände ausläuft.

4. barrier
Die frühere Barriere wurde historisch mehrfach umgetaggt (stone_row → boulder), ohne dass eine real existierende Sperre erkennbar wäre.
Auf dem NRW‑DOP könnten einzelne Blöcke sichtbar sein, die Fläche ist jedoch als natural=scrub gemappt und die Vegetation überwuchert solche Einzelobjekte vollständig. Ohne klar erkennbare, durchgehende physische Sperre ist das Entfernen des Barriere‑Tags korrekt.

Viele der vorgenommenen Änderungen betrafen veraltete Landnutzungen, redundante Kleinstflächen oder Objekte ohne reale Entsprechung. Die Bereinigung solcher Altlasten ist üblich und verbessert die Datenqualität.

Zum Revert:
Wegen dieser vier kleinen Punkte wurde mein kompletter Changeset mit über hundert Verbesserungen vor allem um das Schutzgebiet Kupfersiefer Bachtal vollständig zurückgesetzt. Das steht in keinem Verhältnis und ist sachlich nicht gerechtfertigt. Ich bitte darum, den Revert zurückzunehmen. Ich bin der Auffassung, dass ich die Beanstandungen aus dem CS-Kommentar hiermit ausreichend erklärt habe. Ein Komplett‑Revert ist hier eindeutig überzogen und vernichtet wertvolle Aktualisierungen.

@ silversurfer83: Deine Nachricht und Aufforderung zur Stellungnahme traf am 11. 07.26 um 21:18 Uhr bei mir ein. Am 12.07.26 um 10:30 h war der Revert durch. Dazwischen war ich noch kurz schlafen. Sieht so sachliche und konstruktive Problembewältigung aus?

Hier meine kommentare zu den von zrop genannten punkten:

11. Juli 2026 um 11:29 Uhr

Ich möchte darum bitten, die Diskussion auf die konkreten Objekte und Tags zu konzentrieren.
Abwertende Formulierungen wie „Quark“, „Mist“, „Kram“ oder Kommentare über angeblich „gewechselte Reviere“ tragen nicht zu einer fachlichen Klärung bei.
Die Fragen zu einzelnen Änderungen beantworte ich selbstverständlich, allerdings in einem zeitlich angemessenen Rahmen und auf Basis der jeweiligen Datenlage.
Bitte konzentrieren wir uns auf die einzelnen Punkte und klären sie sachlich.

Bitte erläutern, weshalb diese Änderung als ‚Vandalismus‘ eingestuft wurde.
Die wiederhergestellte Struktur enthält künstliche, nicht reale Parkplatzsegmente und fiktive service‑Wege.
Meine Änderung war eine technische Bereinigung dieser Fehler.
Eine Begründung des Reverts ist erforderlich.

@ karaga: see comment @Vinzenz Mai
3 separate LKW-Parkplätze (amenity=parking) zwischen den Zufahrtswegen zu mappen, entspricht nicht dem OSM-Modell für BAB-Rasthöfe. Ich habe die LKW-Parkplätze in einer Fläche zusammengefasst und daneben die PKW-Parkplatz separat gemappt, weil ja zum einen hgv=yes und trailer=yes gilt und auf dem PKW-Parkplatz gilt motorcar=yes. (Motorräder folgen demnächst).