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

Ich belästige euch mal weiter.

Diese gestrichelte Straße ist laut Openstreetmap mit "privatem Zugang". Was konkret bedeutet das?
Da es sich um Erdbebengebiet handelt, gehe ich davon aus, dass die Straße einfach nur etwas kaputt ist. Stuntzi ist da jedenfalls hoch vor zwei Jahren. Vermutlich lässt sich das nur vor Ort erkennen.
Brouter routet jedenfalls nicht drüber.

1671828557805.png
 

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Das ist der Nachteil von OpenSource ... es wird halt oft rumgedoktort ... aber man erfährt nicht das man mal wieder Tester geworden ist :D
Ich würde es etwas anders formulieren.
Das ist halt der Vorteil von OpenSource (, bzw. freier Sotware). Man kann anhand der Changelogs oder der Commits nachvollziehen, was der wann und vielleicht auch warum geändert hat.;)
 
Das route-quality-cost Overlay ist ja leider mehr oder weniger unbrauchbar, da bereits ein Meter "teures Pflaster" irgendwo auf der Strecke die Farbskala komplett ruiniert. Ich bin zwar bekennender Javascript-Hasser, aber weil Weihnachten ist und das Problem richtig nervt, mach ich eine Ausnahme:
Ohne Hotfix​
Mit Hotfix​
cost-overlay-old.png
cost-overlay-new.png
Link zum Patch: https://github.com/nrenner/brouter-web/pull/693
 
Zuletzt bearbeitet:
Ebenfalls großartig wäre, wenn die Art des route-quality Overlays in der URL "gespeichert" würde, also quasi so:
  • .../standard,route-quality-incline&lonlats=...
  • .../standard,route-quality-altitude&lonlats=...
  • .../standard,route-quality-cost&lonlats=...
  • .../standard,route-quality-surface&lonlats=...
 
Seit vor ein paar Monaten in #811 der Wunsch aufkam, heftige Anstiege und Abfahrten bei Bedarf meiden zu können, hat mich die Idee nicht mehr los gelassen. Deshalb hab ich jetzt - erst mal vornehmlich für den Eigenbedarf - einen avoid_steep_inclines Schalter eingebaut, der heftige Steigungen ausknipst. Ergebnis:
default______options​
avoid_steep_inclines​
consider___elevation​
gravel-normal.png
gravel-avoid-steep-inclines.png
gravel-consider-elevation.png

Link zu obigem Beispiel: https://bikerouter.de/#map=11/47.5682/11.1920/...&profile=quaelnix-gravel

Wenn ihr das Ganze selbst ausprobieren wollt, dann einfach im Profiltext folgenden Abschnitt:
Code:
assign consider_elevation false # %consider_elevation% | Enable to consider elevation | boolean

assign downhillcost switch consider_elevation 40 0
assign downhillcutoff 1.5
assign uphillcost switch consider_elevation 80 0
assign uphillcutoff 1.5
hiermit ersetzen:
Code:
assign avoid_steep_inclines true # %avoid_steep_inclines% | Enable to avoid steep inclines | boolean
assign consider_elevation false # %consider_elevation% | Enable to consider elevation | boolean

assign downhillcost switch ( or consider_elevation avoid_steep_inclines ) ( switch avoid_steep_inclines 80 40 ) 0
assign downhillcutoff switch avoid_steep_inclines 8.0 1.5
assign uphillcost switch ( or consider_elevation avoid_steep_inclines ) ( switch avoid_steep_inclines 160 80 ) 0
assign uphillcutoff switch avoid_steep_inclines 8.0 1.5

Sollte sich die Funktion weiterhin bewähren, werde ich den Schalter wohl irgendwann fest einbauen.
 
Seit vor ein paar Monaten in #811 der Wunsch aufkam, heftige Anstiege und Abfahrten bei Bedarf meiden zu können, hat mich die Idee nicht mehr los gelassen. Deshalb hab ich jetzt - erst mal vornehmlich für den Eigenbedarf - einen avoid_steep_inclines Schalter eingebaut, der heftige Steigungen ausknipst.

Link zu obigem Beispiel: https://bikerouter.de/#map=11/47.5682/11.1920/...&profile=quaelnix-gravel

Wenn ihr das Ganze selbst ausprobieren wollt, dann einfach im Profiltext folgenden Abschnitt:
[...]

