bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.

r4n schrieb:
Gibt es eine Möglichkeit, dass Radwege bevorzugt werden? So wie es der Radlland-Bayern router macht, nur halt nicht auf Bayern beschränkt?
Zum Vergrößern anklicken....

Ich verwende dafür dann gerne das Profil "Trekkingrad". Zumindest bei meinen Versuchen bisher hat das ganz gut funktioniert.
Perfekt ist das natürlich nicht - wenn ein Flußradweg z.B. nen großen Bogen macht wird gerne abgekürzt.
 

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Muehi schrieb:
gerne das Profil "Trekkingrad".
Zum Vergrößern anklicken....
das lässt sich auch nochmal anpassen in dem man "stick_to_cycleroutes" anklickt

Bildschirmfoto vom 2022-09-09 09-01-29.png
 
Ich verwende dafür dann gerne das Profil "Trekkingrad".
So mach ich das auch.

Fahre oft Frei Schnauze oder mit einem Gravelprofil los und wenn ich nicht mehr mag, die Beine müde oder das Wetter schlecht werden, dann lass ich mich auf einer schnelleren Route zurückrouten, meist das Treckingprofil. (Hab die in Locus importiert.)
 
r4n schrieb:
Gibt es eine Möglichkeit, dass Radwege bevorzugt werden?
Zum Vergrößern anklicken....
In meinem Profil lässt sich das über die notcycleroutepenalty realisieren. Standardmäßig werden bei mir Wege, auf denen keine Radroute liegt, pauschal 3 % teurer (sprich weniger attraktiv) gemacht. Möchte man allerdings Radwege so stark priorisieren, dass selbst deutliche Abkürzungen nicht genommen werden, kann man den Wert auf 80 % (oder notfalls noch mehr) erhöhen, also: assign notcycleroutepenalty switch any_cycleroute 1.0 1.8.

Sowas ließe sich, wenn vielfach gewünscht, auch einfach als zusätzlichen prefer_cycle_routes Schalter einbauen.
 
quaelnix schrieb:
In meinem Profil lässt sich das über die notcycleroutepenalty realisieren. Standardmäßig werden bei mir Wege, auf denen keine Radroute liegt, pauschal 3 % teurer (sprich weniger attraktiv) gemacht. Möchte man allerdings Radwege so stark priorisieren, dass selbst deutliche Abkürzungen nicht genommen werden, kann man den Wert auf 80 % (oder notfalls noch mehr) erhöhen, also: assign notcycleroutepenalty switch any_cycleroute 1.0 1.8.

Sowas ließe sich, wenn vielfach gewünscht, auch einfach als zusätzlichen prefer_cycle_routes Schalter einbauen.
Zum Vergrößern anklicken....
Super, von mir aus gewünscht!
 
@r4n meinst Du Radwege oder Radrouten?
Falls Radrouten gemeint ist, könntest Du die im Bikerouter verfügbaren Profile
"navbar.profile.Trekking-FCR-dry" oder
"navbar.profile.Trekking-FCR-wet"
ausprobieren.
"fcr" bedeutet "follow cycle routes".

Im github des Routingprofil heißt es dazu:
1662710262720.png
 
humhum schrieb:
@r4n meinst Du Radwege oder Radrouten?
Falls Radrouten gemeint ist, könntest Du die im Bikerouter verfügbaren Profile
"navbar.profile.Trekking-FCR-dry" oder
"navbar.profile.Trekking-FCR-wet"
ausprobieren.
"fcr" bedeutet "follow cycle routes".

Im github des Routingprofil heißt es dazu:
Anhang anzeigen 1547625
Zum Vergrößern anklicken....

Wenn ich das richtig interpretiere, meine ich Radrouten - das sind doch die Radwege, wie z. B. Main-Radweg oder so. Radwege wäre dann alles, was in der Stadt zum Beispiel für Räder angelegt ist? Dann meine ich tatsächlich Radrouten.

Danke!
 
