Ich hatte es so verstanden, dass barrier=kerb + kerb=raised Probleme macht, nicht aber kerb=lowered. Der Titel des Threads impliziert aber etwas anderes. Was denn nun?
Für welchen der beiden Wege gilt ein barrier=*, das am Schnittpunkt zweier Wege gesetzt ist? Für beide? Dann ist barrier=kerb am Schnittpunkt zwischen einem Fußweg und einer Straße falsch, weil es ja nur für den Fußweg gelten soll. Für einen der beiden Wege? Dann ist die Frage, für welchen der beiden und wie der Router das wissen soll.
Ja, das kommt eben dabei raus wenn man Micromapping (Bordsteine mappen) mit Makromapping (aber nicht da wo sie wirklich sind, sondern generalisiert) mischt.
Volle Zustimmung, aber es ist nicht am Router, diese Mappingfehler zu entwirren. Ich erwarte geradezu von einem Router, dass eine barrier=* am Schnittpunkt mehrerer Wege für alle am Schnittpunkt beteiligten Wege gilt und nicht auf einmal nur für einen bestimmten Weg.
Im Wiki steht dazu:
Do not place a barrier tag on a junction between highways
Man sollte vielleicht mal prüfen, wie oft das vorkommt. Ich gehe davon aus, dass es in 99% der Fälle falsch ist.
Das Thema Mapping von Bordsteinen wurde vor kurzem im internationalen Forum diskutiert [1], [2]. Konsens war dabei, dass barrier=kerb nur dann auf einem Knoten gesetzt werden sollte, wenn es für alle Wege gilt, zu denen der Knoten gehört. Das dürfte bei Kreuzungen so gut wie nie der Fall sein.
Mit diesem Overpass-Query lassen sich möglicherweise falsch gesetzte barrier=kerb tags finden. In den Beispielen sind die “Schuldigen” die folgenden Knoten: [1], [2], [3].
Die Ursache ist genau das im ersten der beiden englischen Threads beschriebene Problem. StreetComplete setzt kerb=raised nämlich auf (Knoten, die Teil sind von) Straßen, um anzuzeigen, dass der Bordstein neben der Straße erhöht ist. Aus meiner Sicht wäre hierfür sidewalk:both:kerb=raised besser, aber gut. iD schlägt dann stumpf bei jedem kerb=* ohne barrier=kerb vor, das barrier=kerb zu ergänzen. So sind sicherlich schon einige Mappingfehler entstanden. Ich habe das als Bug in iD gemeldet.
Ein Router, der barrier=kerb mit Kosten versieht, je nach Fahrzeugtyp und Höhe des Bordsteins, und es daher eher vermeidet, macht also alles richtig. Es ganz zu sperren, ist vielleicht etwas drastisch und gerade bei kerb=rolled sicher falsch. Ein normales Auto kommt ja durchaus über einen Bordstein. Das Hauptproblem sehe ich hier aber beim Tagging und bei iD.
Korrigier mich, wenn ich falsch liege, aber ich bezweifle, dass man über einen “raised” Bordstein einen Weg überqueren darf. Ich finde nichts Gegenteiliges, aber es klingt einfach grundfalsch
Wie ich schon im anderen Thread schreib: kerb=* gab es vor barrier=kerb, weswegen kerb=* auch ohne barrier=kerb verwendet wird/wurde und dieselbe Bedeutung hat. Die einzige wirklich abgesegnete Ausnahme ist highway=crossing, aber auch da wäre eine Variante von
sidewalk:<side>:kerb=*
kerb:<side>=*
immer noch besser als einfach nur kerb=*.
Im Prinzip macht iD es übrigens richtig, auch wenn es in diesem Zusammenhang Müll produziert. kerb=* abseits von highway=crossing impliziert barrier=kerb.
Was ich auch nicht so ganz verstehe: Wenn ich mir unter anderem den problematischen Node 2439273273, dann sehe ich da auf Mapillary an der Bahnhaltestelle sehr wohl einen abgesenkten Bordstein und keinen erhöhten. Quasi ein Überweg, nur ohne Markierungen. Von daher verstehe ich nicht so ganz, wie der SC-User da auf kerb=raised kommt.
Die StreetComplete-Ausnahme (kerb=raisedohnehighway=crossing) ist zwar nicht “abgesegnet”, aber es ist doch nur eine Frage der Zeit, bis das die häufigste Verwendung von kerb=* abseits von barrier=kerb ist. In Berlin z.B. gibt es 763 Knoten mit kerb ohne irgendeinen highway Tag und ohne barrier=kerb. Davon sind 371 kerb=raised, und davon wiederum liegen 352 auf Straßen wie residential, unclassified etc. Fast alle davon dürften also nicht barrier=kerb implizieren.
Praktisch ist jetzt die Frage, wie verhindern wir, dass die alle mit barrier=kerb getaggt werden und zu den angesprochenen Routingproblemen führen. Entweder StreetComplete setzt einen anderen Tag oder iD hört auf, Nutzer aufzufordern, barrier=kerb dranzuklatschen. Den englischen Thread hatte ich erstellt, um herauszufinden, welche dieser Lösungen die Community für besser hält (oder beide). Wenn nicht eins davon passiert, müssen die Router irgendwann barrier=kerb ganz ignorieren. Valhalla und GraphHopper tun das ja anscheinend bereits, wenn man sich die Beispiele am Anfang des Threads genauer ansieht. (Nur OSRM nimmt den langen Umweg in Kauf, um barrier=kerb zu vermeiden.)