Barrier=kerb kann zu Routing-Problemen führen (OSRM)

Vorgeschichte: Routing Dresden Graphhopper/Valhalla/OSRM

Das Problem ist leider nicht auf DD beschränkt:

Auch wenn laut Wiki access=yes impliziert ist (was von OSRM anscheinend nicht beachtet wird), wäre die Frage ob man’s trotzdem bereinigen sollte.

Anzahl Fälle in NRW: 56.

Overpass Abfrage zum Finden der kritischen Nodes:

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?

Da forsche ich noch. kerb=rolled zB. sperrt ebenfalls.

und kerb=regular :

1 Like

Es sollten nur nix, kerb=raised und kerb=yes sperren. Wenn Du da gerade eine Tabelle erstellst, wäre das prima :+1:

Ist es denn Konsenz, dass die Generalisierung der Bordstein-Position auf die Straße OK ist?

Wie genau meinst Du das? Ob es okay ist, die Bordsteinhöhe links und rechts mit barrier=kerb + kerb=* zu erfassen? Eher nicht…

Ich meine den Fall dass der Bordstein am Kreuzungspunkt Fußweg/Straße gemappt ist.
Laut Wiki soll dann nicht barrier=kerb gesetzt werden.

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.

:wink:

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 :wink:

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 :confused:

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.)