Sollte sich die Funktion weiterhin bewähren, werde ich den Schalter wohl irgendwann fest einbauen.
Moin quaelnix,
das liest sich sehr gut!
Werde ich demnächst mal ausprobieren. Hier oben rund um HH wird's schwer. Da bin ich eigentlich froh um jeden Anstieg den man mal mitnehmen kann, auch wenn sie steil sind - dafür auch schnell wieder vorbei ;)
Ich bin evtl. bald mit Rad im Taunus, da könnte ich es mal testen.
Hätte dazu noch zwei Fragen:
1.) Was hat noch mal der consider-elevation switch? Ist das ne Art Mittelding zw. default und avoid-steep?
2.) Ist die Anpassung nur mit deinem Gravel-Profil auf bikerouter.de kompatibel oder kann ich dir in jedes beliebige Profil einfügen?
Danke schon mal, find ich richtig gut!
LG.
 
1.) Was hat noch mal der consider-elevation switch? Ist das ne Art Mittelding zw. default und avoid-steep?
default: Das Höhenprofil wird komplett ignoriert
consider_elevation: Hat den Effekt, dass die Anzahl der Höhenmeter mit der Fahrzeit abgewogen wird
avoid_steep_inclines: Hat den Effekt, dass heftige Steigungen, wenn sinnvoll möglich, gemieden werden
2.) ... kann ich dir in jedes beliebige Profil einfügen?
Ja, man halt muss nur aufpassen, dass man den richtigen Teil ersetzt.
Hier oben rund um HH wird's schwer.
Ja, der Schalter kann sein Potenzial erst dann voll ausspielen, wenn es in Richtung Mittelgebirge geht.
 
Ja, z. B. der QRCode-Export oder etliche visuelle Anpassungen.
Könntest du diese live gegangenen Änderungen auf einen eigenen Branch in DEINER Repo stellen?
Usecase:
  • Ich würde gerne eine lokale Instanz des Bikerouter.de Codes über Docker laufen lassen
  • da ich diverse Settings (Layer, eigenes RouterProfil) nicht immer verlieren möchte.
  • ggf. auch die eine gute Änderung eines PR einbauen. ggf auch eigene features / bugfixes.
 
Guten Morgen zusammen,
Ja, der Schalter kann sein Potenzial erst dann voll ausspielen, wenn es in Richtung Mittelgebirge geht.
Ja das dachte ich mir schon - ich werde es bei nächster Gelegenheit mal testen und Feedback geben. Das wird aber wahrscheinlich erst im Frühling der Fall sein.

Mit ist dazu noch ein Vorschlag bzgl. einer Verbesserung / Verfeinerung / Ergänzung des Schalters gekommen:
Es wäre klasse, wenn man irgendwie die Beschaffenheit des Weges mit einbeziehen könnte:
Tracktype = grade1 oder besser (highway=unclassified, tertiary etc): auch stärkere Steigungen von 8-12% (nur als Beispiel) sind nicht mit zu hohen Kosten verbunden.
Tracktype = grade2: möglichst keine (längeren) Steigungen über 8% (auch hier nur Bsp.), dann sollten solche Wege noch fürs Routing in Betracht gezogen werden.
Tracktype >=3: hohe Kosten um diese Wege möglichst zu vermeiden.
Idealerweise könnte dazu noch das smoothness Tag ausgewertet werden: nicht über schlechter als bad oder intermediate (je nach Steigung) routen.
Bleibt natürlich die Frage, wie das Profil damit umgeht, wenn tracktype=unknown ist und/oder smoothness nicht gepflegt ist.

Ich kann leider überhaupt nicht einschätzen, wie kompliziert so eine Abfrage ins Profil einzubauen ist. In meiner "naiven" Vorstellung wäre das über simple if-Abfragen lösbar, die entsprechende Kosten zuweisen. Vermutlich ist es aber komplexer 😉

Für mich persönlich würde das einen großen Mehrwert bedeuten, da es einen riesen Unterschied macht, ob man sich eine Rampe mit smoothen Asphalt hochgequält oder auf groben Schotter mit kaum Traktion fast vom Rad fällt. Grade mit Gravel üblichen Übersetzungen / Reifen fällt das ja deutlich ins Gewicht.
Vielleicht hast du @quaelnix / jemand anderes ja eine Idee, inwiefern man die Abfrage noch in dein Profil einbauen könnte. Das wäre ein Traum.

