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

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