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

Die derzeitige # if a cycleroute is defined, surface can not be horrible... Logik führt dazu, dass Wege die als tracktype=grade3 getaggt sind, deren Oberfläche aber nicht definiert ist, überproportional stark abgewertet werden, was im ungünstigsten Fall deutliche Umwege auf Asphalt ermöglicht.

Mein Vorschlag wäre an dieser Stelle eine zusätzlich Weiche für tracktype=grade3 einzuführen und diese mit Kosten von irgendwas im Bereich 1 zu belegen. Klingt gut?

(Aus meiner Erfahrung: das Spektrum von grade3-Wegen ist relativ breit, ich habe hier schon alles von geilen verdichteten Wegen bis hin zu surface=sand mit smoothness=very_bad gesehen. Gerade in der Frühzeit von OSM wurden hier in der Region alle Waldwege pauschal mit grade3 angelegt, ohne dass die Leute die Situation vor Ort kannten. Entsprechend wenig kann man sich hier gerade auf diesen speziellen tracktype verlassen. Ein Indiz für passende Klassifizierung ist dann nur das Vorhandensein weiterer Tags wie smoothness usw.)
 

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Ich habe folgende Idee für einen Workaround:
Sieht gut aus. Außerdem wäre es wohl sinnvoll, den Fehler auch in den "offiziellen" Profilen zu beheben (Beispiel: https://github.com/abrensch/brouter/blob/master/misc/profiles2/fastbike-verylowtraffic.brf#L173-L177).
Mein Vorschlag wäre an dieser Stelle eine zusätzlich Weiche für tracktype=grade3 einzuführen und diese mit Kosten von irgendwas im Bereich 1 zu belegen. Klingt gut?
Ja, aber wenn surfacepenalty wirklich nur eine Abschätzung der Oberflächenqualität und nicht gleichzeitig implizit eine zusätzliche Abwertung von nicht aufgelisteten Wegen wie highway=path|footway|... darstellen soll, dann muss, selbst wenn wir tracktype=grade1 bis tracktype=grade5 ausdefinieren, auch die Rückgabe der any_cycleroute Weiche auf einen Wert aus der Umgebung von 2 (was derzeit surface=ground|grass|dirt|earth|mud|clay|sand entspricht) beschränkt sein.
Entsprechend wenig kann man sich hier gerade auf diesen speziellen tracktype verlassen.
Den Ansatz, wenig ausdefinierte Wege grundsätzlich leicht abzuwerten, finde ich nicht verkehrt, aber aktuell werden beispielsweise auch Wege mit tracktype=grade5; surface=sand in der Regel genauso bewertet wie Wege mit tracktype=grade4 ohne surface Tag (in beiden Fällen ist die Summe aus surfacepenalty und tracktypepenalty 8).
 
Wobei ich mit einer Änderung die über das reine Einfügen von switch tracktype=grade3 x (mit 1.55 <= x <= 2) hinausgeht, trotzdem sehr vorsichtig wäre, da sich der Charakter des Profils dadurch deutlich verändert, sofern nicht gleichzeitig an anderen Stellen entsprechend gegengesteuert wird.
 
Wobei ich mit einer Änderung die über das reine Einfügen von switch tracktype=grade3 x (mit 1.55 <= x <= 2) hinausgeht, trotzdem sehr vorsichtig wäre, da sich der Charakter des Profils dadurch deutlich verändert, sofern nicht gleichzeitig an anderen Stellen entsprechend gegengesteuert wird.

Ja, ich habe das auch noch nicht gemacht. Im Grund müsste man schauen, wie oft und wie sehr das Profil beim Routen daneben liegt und dann ggf. leicht nachsteuern. Ich selbst habe es im praktischen Einsatz noch nicht negativ wahrgenommen.
 
Bei mir in der Gegend macht das Profil in 9 von 10 Fällen unnötige Umwege um tracktype=grade3 ohne surface Tag, aber vermutlich ist das im Vergleich dazu, dass man anderswo auf komplett ungeeignete Wege geschickt würde, wirklich das kleinere Übel. In Brandenburg hab ich bisher noch kein einziges Beispiel finden können, wo die aktuelle Logik scheitert. 👍
 
@Marcus, es scheint außerdem, als sei der estimated_traffic_class Lookup auf deinem Server profilübergreifend kaputt.

Ja, ich weiß. Das hat aber ein so niedrige Priorität für mich, dass hier kurzfristig keine Änderung zu erwarten ist.

Viel wichtiger und viel nützlicher ist z. B. das Update der lookups.dat, sobald die neue Version hoffentlich irgendwann demnächst in BRouter gemerged wird …
 
Habe mal eine Frage zum Verhalten beim Routing welche ich mir nicht erklären kann.

Ich bin die Tage mit dem MTB auf einer mit bikerouter.de geplanten neuen Stecke unterwegs gewesen. Dabei wurde ich in einem Streckenabschnitt durch ein neu installiertes abgeschlossenes Tor mit Schild nur Privat aufgehalten. Aktuell pflege ich solche neuen Details dann zu Hause angekommen im OSM ein.

Folgender Link führt zu der Stelle.

1661856872474.png

Der Weg ist im OSM unverändert wie folgt eingetragen:
1661856964626.png

Das neue Tor habe ich wie folgt angelegt:
1661857020004.png


Zu meiner Verwunderung wurde weiterhin nach dem Update über diesen Weg geroutet. Erst als ich das Gate auf access=no umgestellt habe, wird der Weg beim Routing vermieden.

Ich hätte geglaubt, dass eigentlich der Weg selbst mit access=private schon ausreichend sein sollte, damit er mit den üblichen MTB Profilen gemieden wird, was hier aber offensichtlich nicht der Fall ist.

Kann mir bitte jemand helfen, hier meinen Denkfehler aufzuklären?
 
Kein Denkfehler. Das hatte ich schon oft.

In fremden Gegenden meide ich inzwischen alles was nur mit "private" markiert ist
 
Kann mir bitte jemand helfen, hier meinen Denkfehler aufzuklären?
Ich hab mir die Mountainbike Profile zwar noch nicht näher angeschaut, aber auf den ersten Blick sieht es so aus, als würde access=private dort nur zu einer Herabstufung und nicht zu einem kompletten Ausschluss des jeweiligen Wegabschnitts führen. Wenn du das nicht möchtest, einfach die private_penalty (Zeile 54 im "Zossebart" Profil) auf 10000 setzen, dann sind solche Wege zukünftig tabu.
 
Wenn du das nicht möchtest, einfach die private_penalty (Zeile 54 im "Zossebart" Profil) auf 10000 setzen, dann sind solche Wege zukünftig tabu.
Danke für den Hinweis, das hatte ich heute exakt so auch schon einmal probiert, allerdings hatte das keinerlei Einfluss auf das Routing an dieser Stelle. Vielleicht gibt es hier ja einen Bug mit der privat Auswertung in den Profilen.🤔
 
Ich seh gerade, dass die private_penalty wohl sowieso nur für Wege und nicht für Knoten gilt.
Vielleicht gibt es hier ja einen Bug mit der privat Auswertung in den Profilen.
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
 
Nachdem mich dieses wirklich grandiose Forum und insbesondere die Entdeckung von bikerouter.de überhaupt erst auf die Idee gebracht haben, mein eigenes Gravel Profil zu erstellen, möchte ich euch das vorläufige Endergebnis natürlich nicht vorenthalten: quaelnix-gravel.brf (alternativ auch im Anhang zu finden).

Features:
  • Viel befahrene Straßen werden so gut es geht gemieden
  • Die Fahrzeitberechnung funktioniert unanständig gut
  • Trails und Wanderwege werden meisten umfahren
  • Es wird nicht aktiv nach Schotterwegen gesucht
  • Privatwege werden konsequent gemieden
  • Es gibt drei Hauptschalter, um die Routenplanung zu beeinflussen:
    • assume_wet_conditions: Im nassen Zustand schlecht befahrbare Wege werden gemieden
    • prefer_unpaved_paths: Unbefestigte Wege werden, wenn es Sinn macht, bevorzugt
    • consider_elevation: Das digitale Höhenmodell wird mit in Betracht gezogen
  • Dadurch, dass die Wegkosten multiplikativ bestimmt werden, sollte es zumindest theoretisch einfacher sein, das Profil mit ein paar Handgriffen an seine eigenen Bedürfnisse anzupassen
Viel Spaß damit! Kritik ist ausdrücklich erwünscht.

Zu guter Letzt habe ich mit dem Profil spaßeshalber in einem Umkreis von gut 13 km um meinen Wohnort herum für jeden Punkt in einem 3 m Raster die Fahrzeit für den Hin- und Rückweg berechnet und das Ergebnis mit zwei unterschiedlichen Farbskalen visualisiert (dunkelrot und dunkelblau entsprechen jeweils einer Fahrzeit von 1:20 h).
RdYlGn​
Viridis​
reach_rdylgn.png
reach_viridis.png
 

Anhänge

@CC., verkürzt erklärt werden durch den Schalter Wege einfach proportional zu ihrer Steigung bzw. zu ihrem Gefälle künstlich länger gemacht, was dann automatisch dazu führt, dass flacheren Alternativrouten, die eigentlich etwas länger wären, der Vorzug gegeben wird. Den Proportionalitätsfaktor für die "Wegverlängerung" in Abhängigkeit der Fahrbahnneigung kann man via downhillcost (Zeile 26) und uphillcost (Zeile 28) für Steigungen und Gefälle getrennt voneinander seinem eigenen Geschmack anpassen. Wobei man berücksichtigen sollte, dass die Auflösung des digitalen Geländemodells nicht sehr hoch ist. Das heißt, kurze, sehr knackige Rampen werden eventuell nicht korrekt berücksichtigt, da hilft dann auch kein höherer Faktor.

Eine etwas ausführlichere Beschreibung der genauen Funktionsweise findet sich hier: https://brouter.de/brouter/profile_developers_guide.txt (ab "The elevation buffer").
 
@quaelnix Supergut!

Falls es für dich ok ist, würde ich das bei bikerouter.de direkt mit in die Auswahl aufnehmen – wenn du ein Github-Repo dazu hast, gerne auch mit halbautomatischer Aktualisierung.

(Für meinen Geschmack ist da deutlich zu viel Asphalt in den Strecken, das ist aber natürlich immer individuell ;-) Ansonsten ein wunderschönes und sehr cleanes Profil, könnte die perfekte Ausgangslage für eigene Anpassungen darstellen)
 