Guten Start in die Woche und lieben Gruß,

Michael
 
Vielleicht hast du ... ja eine Idee, inwiefern man die Abfrage noch in dein Profil einbauen könnte. Das wäre ein Traum.
Eine Notlösung könnte folgendermaßen aussehen:
Code:
assign bad_when_steep ( and highway=track|path not ( or tracktype=grade1 surface=asphalt|concrete|paving_stones|paved|compacted ) )
assign downhillcostfactor switch not bad_when_steep costfactor ( multiply 2.5 costfactor )
assign uphillcostfactor switch not bad_when_steep costfactor ( multiply 5.0 costfactor )
Einfach diesen Codeblock in der Zeile oberhalb von ---context:node einfügen und falls vorhanden, zusätzlich sowohl assign downhillcutoff 1.5 als auch assign uphillcutoff 1.5 durch assign downhillcutoff 8 bzw. assign downhillcutoff 8 ersetzen. Bei meinem Profil bietet es sich an, zusätzlich assume_wet_conditions zu aktivieren.

Wenn man das macht, nehmen alle Gravelprofile am Gavia Pass von Bormio über St. Catharina die Passstraße: https://bikerouter.de/#map=13/46.39...4;10.488625,46.344052&profile=m11n-gravel-pre

Es wäre klasse, wenn man irgendwie die Beschaffenheit des Weges mit einbeziehen könnte
Ich glaub, ich hab das Problem geknackt! Und zwar hab ich einfach BRouter so umprogrammiert, dass downhillcost, downhillcutoff, uphillcost und uphillcutoff (also die internen Schalter, die regeln, wie mit Höhenmetern umgegangen werden soll) nicht mehr einfach global für das ganze Profil gelten, sondern für jeden Weg individuell je nach dessen Beschaffenheit gesetzt werden können. Damit wird dann obiger Code zu:
Code:
assign bad_when_steep ( and highway=track|path not ( or tracktype=grade1 surface=asphalt|concrete|paving_stones|paved|compacted ) )
assign downhillcost switch bad_when_steep 80 15
assign downhillcutoff switch bad_when_steep 4.0 8.0
assign uphillcost switch bad_when_steep 160 30
assign uphillcutoff switch bad_when_steep 4.0 8.0
mit dem neuen "Werkzeugkasten" sollte sich deine Wunschliste bis ins letzte Detail umsetzen lassen. 8-)
 
Zuletzt bearbeitet:
Ich glaub, ich hab das Problem geknackt! Und zwar hab ich einfach BRouter so umprogrammiert[...]
Hast du eine eigene Instanz irgendwo laufen oder was meinst du mit umprogrammiert?
Oder beziehst du das auf das Profil?
Ich seh aber schon, ich muss mich mal irgendwann in Ruhe mit der Syntax und den Switches / generellen Aufbau der Profile beschäftigen, damit ich besser verstehe was da passiert.
Ganz so kompliziert sieht so ein Profil ja eigentlich nicht aus.
Danke auf jeden Fall für deine Mühen!

LG
 
Hat jemand eine Idee, woran es liegen kann, dass ich manchmal eine Strecke partout nicht über einen gewünschten Streckenabschnitt geplant bekomme? In meinem Fall sind das meist Passübergänge. Egal mit welchem Profil.
Hier ein Beispiel in den Pyrenäen: in direkter und kürzester West-Ost-Verbindung von Urdués nach Aragüés del Puerto ignoriert die Routenplanung konsequent die Passhöhe, egal wieviele Zwischenpunkte man da in der Nähe händisch setzt. Sie will, dass man untenrum fährt.

Es funktioniert zwar mit dem Profil "Wandern (Beta)", aber dieses ist aus einem anderen Grund völlig unbrauchbar, da es um alles, was nur entfernt nach einer Straße riecht, konsequent einen großen Bogen macht.

Profile switchen während einer Planung wäre noch ein geiles Feature, das ich mir wünschen würde... 8-)
 
