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

[dieterdreist]

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.

[Elefant_aus_Wuppertal (Lukas)]

Das waren sicher Zeiten

[osmuser63783]

Zum Routingproblem:

@chris66

Ich habe den Quellcode von OSRM studiert . Demnach:

• Wird kerb=lowered und kerb=flush als nicht sperrend betrachtet

Es müsste also mal jemand bei OSRM Bescheid sagen, dass zumindest kerb=rolled auch für Autos überquerbar ist.

@chris66

• Wird ansonsten barrier=kerb nur als sperrend betrachtet, wenn nicht zusätzlich hw=crossing gesetzt 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.

[chris66]

@osmuser63783

Es müsste also mal jemand bei OSRM Bescheid sagen, dass zumindest kerb=rolled auch für Autos überquerbar ist.

Meine Meinung: es sollte schlicht der default-Wert (implies access yes) beachtet werden.

[Nadjita]

@dieterdreist

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

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.

@chris66

Meine Meinung: es sollte schlicht der default-Wert (implies access yes) beachtet werden.

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

1. Ein Schema entwerfen, mit dem man die Bordsteinhöhe links/rechts der Straße/des Gehweges erfassen kann. Vorschläge gibt’s ja
2. SC dazu bringen, dieses Schema zu nutzen
3. Die kerb=raised an highway-Kreuzungspunkten ohne highway=crossing umtaggen
4. Die restlichen kerb=* an highway=* der Reihe nach entweder auf das neue Tagging umstellen, oder mit barrier=kerb versehen.

[Langlaeufer]

barrier=kerb wurde in OSRM angebeblich doch schon gefixed oder hatte ich das falsch verstanden?

@dooley

Aua. Ich denke, da passe ich das Profil an. Sollte ja durch Aufnahme von “kerb” in die Whitelist funktionieren.

barrier_whitelist = Set {
‘cattle_grid’,
‘border_control’,
‘toll_booth’,
‘sally_port’,
‘gate’,
‘lift_gate’,
‘no’,
‘entrance’,
‘height_restrictor’,
‘kerb’
},

[Langlaeufer]

Also ich würde erwarten:

node mit barrier=kerb kerb=*
→ gilt für alle Wege die den Knoten beinhalten

node mit highway=crossing und kerb=*
→ Kerb gilt nur für den kreuzenden Pfad/Fußweg/Radweg

way mit highway =* mit kerb=*
→ beschreibt die Bordsteine der Straße und hat gar keine Auswirkung auf
das Routing.

kerb=* ohne Objekt-tag (highway/barrier) - ist für mich ein Mapping Fehler.

Wir hatten ja neulich schon die Diskussion um access=tags an Knoten.
Da hätte ich ähnlich argumentiert. Auch die sind nur Attribute und sollten nur wirken, wenn das Element eine Klasse hat.

[dooley]

Das hast du tatsächlich falsch verstanden. Das habe ich nur in den von mir verwendetet Profilen lokal eingebaut - mit den offiziellen OSRM-Profilen habe ich nichts zu tun.

[flohoff]

Das barrier=kerb Probleme im routing macht ist doch ewig bekannt?!?! Ich hatte hier schonmal einen thread dazu gestartet meine ich.

barrier=* ist IMMER eine barrier. Für mich macht barrier=kerb + access=yes auch keinen Sinn. Ist das nun eine barrier oder nicht?

Flo

[Langlaeufer]

Danke für die Klarstellung.

Wenn tatsächlich nur kerb=raised zur Sperrung der Straße führt (und nicht lowered und flush), liegt genau genommen ja auch gar kein Fehler im Router vor, sondern nur eine strenge Auslegung der Barierre, und nicht der Router sollte angepasst werden sondern die Daten.

[chris66]

@flohoff

barrier=* ist IMMER eine barrier

Das ist trivial. Frage ist: Welche Barriere ist hart sperrend und welche schänkt nur die Bewegungsfreiheit etwas ein. Zu letzterem würde ich zählen, unter anderem:

• barrier=toll_booth
• barrier=entrance
• barrier =cycle_barrier
• barrier=cattle_grid
• barrier=kerb

etc. pp.

[OSM_RogerWilco]

Es kommt ganz darauf an, an welches Routing man denkt. Denkt man an Rollstuhl-Routing sieht die Welt ganz anders aus.

[Nadjita]

@chris66

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.

Das Problem ist, dass kerb=raised als sperrend betrachtet wird, auch ohne barrier=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

[dieterdreist]

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.

[skyper]

@dieterdreist

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.

Beim Betrachten der Vergangenheit bitte nicht Key:sloped_curb - OpenStreetMap Wiki vergessen.

[skyper]

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.

[osmuser63783]

@Nadjita

Das Problem ist, dass kerb=raised als sperrend betrachtet wird, auch ohne barrier=kerb

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.

Beispiel: OpenStreetMap

[Langlaeufer]

highway=crossing mit barrier=kerb ab einem Punkt halte ich auch für großen Unsinn. Das kann nur zu Missverständnissen führen.

[milet]

Wo kommt denn das kerb=* an highway=crossing -Knoten überhaupt her?
Die highway=crossing-Wikiseite schlägt das doch gar nicht vor!?

Eigentlich hätte man ein crossing:kerb=* einführen sollen. Das wäre wenigstens nicht so mehrdeutig.

[Nadjita]

@dieterdreist

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.

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.

@osmuser63783

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.

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

@milet

Wo kommt denn das kerb=* an highway=crossing -Knoten überhaupt her?
Die highway=crossing-Wikiseite schlägt das doch gar nicht vor!?

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.