Falls es für dich ok ist, würde ich das bei bikerouter.de direkt mit in die Auswahl aufnehmen
Sehr gerne.
wenn du ein Github-Repo dazu hast, gerne auch mit halbautomatischer Aktualisierung.
Noch nicht, aber das sollte ich wohl wirklich mal in Angriff nehmen.
Für meinen Geschmack ist da deutlich zu viel Asphalt in den Strecken
Geht mir ähnlich. Insbesondere beim prefer_unpaved_paths Schalter ist noch Luft nach oben, aber bis jetzt hab ich in der Hinsicht keinen besseren Kompromiss finden können und "Gravel Pur" ist mit deinem Profil ja schon ziemlich gut abgedeckt.
 
Hallo Zusammen,

ich experimentiere auch gerade mit Bikerouter und finde diesen bisher sehr interessant!

Kann mir dazu jemand erklären, was es mit den (Weg-) Kosten auf sich hat? Für was braucht man diese?
Und @Marcus , kann man das Profil von @quaelnix schon auswählen? @quaelnix danke für deine Arbeit, scheint ein interessantes Profil zu sein.
Ich habe dazu auch nochmals Fragen:
prefer unpaved paths: was genau wird als unpaved eingestuft? Wo ist da die Grenze? Sind Forststraßen/Forstautobahnen paved? Das würde hießen, upaved sind Trampelpfade, Wanderwege?

