Hi,
zur Zeit beschäftige ich mich etwas mit dem planen von Fahrrad/Rennrad Touren. Aber irgendwie hat jedes Routing seine Macken. Verglichen habe ich beispielhaft eine sehr kurze Route. Wenn es bei kurzen Entfernungen nicht gut funktioniert wird es bei langen wohl auch nicht besser:
Maps.Openrouteservice.org (ORS): https://maps.openrouteservice.org/directions?n1=48.548426&n2=12.096763&n3=16&a=48.55322,12.104509,48.546473,12.079511&b=1f&c=0&g1=-1&g2=0&h2=3&k1=en-US&k2=km
Hier gibt es mehrere Fahrradoptionen:
a) Fahrrad „E-Bike“:
2,1 km, 43m aufsteigend. (direkter Weg)
b) Fahrrad “Normal” und “sichere Route”: 2,8 km, 31m aufsteigend:
Anscheinend werden auch geringe Steigungen (max. 5%) vermieden und dadurch ein Umweg von ca. 700m in Kauf genommen.
c) Fahrrad “Trekkingrad”: 3,4 km, 15m aufsteigend.
Noch größerer Umweg.
d) Fahrrad “Mountainbike”: 2,6 km, 49m aufsteigend.
Maximale “Steigung” von 49m
e) Fahrrad “Rennrad”: 2,8 km, 31m aufsteigend:
Es werden auch Fusswege verwendet (Ecke Unterwerkstr.). Die kürzeste Verbindung wird nicht gefunden - auch nicht mit der Option “maximale Steiung” 15%.
ORS hat viele Zusatzinformationen, wie Oberflächenbeschaffenheit, Wegtypen, Steigung usw. die für eine Tourenplanung oder zur Tag-Überprüfung sehr nützlich sind. Deshalb wäre OSR mein Favorit.
Einige Einstellmöglichkeiten, wie z.B. max. Steigung oder Fitnesszustand werden aber anscheinend ignoriert, oder erhalten nicht die nötige Priorität. (Auch manche Radwege mit Bicycle=official bleiben beim Fahrradrouting unberücksichtigt.)
Kennt ihr ein besseres Online-Routing? Wie kann man mithelfen, damit die ORS-Ergebnissen besser werden?
Maximale Steigung wäre technisch natürlich kein Problem. Du kannst allerdings nicht damit rechnen, dass diese Information in OSM an allen ansteigenden Wegen dransteht. Aber Fitnesszustand? Wie willst du das in eine verifizierbare Größe packen?
Den nutze ich auch am meisten, obwohl er manchmal ziemlichen “Mist” routet:
Beim Profil “trekking” werden footways (-> Radfahrverbot!) bevorzugt gegen Anwohnerstraßen (residential + maxspeed = 30).
Wobei trekking = (Berg)wandern bedeutet. Ist das gar kein Routingprofil für Radfahrer?
Da sich aber kein Mensch mit Trekkingschuhen und einem Trekkingrucksack auf ein Trekkingrad setzt, ist „Trekking“ als Bezeichnung eines Routingprofiles durchaus erklärungsbedürftig.
Ein solcher Vergleich ist immer etwas problematisch.
Ich denke, man müsste zunächst sicherstellen, dass in dem betroffenen Gebiet in den letzten Tagen nichts routing-relevantes in OSM geändert wurde, also alle Router auf die gleichen Daten zugreifen, auch die, die nur alle n Tage updaten.
Ich verwende die Programme vor allem für die Urlaubsplanung. Schwerpunkt ist also eine “schöne” Strecke zu finden und nicht die “schnellste” oder “kürzeste”. Dummerweise kann ein Router leicht eine kurze Route finden, relativ leicht eine schnelle, aber Kriterien für schön sind halt
sehr subjektiv. Offensichtlich vermeiden manche Fahhrad-Router lieber ein paar Höhenmeter als ein paar hundert Meter Umweg.
Ob das die Strecke schöner macht?
Ansonsten: BRouter scheint mir auch ein guter Ansatz zu sein. Gut zu bediehnen, auskunftsfreudig und konfigurierbar.
Über die Tempo-30-Straße ist der Weg ca. 10 m länger.
Die Bewertungen der Routen geschieht über virtuelle “Kosten” (entspricht Aufwand).
In dem verlinkten Beispiel:
highway = footway: cost = 1050 $/km gegenüber
highway = residential: cost = 1150 $/km.
Als Hauptproblem sehe ich die default-Einstellungen für highway = footway. Die Benutzung ist viel zu “billig”.
Weil man dort nicht fahren darf, sondern schieben muss und deshalb nur langsam voran kommt, müssten die “Kosten” gegenüber fahrbaren Strecken (z. B. highway = residential|service|path) viel höher sein.
Hatte vorher nur einen viel längeren Weg über die Thüringer Straße gesehen. Ich denke, das für den Weg über die Tempo-30-Straße vor allem die 2 Abbiegevorgänge ins Gewicht fallen, wobei mich da wiederum wundert, dass ein highway=service+service=driveway gegenüber dem hw=path + bicycle=yes bevorzugt wird. Anscheinend wird das service=driveway nicht als ein access=destination gewertet.
Da muß ich Dir entschieden widersprechen. Ich habe schon Bergwanderer gesehen, die für den Weg zum “Startpunkt” ihrer Tour ein Trekking-Rad benutzt haben.
Ja stimmt wohl, bei “trekking” (was ein Radfahr-Profil ist…) hat highway=footway kein implizites Radfahrverbot.
Die expliziten (bicycle=no|dismount) greifen aber natürlich, führen aber in dm Fall, dass Fussgänger erlaubt sind, auch nicht zum Verbot, sondern nur zur Bewertung als Schiebestrecke.
Hier ist der relevante Teil des trekking-Profils, dass in Deinem Beispeil den footway “freigibt”:
assign isbike = or bicycle=yes or or bicycle=permissive bicycle=designated lcn=yes
assign ispaved = surface=paved|asphalt|concrete|paving_stones
assign isunpaved = not or surface= or ispaved surface=fine_gravel|cobblestone
assign probablyGood = or ispaved and isbike not isunpaved
....
assign costfactor =
...
else if ( highway=...|footway ) then
(
...
else ( if probablyGood then 1.0 else 5.0 )
)
Es ist also die Kombination aus surface-tagging ("surfave=paving_stones) und die Abwesenheit von explizitem access tagging (bicyle=no), die in diesem Fall zu dem unplausiblen Ergebnis führt.
Ich denke aber mal, dass das nicht so “super-typisch” ist und es andersrum wahrscheinlich genug Radwege gibt, die als Fussweg getagged sind, so dass ich es ohne eine grössere Testanstrengung auch nicht so einfach ändern will.
