**Mich wundert, daß BRouter den purpurfarbenen Weg, der mit Absteigen und Aufwärts-Schieben hoch zur Brücke verbunden ist, statt des grün-gestrichelten Weges vorschlägt, der völlig unproblematisch ist. **
Gibt’s in den OSM-Daten irgendwelche Tags, die dieses Routing provozieren?
Wenn man sich das in google Maps ansieht geht dieser V-förmige Weg nicht hoch zur Brücke sondern führt leicht bergab. Vielleicht nimmt Brouter diesen Weg weil er ein “paar Meter” eher auf dem Radweg mündet als der Weg über die Werftstraße?
sind die Kosten geringer (551 | 1) als bei der anderen Route über die “Werftstr.” (abgekürzt!) = 634 | 1,34 - wie auch immer die Kosten berechnet werden.
Beim Höhenprofil sieht man, dass die Werftstraße wohl einen steileren Anstieg hat (zw. 0,28 und 0.36 km) … in den Kalkulationen von brouter, evtl. nicht in Realität
Es gibt ein Profil “Treckingrad ignoriere Radrouten”, dann routet brouter über die Werftstraße. Nach Aktenlage ist das steile Stück wohl auch wunderbar zum Fahrradfahren geeignet, sonst hätte man für die Route “Grüner Ring Hannover” eine andere Wegführung gewählt. Über die Tannenbergallee im weiteren Verlauf führen ebenfalls ein paar Radrouten, da denkt sich halt der Router, radeln sei da besonders schön…
In allen Rennrad-Profilen sowie Velomobil und Liegerad wird die grüne Route genommen. Trekkingrad bevorzugt vermutlich kleine Wege vor normalen Straßen.
Edit: Wenn man auf dem Zickzackweg absteigen und schieben muss (zB weil da ein Zusatzschild “Radfahrer absteigen” steht), gehört bicycle=dismount dran, und dann dürfte sich auch das Routing ändern.
Wähle mal bei BRouter “Trekkingrad (ignoriere Radrouten)” … dann kommt das gewünschte Ergebnis. So wie bei Dir die Route ausgespuckt wird, sind 1, bzw. mehrere Radrouten erfasst.
Hmm. Längerer Weg und Aufwärts-Schieben ist kostengünstiger als kürzerer, ebener Weg ohne Absteigen? Das leuchtet mir nicht ein: offenbar sind auch BRouters Wege unerforschlich.
Nö. Wie die Kosten zustande kommen, kannst du unter Schraubenschlüssel > Profil bis ins letzte Detail erforschen. Vielleicht reichen dir schon die ersten vier Zeilen, um BRouters Wege zu verstehen.
Die Notwendigkeit des Aufwärtschiebens muss erst mal erkannt werden, um es berücksichtigen zu können. Die benutzten Höhendaten geben das offenbar so kleinräumig nicht her. Hintergründe siehe hier.
Auf die Bevorzugung von Rad- und Nebenwegen in dem Profil wurd ja schon hingewiesen.
Das Trekkingrad profil beforzügt Fahrradrouten sehr. So sehr das Fahrradrouten und die kurven da in keine extra Kosten bekommen.
Daher durchschnittlich 1 cost.
Die Werftstraße bekommt wegen residential einen cost von 1.1 und weil stick_to_cycleroutes nicht gesetzt ist nochmal 0.05 und es gibt noch einen zuschlag weil es um die Ecke geht.
Deswegen 13% kurzer aber 34% weniger kosten.
Ich hab für Fahrradfahrten mein eigenes Profil gemacht was besser anschliesst an mein Fahrprofil.
Danke für die Info!Dasmuß man aber erst einmal wissen … Insofern werde ich künftig diesbezüglich “ignorieren” wählen.
**Ob “wunderbar”, sei mal dahingestellt: immerhin geht es bergauf und dann ist noch eine spitze Kehre zu befahren - s. Foto. Aber befahrbar ist der Weg tatsächlich; ich hatte es vom Vorbeifahren nur anders in Erinnerung: selbst bin ich da noch nie hochgefahren.
**
**Sicher? Manchmal fragt man sich, was sich solche Planer dabei gedacht haben. Und der Verlauf der Route ist inzwischen gegenüber der, die ich vor langer Zeit mal gefahren bin, an mehreren Stellen auch geändert worden.
**
Dann sollte man dem Router diese Logik vielleicht abgewöhnen?
# *** The trekking profile is for slow travel
# *** and avoiding car traffic, but still with
# *** a focus on approaching your destination
# *** efficiently.
Das Profil bevorzugt also langsames Reisen und vermeidet autobefahrene Straßen, bemüht sich aber dennoch darum, das Ziel zügig zu erreichen. Unter dieser Prämisse funktioniert es an der angemeckerten Stelle perfekt, würde ich sagen