Hintergrund meiner Frage und Experimentiererei ist, dass ich z. B. mit Komoot öfters die Erfahrung mache, dass im Gravel-Modus sehr viele aspahltierte Wege verwendet werden aber es auch vorkommt, dass man mal eine S1 oder gar S2 hoch geschickt wird. Das möchte ich vermeiden.
Ich habe auch gute Erfahrungen, wenn ich weitere Strecken in für mich angemessener Zeit fahren möchte, dass dann der Radlland-bayern.de Routenplaner gut funktioniert - Eben auf guten Radwegen, wogegen ich generell hier in meiner Umgebung nichts einzuwenden habe. Heißt, ich bevorzuge es mittlerweile, etwas zivilisationsnäher zu fahren und nicht immer im Wald. Man sieht dabei einfach mehr als nur Bäume, was mir gut gefällt.
Falls es Tips gibt, wie ich das z. B. in ein Profil mit einbeziehen könnte, wäre ich dankbar!
Beim quaelnix-Profil gefällt mir sehr, dass man Höhenmeter vermeiden kann! Hier im Mittelgebirge würde ich gerne weitere Strecken fahren, ohne jedesmal die knackigsten Steigungen mit einzubeziehen.

Danke vorab,
Grüße
r4n
 
Hallo!

Gibt es eigentlich eine Möglichkeit, die Farbe im Bikerouter von geladenen Tracks zu verändern?
Hintergrund: Ich möchte eine Route auf Basis von drei bisherigen Tracks. Die Tracks überschneiden sich nun alle etwas, und es würde die Übersichtlichkeit für mich erhöhen, wenn ich jedem eine eigene Farbe geben könnte.
 
Echt? S2 bergauf geht mit keinem Rad... Das sollte also bergauf immer ausgeschlossen werden; in Gravelprofilen auch bergab.
S2 (steinige Wanderwege) ist sehr selten aber auch schon passiert. S1 kommt aber auf längeren Routen schon mal vor. Ist halt nervig, wenn man in unbekannten Gegenden dann nicht einfach eine Alternative fahren kann.
 
Zurück