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. 
Einerseits verständlich, andererseits auch wieder nicht. Ich bin da nicht SCs Meinung, dass die kerb-Angabe immer auf dem Crossingnode sein muss. Wenn schon Micromappilg, dann richtig.
Bei cycleways sucht SC doch auch vor dem Aufploppen einer Quest womöglich gemappte cycleway-Ways in der Nähe, bevor es an einer Straße nach dem Vorhandensein eines straßenbegleitenden Radweges (cycleway=* an Straße) fragt.
1 Like
naja, für mich sehen die Daten eher anders aus, es scheint ziemlich klar, dass “kerb=*” als ergänzende Beschreibung von barrier=kerb gewachsen ist: http://taghistory.raifer.tech/#/kerb/&/barrier/kerb
Welches früher da war bin ich mir nicht sicher, in jedem Fall waren das damals ziemlich geringe Nutzungen, als ich das Proposal für einige damals neue barrier-Werte gemacht habe (glaube 2011), habe ich barrier=kerb mal mit aufgenommen, aber eigentlich hat zu dem Zeitpunkt noch niemand Bordsteine gemappt und es schien ein bisschen utopisch, dass man diesen Detailgrad in der Fläche erreichen würde.
Das waren sicher Zeiten 
Zum Routingproblem:
Es müsste also mal jemand bei OSRM Bescheid sagen, dass zumindest kerb=rolled auch für Autos überquerbar ist.
Es gab einen älteren Bug in iD, wo Nutzer auch bei einem highway=crossing mit kerb=* dazu aufgefordert wurden, barrier=kerb dazu zu setzen. Das ist inzwischen behoben. Hoffentlich geschieht das auch bald mit kerb=raised.
1 Like
Meine Meinung: es sollte schlicht der default-Wert (implies access yes) beachtet werden.
1 Like
Sieht für mich jetzt nicht so aus, wobei kerb=* dem barrier=kerb „nur“ um 2.000 voraus ist; viel öfter sollte es also auf Straßen, die keine Kreuzung sind, auch nicht vorkommen hüstel.
Ich halte access=yes für einen kerb=raised für absoluten Nonsens. Wer will denn über einen erhöhten Bordstein geroutet werden? Mir ist keine Straße bekannt, wo ein erhöhter Bordstein der „Verkehrsberuhigung“ dient, wohl aber genug Vorkommnisse, wo jemand dadurch die Bordsteinhöhe links und rechts der Straße meint. Wir sollten lieber
- Ein Schema entwerfen, mit dem man die Bordsteinhöhe links/rechts der Straße/des Gehweges erfassen kann. Vorschläge gibt’s ja
- SC dazu bringen, dieses Schema zu nutzen
- Die
kerb=raisedanhighway-Kreuzungspunkten ohnehighway=crossingumtaggen - Die restlichen
kerb=*anhighway=*der Reihe nach entweder auf das neue Tagging umstellen, oder mitbarrier=kerbversehen.
2 Likes
barrier=kerb wurde in OSRM angebeblich doch schon gefixed oder hatte ich das falsch verstanden?