Ah cool, danke dir, gibt schonmal ganz andere Ergebnisse.

Ich jongliere noch ein wenig mit den Profilen, und hab für mich noch nicht so das passende gefunden, wenn ich größere Runden drehen will. Ich habe hier am Alpenrand das Problem, dass die Gravelprofile sehr auf Schotter aus sind, und dafür überproportional Höhenmeter mitnehmen, die ich mir anders ersparen könnte.
Will ich z.B. von mir nach Garmisch, dann sieht die Situation wie folgt aus.
Gravel schnell macht 58 km, 275hm
alle anderen Gravelprofile nehmen Umwege über verschiedene Voralpenhügel und Endmoränen, da dort viele, gut zum Graveln geeignete Forstwege vorhanden sind. Ist zwar soweit schön, ergibt aber z.B. bei
Gravel CXB 66km, 580hm
Gravel M11n 70km, 480hm
Gravel quälnix 65km, 550hm
Sind halt insgesamt im Schnitt mehr als das Doppelte an Höhenmeter für vielleicht geschätzt 15-20% mehr Schotter. Wenn man länger fahren will, ist das nicht so ideal, da dich sowohl die Höhenmeter, wie der Schotter ja doch deutlich mehr fordern. Das spiegelt sich in der errechneten Fahrzeit definitiv nicht wider.
Treckingrad ist ziemlich analog Gravel schnell. Beide sind dann aber wiederum sehr viel auf Radrouten entlang von Straßen und auf Nebenstraßen unterwegs. Bissl mehr Schotter wäre dann doch wieder gut.
Gibt's da eine Empfehlung?
 
Zuletzt bearbeitet:
Cool, ja das sieht deutlich besser aus!
Kann ich den Schalter irgendwie in Locus Maps mit brouter aktivieren?
Bei manchen Profilen gibt es die Möglichkeit für eine Feinauswahl, z.B. bei den internen Wandern und MTB-Profilen der Schalter nasse Bedingungen.
 
@DaMoasta, da bin ich überfragt, aber was wohl auf jeden Fall gehen sollte, ist, eine Kopie von der jeweiligen ".brf" Datei zu machen und den Schalter dort einfach standardmäßig umzulegen. Also das assign consider_elevation false zu einem assign consider_elevation true machen und dann jeweils unter einem neuen Namen abspeichern.
 
Also der Wert "assign uphillcost switch consider_elevation" ist für mich echt interessant. Man kann damit die Höhenmeter stark reduzieren und die Distanz wächst dann natürlich. Aber hier manuell eingreifen zu können finde ich interessant!
 
DaMoasta schrieb:
da dich sowohl die Höhenmeter, wie der Schotter ja doch deutlich mehr fordern. Das spiegelt sich in der errechneten Fahrzeit definitiv nicht wider.
Zum Vergrößern anklicken....
Höhenmeter werden bei der Fahrzeitberechnung berücksichtigt, die Beschaffenheit der Fahrbahn nicht.
r4n schrieb:
Aber hier manuell eingreifen zu können finde ich interessant!
Zum Vergrößern anklicken....
Im Trekkingprofil hat man aus dem Optionsmenü heraus direkten Zugriff auf diese Werte. Das wäre prinzipiell auch für die Gravelprofile denkbar, wobei ich die Einstellmöglichkeiten in meinem Profil eigentlich absichtlich eher simpel gehalten habe. Genial wären natürlich Schieberegler mit einer Liveaktualisierung der Route, dann könnte man mit zwei Handgriffen selber entscheiden, wie viel Asphalt und wie viele Höhenmeter man will.
 
quaelnix schrieb:
Höhenmeter werden bei der Fahrzeitberechnung berücksichtigt, die Beschaffenheit der Fahrbahn nicht.