@isartrails, das wird daran liegen, dass das fragliche Wegstück in Openstreetmap als mtb:scale=5 hinterlegt ist. Wenn du in deinem Beispiel in den Profiloptionen den mtb_hard_factor auf 5 setzt, dann nimmt BRouter in diesem Fall ohne Rücksicht auf Verluste die kürzeste Verbindung.
Hast du eine eigene Instanz irgendwo laufen oder was meinst du mit umprogrammiert?
Ja, ich hab lokal eine Testumgebung mit einer entsprechend modifizierten Version von BRouter aufgesetzt.
Oder beziehst du das auf das Profil?
Nein, das untere Beispiel funktioniert nur dann in Brouter-Web, OsmAnd bzw. Locus Maps, wenn im Hintergrund eine Version von BRouter läuft, die die neuen Funktionen beherrscht.
Danke auf jeden Fall für deine Mühen!
Gerne. Am Ende profitieren wir ja alle davon, wenn BRouter noch besser wird.
 
@isartrails, das wird daran liegen, dass das fragliche Wegstück in Openstreetmap als mtb:scale=5 hinterlegt ist. Wenn du in deinem Beispiel in den Profiloptionen den mtb_hard_factor auf 5 setzt, dann nimmt BRouter in diesem Fall ohne Rücksicht auf Verluste die kürzeste Verbindung.
Das sind für mich Böhmische Dörfer. :confused:
Wo finde ich diesen mtb_hard-factor ?

Aber davon mal abgesehen, selbst wenn der Weg auf OSM so getagged ist, muss das doch nicht heißen, dass man da mit dem MTB nicht lang kann/soll. Dass es nicht leicht werden wird, erwartet ja keiner...

Außerdem: irgendwas stimmt an deiner Argumentation nicht: ändere ich das Profil im obigen Beispiel auf "Rennrad", dann macht er es plötzlich. Und das, obwohl es völlig hirnrissig wäre, in dem Gelände mit Rennrad unterwegs zu sein.
 
Wo finde ich diesen mtb_hard-factor ?
Rechts oben auf den Werkzeugschlüssel klicken, Optionen auswählen, 5 in das Feld unter mtb_hard_factor eingeben und dann unten den blauen "Anwenden" Knopf drücken.
Aber davon mal abgesehen, selbst wenn der Weg auf OSM so getagged ist, muss das doch nicht heißen, dass man da mit dem MTB nicht lang kann/soll.
Mit mtb:scale=5 sind solche Wege gemeint: http://www.singletrail-skala.de/s5, ob der Weg wirklich so heftig ist, kann ich dir nicht sagen, aber im Zweifel würde ich es nicht drauf ankommen lassen wollen.
 
Ja, ich hab lokal eine Testumgebung mit einer entsprechend modifizierten Version von BRouter aufgesetzt.
Ist die Instanz ansonsten wie die von Marcus bzgl der Funktionalität / Profilen / Layer und würdest du dir evtl mal verfügbar machen?

Oder @Marcus evtl. wäre es ja auch in der Zukunft auch eine Option die Veränderung in deiner Instanz zu nutzen, falls es mit anderen Profilen keine Probleme gibt?
Profile switchen während einer Planung wäre noch ein geiles Feature, das ich mir wünschen würde...
+1
Ich meine auch irgendwo hier im Thread mal gelesen zu haben, dass @Marcus das für dir Zukunft in Aussicht gestellt hat!?
 
@Lupus_HH, aufgrund der uneingeschränkten Abwärtskompatibilität und der Tatsache, dass diese Änderung nicht nur den Gravel, sondern auch fast allen anderen Profilen ganz neue Möglichkeiten eröffnen würde, besteht vermutlich eine realistische Chance, dass sie in BRouter aufgenommen wird und damit früher oder später für alle verfügbar wird.

Aber damit es so weit kommt, muss die Änderung wohldurchdacht und sauber implementiert sein und das geht nicht von jetzt auf gleich.

Für den Fall, dass die Änderung nicht angenommen wird, können wir uns dann immer noch überlegen, ob es Sinn macht, unser eigenes Süppchen zu kochen.
 
@Lupus_HH, hier mal exemplarisch, welche Möglichkeiten man damit im MTB "Zossebart" Profil hat:
Alt​
Neu​
old.jpg
new.jpg
Link zum Beispiel: https://bikerouter.de/#map=12/51.7542/10.7038/...&profile=mtb-zossebart

