Auf der Suche nach crossings die potentiell falsch getagged sind (z.B. mit dem deprecated crossing=zebra) ist mir aufgefallen, dass es in Deutschland mehrere Tausend nodes und ways gibt, die mit crossing=unmarked und crossing:markings=yes getagged sind. Vielfach sind beide tags erst in jüngerer Vergangenheit in einem changeset hinzugefügt worden (z.B. Way: 1525708162 | OpenStreetMap).
Nach meiner Auffassung und dem was dazu im Wiki steht, ist diese Kombination klar widersprüchlich.
Übersehe ich hier etwas und es gibt Fälle wo das Kombinieren dieser tags sinnvoll ist?
The Mapillary imagery from 2020 shows no markings.
Regardless, best to remove the crossing=* tag and just accurately record crossing:markings=* + crossing:signals=* ![]()
Hi, willkommen bei OSM!
Es ist auf jeden Fall ein Fehler in den Daten. Am Besten ist es, einen Kommentar unter dem Changeset zu hinterlassen, um den Hintergrund dieses Fehlers zu ermitteln bzw. für seine Korrektur zu sorgen.
Falls du selbst in der Gegend unterwegs bist, steht es dir natürlich frei, selbst dort vorbeizuschauen und die korrekten Tags einzutragen.
Hört sich erstmal viel an, aber bei Millionen von hw=crossing Nodes eine Fehlerquote von weit unter 1%. ![]()
Bei denen die ich hier mal gecheckt habe war crossing=unmarked wohl falsch anstelle crossing=uncontrolled gesetzt.
Wo gibt es da die Markierung… ![]()
Ist ohne Markierung mit tactile_paving=yes
Was ich immer mal wieder bei crossings beobachte, ist wie inkonsistent mit Querungsstellen wie diesen (mit Markierung für Radfahrer, ohne Markierung für Fußgänger) umgegangen wird:
(OSM-Link)
Vielleicht trägt das zu dem
crossing=unmarked + crossing:markings=yes-Problem bei.Es gibt natürlich das Taggingschema mit
footway:crossing:markings und cycleway:crossing:markings, aber wirklich verbreitet ist es nicht und es ist unterschiedlich, welcher Wert dann für crossing=* gesetzt wird.
Hier noch ne entsprechende Overpass-Query:
PS: Da diese Tags mittlerweile zu 95% von SC gesetzt werden wäre es schön, wenn da eine entsprechende Validierung reingebaut würde.
Ich frage mich, ob das z.T. vlt. auch typos von autocomplete sind? Also crossing=un getippt und dann falsch vervollständigt? Oder wenn mehrere Querungen bearbeitet wurden, die unterschiedlich sind aus versehen alle ausgewählt etc.
Einige Fälle erklären sich vmtl. dadurch, dass die Insel farblich markiert ist, wodurch manch einer vlt. Interpretations-Spielraum sieht z.B.
Eigentlich braucht crossing=unmarked überhaupt kein crossing:markings weil das bereits no impliziert.
Man müsste auch den betroffenen Wegabschnitt mit prüfen, weil dort auch öfters footway/cycleway/path=crossing + crossing:markings=* getaggt wird.
ja, leider nicht weit verbreitet und auch von Editoren insbesondere von StreetComplete nicht direkt unterstützt
welcher Wert für crossing dann zu verwenden wäre ist nicht dokumentiert, wobei die ganzen crossing:markings/signals etc darauf abzielt das crossing-Tag zu ersetzen.
Die fehlerhaften Kombinationen von crossing und crossing:markings kommen leicht zustande, wenn man im Editor einen der beiden Tags aktualisiert ohne den anderen zu beachten. Kann durchaus sein, dass manche Vorlagen hier noch Fehler machen und alte redundante Tags nicht entsprechend entfernen oder anpassen.
ID setzt zum Beispiel crossing=uncontrolled und vergisst crossing:markings von no auf yes zu ändern. Bei crossing=unmarked wird jedoch immer crossing:markings=no gesetzt.
uncontrolled wird sicherlich auch öfter mal missverstanden. Ist leider nicht so intuitiv, dass da mit Markierung gemeint ist und eben nicht unmarked.
Danke für eure Rückmeldungen!
Ich habe inzwischen erfahren, dass zumindest die größeren Cluster in München einfach Fehler beim editieren waren.
Wenn man das jetzt für die betroffenen changesets (also nur die in München) via search and replace in josm gesammelt ändert, zählt das dann schon als automatischer Edit der speziell dokumentiert werden sollte?
Das andere ist die Frage, was stattdessen für Tags angebracht wären?
Ich würde, wenn ich dem wiki folge crossing=uncontrolled + crossing:markings=no nehmen.
EDIT: Quatsch, crossing=unmarked wäre richtig.
Andererseits wird ja immer wieder diskutiert ob das tagging von Kreuzungen nicht grundsätzlich anders gelöst werden sollte, und z.B. crossing=* komplett zu deprecaten. Ich habe zwar noch nicht viel Erfahrung in dem Bereich, finde diesen Ansatz aber eigentlich ganz interessant.
In dem Fall wären crossing:markings=no und crossing:signals=no zu nehmen.
Das würde ich auf jeden Fall machen. crossing=uncontrolled sehe ich da als optional, ich würd mir nicht die Mühe machen, falsch ist es nicht.
Derzeitige Anzahl in D : 1612 (Nur hw=crossing gezählt, nicht footway=crossing).
Ein großer Hotspot ist München-Ost. ![]()
EDIT: Das war ebenfalls ein Versehen .
So viele Änderungen sind es nun auch nicht?. Es ist auch nur lokal begrenzt und offensichtlich hast du dich mit dem Verursacher auch schon geeinigt.
Außerdem wurde das hier ja diskutiert, dass sollte auch reichen. Kamnst im Changeset-Kommentar die url von dieser Diskussion angeben.
Konnte jetzt nachvollziehen, wie dieser und diverse ähnliche Fälle entstanden sind:
Beim ursprünglichen taggen wurde crossing=* vergessen und es gab wohl mal eine Map-Roulette Runde, um diese fehlenden crossing=* zu ergänzen. Wenn dann crossing:markings falsch war, wurde das manchmal vergessen, aus genau diesem Grund:
Exakt dafür gibt’s bereits einen Bug-Report bei iD. Osmose issue um das zu flaggen habe ich mal erstellt.
Im Wiki steht doch aber recht eindeutig, dass crossing=uncontrolled für markierte Querungsstellen sei.
Oh, stimmt.
Despite the name,
crossing=uncontrolledis not for uncontrolled crossings.
Habe die obige Overpass Query angepasst. Sie findet momentan 5449 Fälle in D.
Stimmt, mein Fehler. Bin zwischenzeitlich zu Zebrastreifen übergegangen und habe das durcheinandergebracht.