Im Trekkingprofil hat man aus dem Optionsmenü heraus direkten Zugriff auf diese Werte. Das wäre prinzipiell auch für die Gravelprofile denkbar, wobei ich die Einstellmöglichkeiten in meinem Profil eigentlich absichtlich eher simpel gehalten habe. Genial wären natürlich Schieberegler mit einer Liveaktualisierung der Route, dann könnte man mit zwei Handgriffen selber entscheiden, wie viel Asphalt und wie viele Höhenmeter man will.
Zum Vergrößern anklicken....
Ja, das direkt machen zu können wäre schon genial!
Es scheitert bei den anderen profilen für mich eher an einer Beschreibung/Erklärung wie es routet.
Du erklärst hier zu deinem Profil und deshalb setzte ich mich damit auseinander, das ist super (genau wie deine Arbeit und deine Erklärungen.

Evtl könnte man (also Du :)) ein simples und ein extended adjustment Profil machen?

Es gibt wahrscheinlich fast unendliche Möglichkeiten der Einstellungen. Aber das quaelnix ist ja schon eine gute Basis.
Habe auch die Kostenfsktoren für schlechte Wege gefunden, auch prima.
Für mich ist halt vor allem diese Radrouten und Höhenmeter-Reduktion wichtig. Wobei Radrouten, je nachdem, bevorzugt oder nicht bevorzugt werden sollen. Also mit dem Schalter ist das gut!
Mit den Höhenmetern war beim Wert von 500 statt 80 eine deutlich andere Route gekommen, was mir sehr gefallen hat.

Was dann auch noch sowas ist, was ich versuche: wenn ich von einem Punkt zu einem anderen und zurück fahre, wenn dann ein andere Weg zurück genommen wird ohne zusätzliche Punkte anzugeben. Aber das geht auch mit zusätzlichen Punkten gut.
 
r4n schrieb:
Mit den Höhenmetern war beim Wert von 500 statt 80 eine deutlich andere Route gekommen
Zum Vergrößern anklicken....
Dabei nur aufpassen, dass der Mean cost factor rechts unten nicht zu hoch wird, denn sonst kommt irgendwann die Fahrzeitprognose durcheinander (und die Berechnung der Route kann deutlich länger dauern).
r4n schrieb:
Aber das geht auch mit zusätzlichen Punkten gut.
Zum Vergrößern anklicken....
Man kann in so einem Fall auch erst mal sein Glück mit den drei alternativen Routenvorschlägen probieren:
Original (Link)​
3rd Alternative (Link)​
qualnix-original.jpg
qualnix-3rd-alternative.jpg
 
Ja die Alternativen sind super.
Aber unterwegs auf Locus gibt's die natürlich nicht. ;-)
Was auch cool wäre, wäre ein Zufalls-Rundtourgenerator. Ich will ca. 5h fahren, schlag mir was vor.
Um den eigenen Standort natürlich, oder einen beliebigen, anderen.
 
Wenn wir gerade bei "Wünsch Dir was" angekommen sind. Durchnummerierte Wegpunkte (und oder Richtungspfeile auf der Route) wären insbesondere beim Planen von Rundtouren echt nicht verkehrt.
 
beutelfuchs schrieb:
Der bessere Ansatz ist einfach zu schauen, wo Leute mit welcher Art Bike tatsaechlich lang fahren. Am besten hat das bisher Garmin mit seinen popularity maps geloest
Zum Vergrößern anklicken....

Keine Ahnung ob das Garmin so toll gelöst hat, wirklich hilfreich ist es für mich als Mountainbiker der gerne die Trails runterfährt leider nicht, wahrscheinlich dank der zahlreichen E-Biker die lieber die Waldautobahn nehmen..

1662841371201.png



Für mich sind die besten Anlaufstellen immer noch Strava & Trailforks. Eine Heat-Map ist vom Ansatz her gut, es muss aber eine klare STS-Klassifizierung hervorgehen. Ein vernünftiger User-Input ist unabdingbar, sonst endet es in falschen Definitionen und Klassifizierungen. Umso besser die Daten, desto besser dann auch die Möglichkeiten für ein Routing.