Die neue Route entsteht allein dadurch, dass die Zeilen im Profil, welche den Umgang mit Höhenmetern definieren, in den Wegkontext verschoben und folgendermaßen abgeändert wurden:
Code:
assign bad_when_steep ( and highway=track|path not ( or tracktype=grade1 surface=asphalt|concrete|... ) )
assign downhillcost switch bad_when_steep 120 80
assign downhillcutoff switch bad_when_steep 10 1.5
assign uphillcost switch bad_when_steep 240 160
assign uphillcutoff switch bad_when_steep 4 10
Dadurch werden negative Höhenmeter auf gutem Untergrund und positive Höhenmeter auf schlechtem Untergrund bestraft. Was dazu führt, dass er bei der Auffahrt überwiegend weniger steile Schotterwege vom tracktype=grade2 nimmt und bei der Abfahrt dann ins Gelände geht. Das Anpassen einer einzigen Zahl (10 in obigem Beispiel) genügt dabei, um festzulegen, wie "flowig" die Abfahrt sein soll: Leider geil.
 
Zuletzt bearbeitet:
@Lupus_HH, so, ich war fleißig: https://github.com/abrensch/brouter/pull/497
Oder @Marcus evtl. wäre es ja auch in der Zukunft auch eine Option die Veränderung in deiner Instanz zu nutzen, falls es mit anderen Profilen keine Probleme gibt?
Das Problem an der Sache ist dann halt, dass man getrennte Profile für bikerouter.de und für Locus Map bzw. OsmAnd bräuchte, weil Letztere die neuen Funktionen dann ja trotzdem nicht unterstützen würden.
 
@Lupus_HH, so, ich war fleißig: https://github.com/abrensch/brouter/pull/497

Das Problem an der Sache ist dann halt, dass man getrennte Profile für bikerouter.de und für Locus Map bzw. OsmAnd bräuchte, weil Letztere die neuen Funktionen dann ja trotzdem nicht unterstützen würden.
Sehr gut, dann können wir ja mal gespannt sein, ob und wann das ganze eingebaut wird. Poutnikl hat ja schon einen Kommentar dazu abgegeben - evtl doch problematisch?

Bzgl. Locus / OsmAnd Profilen: ich persönlich fände das nicht dramatisch, da ich eh meist nur am Rechner plane und am Handy dann höchstens manuell mal ne Abkürzung / Wegänderung einbaue. Allerdings muss man das natürlich wissen / muss dokumentiert sein, dass die Profile nicht 1:1 kopiert werden können. Macht den Umgang damit natürlich nicht grad nutzerfreundlicher...
Aber werden die Änderungen am brouter die via github reinkommen nicht irgendwann auch in die brouter android app eingebaut? Dann würde es ja wieder passen. Oder beziehst du das auf die integrierte Routing Engine? Bei locus nutze ich sie nicht (sondern halt brouter) und OsmAnd nutze ich mangels iPhone gar nicht ;)
 
Ich weiß nicht ob das hier ner passt (sonst gern per pn) und quaelnix oder sonst jemand überhaupt Lust und Zeit hat:
Könnte mir jemand erklären was genau in dem Profil Code von quaelnix passiert / wie die Syntax aufzulösen ist:
Habe meine Fragen als Kommentar in den Code eingefügt:
Code:
---context:way

assign has_decent_surface surface=asphalt|concrete|paved|paving_stones|fine_gravel|compacted
#Definition der Bedingungen für Switch(? korrekt) bzgl. Weg Oberfläche?

assign bad_when_steep ( and highway=track|path not ( or tracktype=grade1 has_decent_surface ) )
#Definition der Bedingungen für den Switch der ausgelöst werden soll, wenn es zu steil wird: der Weg muss dazu als TRACK definiert sein (heißt wenn höherwertig wird der switch nicht berücksichtigt), UND NICHT PFAD (heißt Pfade werden dann nicht fürs Routing genutzt?) UND tracktype=1 ODER has_decent_surface erfüllt?

assign downhillcost switch bad_when_steep 120 80
#hier wird angegeben ab welcher Steigung der switch auslösen soll? Kann aber die Zahlen nicht zuordnen. X Meter Länge auf X Meter Höhe?

assign downhillcutoff switch bad_when_steep 10 1.5
#hier werden an die Kosten "manipuliert, so dass die Route teurer wird, wenn der switch bad_when_steep gesetzt ist?
Auch hier kann ich die beiden Zahlen nicht zuordnen, werden Faktoren sein denk ich - aber wie werden diese verrechnet?

#hier das gleiche wie oben nur auf Uphill bezogen.
assign uphillcost switch bad_when_steep 240 160
assign uphillcutoff switch bad_when_steep 4 10

Danke schon mal für eine Erklärung!
 
Zurück