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

Communities Deutschland (Germany)
,
22

Ich habe den Quellcode von OSRM studiert :closed_book: . 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.
23

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
24

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
25

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

26

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.

27

Außer vielleicht noch an Bushaltestellen und Bussteigen.

1 Like
28

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. :person_shrugging:

29

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
30

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.

31

Das waren sicher Zeiten :joy:

32

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
33

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

1 Like
34

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.

image
image1063×675 29.1 KB

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.
2 Likes
35

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

36

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.

1 Like
37

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.

38

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

39

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.

1 Like
40

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.

2 Likes
41

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

1 Like