Schade das man im BRouter keine Heat-Maps, Trailforks oder dergleichen drüberlegen kann. Das wäre dann schon fast der Endgegner.
 
DaMoasta schrieb:
Kann ich den Schalter irgendwie in Locus Maps mit brouter aktivieren?
Bei manchen Profilen gibt es die Möglichkeit für eine Feinauswahl, z.B. bei den internen Wandern und MTB-Profilen der Schalter nasse Bedingungen.
Zum Vergrößern anklicken....
Das geht leider (immer noch) nicht. Das versuche ich schon seit Jahren beim Entwickler von Locus zu erreichen, aber er will nur einige allgemeine Optionen aus einer Locus-internen Whitelist erlauben (u.a. avoid_tolls, is_wet, avoid_unpaved). U.a. wird als Grund herangeführt, dass Locus so eine Übersetzung der Parameter anbieten kann.
Ich wäre ja auch zufrieden, wenn es wenigstens als versteckte Poweruser-Option möglich wäre, aber auch das wurde verwehrt :(
Das ist auch der Grund, weshalb ich mein MTB-Profil in zwei Varianten erstelle, es ließe sich nämlich sonst eigentlich über einen einzigen Parameter umswitchen.

Apropos: wie weiter oben diskutiert, ist das Handling der access-Regeln in meinem Profil überarbeitungswürdig. Ich hab das schon seit Jahren auf der ToDo-Liste stehen. Das ist momentan so wie es ist, weil in Gegenden die ich kenne oftmals in OSM falsch gemappt wurde (access=private statt permissive bei "auf eigene Gefahr"). Ist aber allgemein wohl ungünstig da es eben auch vorkommen kann, dass man so über einen Privatweg geroutet wird.
Ich werde zumindest erstmal das Routing über "private" (auch auf Nodes) anpassen...
 
quaelnix schrieb:
Ich seh gerade, dass die private_penalty wohl sowieso nur für Wege und nicht für Knoten gilt.

Richtig, es liegt daran, dass auf dem Knoten ein vehicle Tag gesetzt wurde. Bei barrier=gate; access=private ohne vehicle Tag funktioniert es (siehe Beispiel). Eine mögliche Lösung ist Zeile 623 wie folgt umzuschreiben:
Code: 
        if or vehicle=private|no access=private|no      then false
Zum Vergrößern anklicken....
Darf ich hier nochmal nachhaken, welches vehicle-tag genau in dem Fall gesetzt war, wo es "nicht richtig" funktioniert hat? Bei OSM sollte es ja so sein, dass ein access= - Tag das allgemeinste ist und speziellere Tags (vehicle=, bicycle=, foot=) das für die jeweilige Fortbewegungsart überschreiben können. Wenn also ein vehicle-Tag gesetzt ist und kein spezielleres Tag (bicycle=) vorhanden ist, sollte also das vehicle-Tag gelten (auch wenn gleichzeitig access auf einen anderen Wert gesetzt ist). Ein Fahrrad ist ja nunmal ein vehicle. Momentan sperren aber nur "private" und "no", eventuell gibt es noch weiter Werte, die zu einer Sperrung führen sollten?

Ein Hinweis noch zu Access und punktförmigen Barrieren (z.B. Toren): seit v1.2.1 meiner Profile (auf bikerouter.de gibts noch die ältere v1.2.0) gibt es einen zusätzlichen Switch "use_uncertain_gates", welche Barrieren für das Routing zulassen, bei denen (noch) kein Access getaggt wurde. Normalerweise sind die nämlich fürs Routing gesperrt. In manchen schlecht gemappten Gegenden gibt es sonst Routing mit großen Umwegen, obwohl die Tore oftmals passierbar sind (kommt auf die Gegend an). Das ist aber natürlich mit Vorsicht zu benutzen und man sollte drauf gefasst sein, doch mal vor einem unpassierbaren Tor zu stehen.
 
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂
Zurück