Das Problem ist, dass kerb=raised als sperrend betrachtet wird, auch ohnebarrier=kerb und kerb=rolled noch fehlt in den Ausnahmen¹:
local kerb = node:get_value_by_key("kerb")
local highway = node:get_value_by_key("highway")
local flat_kerb = kerb and ("lowered" == kerb or "flush" == kerb)
local highway_crossing_kerb = barrier == "kerb" and highway and highway == "crossing"
if not profile.barrier_whitelist[barrier]
and not flat_kerb
and not highway_crossing_kerb then
result.barrier = true
end
Also barriersbarrier=kerb sind für Autos immer sperrend, wenn sie weder flush, noch lowered und nicht Teil eines highway=crossing+barrier=kerb sind. Demnach ist das derzeitige SC-Verhalten, kerb=raised ohne highway=crossing zu erfassen unproblematisch, weil es zumindest das OSRM-Routing nicht kaputt macht. Andere Router müsste man sich ansehen~~, aber insgesamt … suboptimal~~.
Problematisch ist auch, dass OSRM das kerb=raised am highway=crossing nur ignoriert, wenn barrier=kerb gesetzt ist. Das sollte man auch definitiv fixen.
¹: Ich habe den für uns irrelevanten Teil des Codes, der sich nicht auf Kerbs bezieht, zur besseren Lesbarkeit entfernt
Update: hab meinen Fehler befunden und das Ganze angepasst
dieser Graph zeigt halt nur die Anfangszeit, bis zu diesem Zeitpunkt würde ich es auch so sehen dass kerb=* ohne barrier=kerb trotzdem einen Bordstein an dieser Stelle gemeint haben kann, aber dann hat barrier=kerb kerb=* “überholt” und die beiden sind synchron und steil gewachsen, auf das hundertfache der Anzahl von 2013/14. Die Nutzungszahlen in dem dargestellten Zeitraum sind eher nicht relevant für die heutige Situation, angesichts des Vorkommens von Bordsteinen ist ein Wert unter 10.000 quasi gar nichts, im Vergleich dazu gab es 2013/14 schon eine Million highway=crossing (wovon es insgesamt sicherlich deutlich weniger gibt in der Welt als Bordsteine). Aktuell haben 65% aller barrier=kerb ein kerb=* und 66% der kerb=* ein barrier. Zugegeben sind das noch ein Drittel kerb=* ohne barrier, aber eben auch zwei Drittel mit.
TLDR; ich gebe dir insofern Recht, als es anfangs nicht ganz klar war, was “kerb” bedeuten soll, und sicherlich viele davon explizite Bordsteine meinten, aber dass das bis heute so sein soll stimmt m.E. nur noch für eine Minderheit.
Insgesamt denke ich sind wir uns einig, dass man “barrier=kerb” nur setzen sollte wo es auch einen Bordstein gibt (sei es entlang der Bordsteinlinie als way oder am Kreuzungspunkt einer Querung mit dem Bordstein als node), und dass “kerb” einen Bordstein beschreibt (das kann sowohl “abstrakt” auf einem highway=crossing oder z.B. auch auf einem highway-way sein, also auch als Ergänzung zu einem barrier=kerb). Insofern ist barrier=kerb auf einem highway=crossing falsch, das kommt auch nur gut tausenmal vor, also 0,02%, und sollte man vermutlich fixen durch Entfernen von barrier=kerb (aber wie immer am besten nur mit Ortskenntnis).
Ein kerb=* ohne barrier auf einem highway der eine Straße repräsentiert würde ich ähnlich wie sidewalk=yes als Eigenschaft sehen, die nicht bedeutet dass dort die Autos über einen Bordstein fahren, sondern dass sich das auf den Bordstein am Straßenrand bezieht. Stellen wo man mit dem Auto über einen Bordstein fährt (z.B. an den Ein-/Ausfahrten von verkehrsberuhigten Bereichen, ggf. mit kerb=flush oder lowered) kann man ja immer noch mit barrier=kerb explizit kennzeichnen.
Die 3x kerb (mit Insel sogar 5x) halte ich für nicht so problematisch. Ja es hat ein bisschen Redundanz aber die Programme können ja selbst entscheiden wie sie mit kerb=* ohne barrier=kerb umgehen.
Ich sehe zwar nicht, wie sich das aus dem Code ergibt, aber die Version von OSRM auf openstreetmap.org, die barrier=kerb kerb=raised vermeidet, hat keine Probleme mit kerb=raised ohne barrier=kerb.
Dann haben wir uns wohl falsch verstanden. Ich meinte nicht, dass heute noch eine relevante Anzahl von Nodes von damals existiert, die nur kerb=* hat. Es ging mir nur darum zu zeigen, dass das reine Tagging von kerb=* älter ist als barrier=kerb und diese ersten Kerbs heute eine definitiv undefinierte Bedeutung haben.
Ja, Denkfehler gefunden, sorry. Also natürlich läuft der Router nur dort hinein, wenn es sich um eine barrier=* handelt. Demnach werden kerb=* ohne barrier=kerb komplett ignoriert und die Ausnahmeregelung für highway=crossing ergibt auf einmal wieder Sinn
Ich hab mein Posting dahingehend angepasst – war zu sehr im Mittagsmodus
Das kommt aus dem kerb-Proposal und wurde 2016 in die Doku aufgenommen. Ist ja auch sinnvoll. Das jetzt zu ändern auf crossing:kerb ist ein wenig spät.
Sagen wir mal so: ein kerb=raised mit nennenswerter Höhe dürfte im Alltagsbetrieb verdammt unpraktisch sein, daher dürfte das an Stellen mit regelmäßigen Kfz-Verkehr nicht zu finden sein …
Es wird also wohl nur um äußerst selten befahrene Stellen gehen wie Grundstückszufahrten gehen, also Grundstückszufahrten oder Wohnwege zu 1-n Häusern, D.h. hinter dem Bordstein wird wohl Privatgelände sein und das Befahren ja/nein ist Sache des Eigentümers,zugleich wohl oft Halter des Kfz.
Es gab im verkehrsportal.de wohl auch schon Meinungen, dass man Grundstücksausfahrten über öff. Gehwege hinweg mit Absenkung nicht ungenehmigt und überall anlegen darf, das kann aber von den Bauordnungen der Länder und Kommunen etc. abhängen. Von der StVO her gibt es m.E. kein Hemmnis, ein Grundstück an beliebigen Stellen (nachrangig) zu verlassen, auch nicht über hohe Bordsteine.
Ebenso nicht, wenn man über Wege irgendwo auf eine Straße trifft und der Bordstein dort hoch ist. Wird mit Autos seltener passieren, mit Fahrrädern schon öfters. Grünanlagen sind hier seit einigen Jahren defaultmäßig für Radler frei und nicht jeder Grünanlagenzugang ist abgesenkt, stört rechtlich m.E. nicht.
Ein anderes Thema sind solche Stellen wie aus dem einen Bsp.:
barrier=kerb
kerb=raised
kerb:height=0.04
tactile_paving=incorrect
wheelchair=limited
Da ist der raised-kerb ja sogar alltagstauglich …
So wie “raised” kerb derzeit definiert ist, nämlich alles über 3cm Höhe, gibt es sicher zigtausend solcher Stellen. Wenn “raised” kerb wirklich einen erhöhten oder auch einen normalen Bordstein bezeichnen würde, dann wäre es in der Tat selten zum Überfahren gedacht.
Da geht es, soweit ich das sehe, nur um barrier=kerb auf highway=crossing. Dass es davon so viele gibt, liegt an dem älteren Bug in iD, der inzwischen behoben ist.
Es wäre schade, wenn Router alle barrier=kerb (ohne highway=crossing) ignorieren, nur weil es so viele Taggingfehler gibt.
Ja, da muss man sich entscheiden. Entweder akzeptiert man die Tagging-Fehler, dann müssen die Router diese “Barriere” ignorieren oder man sorgt dafür dass die Fehler nicht mehr passieren. Im Moment sehe ich nicht, dass ein großer Elan da ist, die Fehler zu fixen (siehe Post #1).
Ich weiß nicht, wie die Contributors Fehlerberichte priorisieren. Sind ja vermutlich auch nur Freiwillige. Bisher hat sich das anscheinend niemand angeschaut. Ich lade euch alle ein, im Issue Tracker ein zu geben.
Außerdem habe ich das als Taggingfehler im Wiki zu barrier=kerb dokumentiert und im Wiki zu kerb= dokumentiert, was man machen kann, wenn man kerb=raised sieht: nämlich, wo es passt, ein entsprechendes crossing, z.B. crossing=no oder highway=crossing crossing=unmarked zu setzen. Ich lade euch ein, das gleiche zu tun. Das hilft Routern, ist präziser, und verhindert nebenbei, dass iD seine Nutzer dazu drängt, barrier=kerb dazuzusetzen.
Leider passt manchmal weder crossing=no noch unmarked nicht. Bis das Problem in iD behoben ist, macht es meiner Meinung nach nicht so viel Sinn, an solchen Stellen barrier=kerb massenweise zu entfernen. (Wo es mir auffällt, mache ich es natürlich trotzdem.) Aber das wird dann nur vom nächsten iD-Nutzer wieder hinzugefügt.
Wenn der iD-Fehler behoben ist, können wir uns darum kümmern, ein gezieltes Retaggen zu organisieren (z.B. mit Maproulette und Mapillary?)
Nebenbei könnte natürlich jemand bei StreetComplete nachfragen, ob sie es in Erwägung ziehen würden, lieber einen anderen Tag zu setzen, z.B. sidewalk:both:kerb=raised.
Auf jeden Fall! barrier=kerb gehört entfernt. Wenn dann da anschließend nur noch kerb=raised steht, kann man überlegen, ein highway=crossing oder crossing=no hinzuzufügen, wenn es passt.
Hab’ mal nen neuen Bug auf github aufgemacht. Der Power-Mapper aus München, der dort die Barrieren gesetzt hat ist ebenfalls der Meinung, dass dies ein Router- und kein Mapping-Problem ist.
Also, meine lieben Routerprogrammierer: Einfach das Wiki (access=yes default) beachten und barrier=kerb in die Whitelist setzen.
zu geben.