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.
4 Likes
Ja, das kommt eben dabei raus wenn man Micromapping (Bordsteine mappen) mit Makromapping (aber nicht da wo sie wirklich sind, sondern generalisiert) mischt.
4 Likes
Warum sollte es nur für einen Weg gelten, wenn es auf beiden gesetzt ist? Würde ich z.B. für einen Poller auf einer Wegeskreuzung erwarten.
2 Likes
Auch das ist meist ein Mappingfehler, da das in der Realität sehr selten vorkommt.
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.
2 Likes
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.
5 Likes
Stellenweise muss man echt stark sein, bei den gruseligen Sachen, auf die man bei der Suche nach diesen barrier=kerb so stößt:
Achso, da sag ich jetz mal lieber nix zu… SCNR
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 
Wer’s nicht sieht: Da liegt ein hw=footway,footway=crossing auf einem hw=residential.
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.
1 Like
Die StreetComplete-Ausnahme (kerb=raised ohne highway=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.)
Ich habe den Quellcode von OSRM studiert 
. Demnach:
- Wird kerb=lowered und kerb=flush als nicht sperrend betrachtet
- Wird ansonsten barrier=kerb nur als sperrend betrachtet, wenn nicht zusätzlich hw=crossing gesetzt ist.
Ist sie doch schon, weil es früher kein barrier=kerb gab. Deswegen ist es ja auch so gefährlich, nur kerb=* zu setzen, denn das impliziert ja barrier=kerb!
1 Like
Ok. Dann sind wir uns in der Sache doch einig, oder? Wenn ich kerb=raised als einzigen Tag auf einem Knoten sehe, darf ich nicht einfach barrier=kerb dazu setzen, ohne nachzugucken, wer und warum hier den Tag gesetzt hat. Genau dazu fordert iD aber auf.
1 Like
Bei folgendem Node ist explizit motor_vehicle=no gesetzt, was bei einer Höhe von 15 cm ja vollkommen in Ordnung ist, da kommt man selbst mit einem nicht tiefergelegten BMW nicht unbeschadet darüber…
Ist nicht auch dieses “Grundverhalten” von SC in seiner Crossing-Quest da ein bisschen schwierig?
Wenn ich eine Situation hätte, in der ein Weg eine Straße kreuzt und da ist kein Überweg, sondern beide Bordsteinkantenseiten sind “Hochbordsteine”, dann käme ich niemals auf die Idee, kerb=raised auf die Straße zu setzen. Nein. Ich würde einfach zwei barrier=kerb + kerb=raised-Nodes da hin setzen, wo sich die barrier=kerb auch wirklich befinden. Also entlang des footways z. B., aber nicht auf dem Kreuzungsnode.
Ich verstehe, dass man dann noch irgendwie das Problem lösen müsste mit der Angabe, ob da jetzt ein Überweg vorhanden ist oder nicht, weil ich nicht weiß, ob man aus den beiden barrier-Nodes das dann schließen könnte. Weil der gemeinsame Node von Straße und Weg wäre dann ja nicht getaggt. Aber so, wie es jetzt ist, ist es auch Murks.
Außer vielleicht noch an Bushaltestellen und Bussteigen.
1 Like
Ja, das ist es aber bei einer echten Crossing auch. Selbst, wenn Du die kerbs separat erfasst hast, wird Dich SC fragen, welche Kerbs da sind, weil die Auswertung, dass da schon welche separat gemappt sind, zu umständlich ist. Dann hat man letztendlich 3x kerb und tactile paving, eben an den echten Nodes und dann nochmal an der highway=crossing. 