Hallo zusammen, kann mir jemand helfen? Was ist hier schiefgegangen? Wieso nimmt der Routenplaner einen riesigen Umweg, aber nur bei der Fahrradversion und berechnet die völlig falsche Fahrtzeit? (17 Minuten für 14 km)?
Ist das ein Bug im Mapping oder in der Routenfindung (Kantengewichtung etc.)?
Ja, da Valhalla und Graphhopper hier über die L39 gehen vermute ich eine ungünstige Gewichtung. Eventuell führt das sidewalk=no hier zu einer Herunterstufung.
Hmmm, komisch, bei diesem Beispiel ist es genau umgekehrt (OSRM nimmt die secondary, Graphhopper nicht):
Auf der L39 ist der Seitenstreifen problemlos mit dem Rad befahrbar, alternativ gibt es die Route über Sang und den Tömperweg, die hier allerdings auch nicht gezogen wird. Irgendetwas scheint hier nicht in Ordnung zu sein.
Hier ist auch ein merkwürdiges Routing… für Auto… in Fahrradstraße. Da schlägt sich Valhalla noch am besten. Graphhopper vermeidet die zu sehr…
Und der Seitenstreifen ist sogar schön getaggt mit shoulder=yes und cycleway:both=shoulder 
Das liegt wohl an vehicle=destination an der Straße “Am Stadion”, die deshalb komplett vermieden wird, sobald eine Straße ohne vehicle=destination vorhanden ist. Das ist im Wiki aber klar erläutert. “Zufahrt erlaubt, um ein Fahrtziel zu erreichen, dass auf anderen Wegen nicht erreicht werden kann.” Da das Ziel über die “Zufahrtsstraßen” erreicht werden kann, wird die Straße vom Algorithmus korrekt vermieden. Die Straße “Am Stadion” ist eine Fahrradstraße mit “Anlieger frei” und “Fahrschulausbildung frei”. vehicle=* macht hier keinen Sinn, da vehicle auch Fahrräder umfasst. Stattdessen müsste hier motor_vehicle=destination und driving_school=yes genutzt werden. Die Parkplätze von Freibad, Sportplatz und Eissporthalle benötigen access=customers.
Die Straße “Am Stadion” in Erding habe ich gefixt, muss ich nachher mal gucken, wie das aussieht, wenn der Cache leer ist.
Bei Fahrradstraße mit “Anlieger frei” ist streng genommen korrekt die Kombination aus vehicle=destination und bicycle=designated, weil andere nicht-motorisierte Fahrzeuge wie Kutschen auch ausgeschlossen sind.
Steht hier leider anders: DE:Tag:access=destination – OpenStreetMap Wiki
Ich kriege GraphHopper aber immer noch nicht dazu, den Parkplatz vom Freibad zu ingnorieren …
Aus der OSRM-Debug-Ansicht entnehme ich folgendes:
OSRM verwendet für die L 39 nur 15 km/h, während die Radwege auf dem Umweg mit 127 km/h bzw. ungefähr mit 65 km/h gewichtet werden.
Siehe: https://routing.openstreetmap.de/debug/bike.html#15.47/51.4304/6.2763
Das könnte den Umweg und die zu geringe Zeitangabe von OSRM erklären.
Das Mapping scheint richtig zu sein.
Das Fahrrad- und Fußgängerrouting von OSRM fand ich bisher meist nicht besonders gut.
dann ist das Wiki falsch. Die StVO sieht ausdrücklich vor:
Anderer Fahrzeugverkehr als Radverkehr sowie Elektrokleinstfahrzeuge im Sinne der eKFV darf Fahrradstraßen nicht benutzen
Und Kutschen sind nun mal Fahrzeuge.
Willkommen bei der Tour de France!
Woher kommt denn so eine unrealistische Gewichtung?
Laut https://routing.openstreetmap.de/about.html finden sich die verwendeten Routing-Profile hier:
https://github.com/fossgis-routing-server/cbf-routing-profiles
Nach kurzer Betrachtung des Profils konnte ich den Grund dafür nicht finden.
Das erinnert mich an Unrealistisches Routing 30er- vs. 50er-Straßen - #5 by Nadjita und die sich darauf beziehenden Antworten.
@Langlaeufer hatte die Bugs in Incorrect Bicycle Profile · Issue #13 · fossgis-routing-server/cbf-routing-profiles · GitHub und Incorrect weights for highway=path · Issue #6552 · Project-OSRM/osrm-backend · GitHub eingetragen.
Danke… hätte jetzt nicht gewusst was da ändern soll🙂
Nach näherer Betrachtung habe ich den Grund gefunden:
Festhalten, es sind statt 127 km/h sogar 1024 km/h (bei highway = path + foot = yes + bicycle = yes). 
Die 127 km/h in der Debug-Ansicht resultieren lediglich daraus, dass 1024 nicht in ein Byte passen (signed char geht von -128 bis +127), deshalb wird der Wert bei 127 gekappt:
void set_speed(unsigned int value)
{
add_property(m_layer.key_speed, m_layer.uint_index(std::min(value, 127u)));
}
Quelle: osrm-backend/src/engine/plugins/tile.cpp at v5.27.1 · Project-OSRM/osrm-backend · GitHub
Das betrifft wirklich nur die Debug-Ansicht, für die Routing-Entscheidung und die Zeitberechnung werden 1024 km/h verwendet.
So berechnen sich die 1024 km/h:
Relevante Werte aus der bike.lua:
bicycle_speeds = {
(...)
path = {0.4, 8},
(...)
}
speed_path = {
(...)
foot = { designated = {0.2, 8},
yes = {0.35, 8} },
bicycle = { yes = {1.2, 16} },
(...)
}
WayHandlers.adjust_speed_for_path (aus lib/way_handlers.lua) berechnet die Routing-Geschwindigkeit wie folgt:
path = 8 km/h
foot = 8
bicycle = 16
path * foot * bicycle = 1024 km/h
Vermutlich hat der Profil-Ersteller nicht bemerkt, dass es sich hier bei speed_path um Multiplikatoren und nicht um absolute Geschwindigkeiten handelt!
Das Fahrrad-Profil ist auf Zeitdauer (weight_name = 'duration') eingestellt, das Routing minimiert somit ausschließlich die Zeit.
Um zu verifizieren, dass der OSM-Server auch tatsächlich so rechnet, habe ich mir einen langen (um Rundungsungenauigkeiten möglichst gering zu halten, OSRM rundet Sekunden und Meter auf Zehntel) Weg Way: 80519499 | OpenStreetMap mit (highway = path + foot = yes + bicycle = yes) herausgesucht und über diesen geroutet:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bicycle&route=48.12709,8.52762;48.11293,8.51676#map=15/48.12002/8.52226
Hier noch die Debug-Ansicht mit den abgeschnittenen 127 km/h:
https://routing.openstreetmap.de/debug/bike.html#15/48.1191/8.5216
Antwort des OSM-Servers:
"weight_name":"duration","weight":6.3,"duration":6.3,"distance":1821.4
1821,4 Meter in 6,3 Sekunden ergibt 1040,8 km/h, das liegt nahe an den genannten 1024 km/h (somit kleine Rundungsungenauigkeiten).
OSRM-Profile lassen sich übrigens einfach debuggen, hier meine entsprechend angepasste Version (debug.lua), angelehnt an debug_example.lua:
--
-- You run your copy via the lua command line:
-- > cd profiles
-- > lua5.1 debug.lua
-- for better printing
local pprint = require('lib/pprint')
-- require the debug tool
local Debug = require('lib/profile_debugger')
-- load the profile we want to debug
Debug.load_profile('bike')
-- define some input tags. they would normally by extracted from OSM data,
-- but here we can set them manually which makes debugging the profile easier
local way = {
bicycle = 'yes',
foot = 'yes',
highway = 'path',
surface = 'paving_stones'
}
-- output will go here
local result = {}
-- call the way function
Debug.process_way(way,result)
-- print input and output
pprint(way)
print("=>")
pprint(result)
print("\n")
-- report what tags where fetched, and how many times
Debug.report_tag_fetches()
Ergebnis sind die bekannten 1024 km/h:
backward_speed = 1024
forward_speed = 1024
Um das Problem nochmals anhand eines Beispiels zu verdeutlichen:
Ein 68 km langer Weg mit highway = path + foot = yes + bicycle = yes (Routing-Geschwindigkeit 1024 km/h) würde gegenüber einem 1 km langen Weg mit highway = residential (Routing-Geschwindigkeit 15 km/h) bevorzugt!