Unrealistisches Routing 30er- vs. 50er-Straßen

Communities Deutschland (Germany)
21

OSRM bewertet im Radmodus schlechte (dirt) Pfade (path) besser als gute Pfade.
Die Routingergebnisse sind auch nachprüfbar unlogisch.

Da muss irgendwo ein riesen Bug sein. Ich vermute da hat jemand Multiplikation und Division beim Anbringen der Gewichtsfaktoren verwechselt. Es ist nur highway=path betroffen.

Es besteht natürlich noch die Möglichkeit, dass die (Geschwindigkeit in der) Debug-Karte falsch berechnet ist. Bei der Fußgänger-Debug-Karte scheint dies der falls zu sein. Die Rates sind gleich aber die Geschwindigkeiten der Pfade (path) sind 4 x höher als die der Fußwege (footway).
Konnte das aber beim Routing nicht nachweisen

Bei meinem Fahrradbeispiel lässt sich mit den Geschwindigkeiten hingegen erklären, warum er lieber auf der falschen Straßenseite den längeren Weg in verbotener Richtung nimmt anstatt auf dem kurzen richtigen Radweg zu fahren.

1 Like
22

Ich hab irgendwie das gefühl das das was man in der Debug karte sieht nicht zu dem bicycle profile im OSRM backend passt.

Denn dort ist ganz klar das oneways in die andere richtung “inaccessible” sind. Also dürften die GAR NICHT verwendet werden. Hier sieht man aber im Debug layer das die nur “schlecht” sind.

Weiss jemand wo das profile liegt was hier zugrunde liegt?

Flo

23

https://routing.openstreetmap.de/about.html

The routing profiles used for these servers. They differ from the profiles included with the OSRM-backend sources, especially the bike and foot profiles.

car: worldwide
bike: worldwide
foot: worldwide

Ja - das erklärt es - Passte überhaupt nicht zu den OSRM default profiles.

Wenn man in das profile guckt dann ist “path” per-se erstmal deutlich schlechte:

126   bicycle_speeds = {
127     cycleway       = {1.3, 16},
[ ... ]
139     track          = {0.8, 13},
140     path           = {0.4,  8},
141     footway        = {0.35, 6},
142     pedestrian     = {0.35, 6},
143     steps          = {0.05, 1}
144   },

Also halb so schell - Wird dann aber später noch besser gerechnet aber nur wenn da ein bicycle=yes drauf ist - bicycle=designated kennt das profile nicht:

217     speed_path = {
218       sac_scale = 0,
219       foot = { designated = {0.2, 8},
220                yes = {0.35, 8} },
221       bicycle = { yes = {1.2, 16} },
222       ["mtb:scale"] = nil
223     }

Das ist zumindest meine interpretation - Damit ist “path” + “bicycle=designated” halb so schnell wie ein “cycleway” …

Bugs also hier hin - Nicht in das OSRM Backend repository:

Flo

24

Auf der OSRM Demo Seite passiert das gleiche. Und dort sind die debugkarten verlinkt. Vielleicht ist ja das Backend die falsche Stelle allerdings sollte OSRM schon sein eigenes Profil benutzen und nur dazu passende Debugkarten. Sonst ist das auch ein Fehler.

https://map.project-osrm.org/?z=15&center=52.389600%2C9.758585&loc=52.389349%2C9.754447&loc=52.382129%2C9.765961&hl=en&alt=0&srv=1

25

https://map.project-osrm.org/

Unten auf “About this service” und dann auf “Routing profiles” - So habe ich das gefunden.

Und jeder darf beliebige profiles nehmen. OSRM routet nur mit den weights die die profile zurückgeben. Es hängt alles am Profil nicht an der OSRM engine. Die profiles die dabei sind sind “Beispielprofile” …

Flo

26

Das Fahrrad-Routing auf https://map.project-osrm.org kommt von routing.openstreetmap.de/routed-bike/route/v1/driving/....
Bei routing.openstreetmap.de und map.project-osrm.org handelt es sich sogar um den selben Server. Somit ist auch zu erwarten, dass sich die Ergebnisse nicht unterscheiden. :smiley:

27

Könnte es sein, dass die Profile selbst nicht fehlerhaft sind, aber einen Bug in der OSRM engine aufdecken oder ist das ausgeschlossen?

28

Ich glaube auch nicht das der eigentliche Routing-Algorithmus falsch ist, sondern die Berechnung der Kosten=Gewichte. Das Fahrrad-Profil (cbf-routing-profiles/bike.lua at master · fossgis-routing-server/cbf-routing-profiles · GitHub) sieht erstmal nicht grob falsch aus.
Jetzt müsste man rausfinden was die einzelnen Parameter bedeuten und wie sie verrechnet werden, und da sind wir im backend

mode.inaccessible klingt nach gesperrt, die Debugkarte sieht eher nach Rate * 0,5 aus)
Die “speeds” (bicycle_speeds, surface_speeds, tracktype_speeds) werden laut code mit mit der min-Funktion (cbf-routing-profiles/way_handlers_weight.lua at master · fossgis-routing-server/cbf-routing-profiles · GitHub) verrechnet - was dann allen paths maximal eine Rate von 0.4 geben würde - das wäre für die deutschen gemeinsamen und getrennten Rad-Fußwege ziemlich doof.

Mir ist unklar was mit speed_path passiert. Da wird was multipliziert.
Die Werte in der Debug-Karte kann ich mir kein Stück erklären.

29

Nope - Das Backend macht eine Lösung des Graphen - Die geschwindigkeiten/gewichtigungen werden beim preprocessing durch die profiles ermittelt. Der Algorithmus ist für ALLE graphen derselbe. Es werden keine entscheidungen ausser “kosten/weight” des graphen im Backend getroffen. Das Backend interessieren noch nichteinmal OSM Tags.

Wenn man sich mit dem Graph Problem im ursprung aka Dijkstra oder A* beschäftigt gibt ist es sehr unwahrschlich das sich das Problem NUR HIER manifestiert.

Die zugrundeliegenden Algorithment sind relativ trivial. Das Preprocessing ist die Magie. Wie übersetzt man OSM tags in gewichtungen/kosten des Graphen. Und as findet AUSSCHLIESSLICH im profile statt. Deshalb ist die OSRM engine für alle transportmethoden identisch. Also Modalagnostisch. Es ist dem Egal ob du dem einen Car, Foot oder Bike graphen gibts. Alles nur graph, mathematisch zu lösen einen weg im graphen mit den geringsten kosten zu finden.
Die Kosten bestimmt das Profil.

Ich halte es für SEHR unwahrscheinlich das im graph code im OSRM ein Bug ist der sich so auswirkt. Der Punkt ist ja auch das wir die unterschiedlichen gewichtungen im Debug Layer sehen. Das ist aber ja nur eine visualisierung der gewichtungen die aus dem profile purzeln.

Flo

30

OSRM setzt also komplett auf die Vorverarbeitung mit Hilfe der Profile. Die OSRM Engine erhält nur die fertigen Gewichtungen [1], welche nachträglich nicht verändert werden können. Es befinden sich alle zur Berechnung der Gewichte [1] benötigten Funktionen in den Profilen selbst, es muss also an den Profilen liegen.
Mir war nicht klar, dass mit OSRM kein dynamisches Routing möglich ist.

[1] von Objekten, wie etwa Wegen und Punkt-Barrieren

31

@flohoff. Entwickler “datendelphin” ist in beiden Projekten aktiv und hat sich dem angenommen.

4 Likes