MTB-News.de

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

Mal ne Frage zum Profil "Rennrad - sehr wenig Verkehr", ob ich da irgendwas falsch mache, oder fehl-interpretiere.
Eigentlich habe ich das Profil bisher nicht benutzt. Primär Gravel und MTB, die für mich ganz gut funktionieren.
Aktuell ist aber alles (immer noch) so nass und durchweicht, dass ich mehr Spass am Tile Hunting und neuen Strecken habe.
ABER gerne wirklich wenig Verkehr und dafür lieber Umwege.
Bei mir zeigt da das Profil ein komisches Verhalten. Es werden bei mir durch die Routing Engine gerne Straßen mit getrennten Radwegen genutzt. Diese sind in den meisten Fällen aber alles andere als wenig befahren. Ja die Wege sind sicher, aber ich möchte halt gerne ruhig fahren, dass ist MEIN Verständnis von wenig Verkehr. Mache ich was falsch?
Ergänzende Frage - gäbe es irgendeine Heatmap die diesem Wunsch gerecht wird, die ich als Overlay einblenden kann?
 
Zuletzt bearbeitet:

Anzeige

Re: bikerouter.de / BRouter(-Web) - Fragen & Antworten, Hilfe, Profile, Tipps etc.
Es gibt ja drei verschiedene Rennrad Profile, die mit "wenig Verkehr" werben. Hast du mal das Erste, also das mit drei Sternen ausprobiert?
hulster schrieb:
Eigentlich habe ich das Profil bisher nicht benutzt. Primär Gravel und MTB, die für mich ganz gut funktionieren.
Zum Vergrößern anklicken....
Wenn du in meinem Profil in Zeile 202 folgenden Code einfügst, wird quasi ausschließlich über asphaltierte Straßen geroutet:
Code: 
multiply switch is_paved 1 12
Das funktioniert so gut, dass ich auch schon überlegt habe, das als prefer_paved_paths Schalter einzubauen. 🤔
 
hulster schrieb:
Bei mir zeigt da das Profil ein komisches Verhalten. Es werden bei mir durch die Routing Engine gerne Straßen mit getrennten Radwegen genutzt. Diese sind in den meisten Fällen aber alles andere als wenig befahren. Ja die Wege sind sicher, aber ich möchte halt gerne ruhig fahren, dass ist MEIN Verständnis von wenig Verkehr.
Zum Vergrößern anklicken....
estimated_noise_class ?
 
quaelnix schrieb:
@snakebite, eine möglichst einfache Query, die obigen Zweck erfüllt, sähe so aus:
Code: 
way[highway~"^(primary|secondary|tertiary)"]({{bbox}});
node(w)["mountain_pass"="yes"];
out;
Aber in den BRouter-Web Overpass Layer bekomme ich es trotzdem nicht eingespeist.
Zum Vergrößern anklicken....
Ich hab deine Query schon verstanden.
Das Problem ist - wie du bereits richtig festgestellt hast - dass der das overpass-frontend, welches im brouter web verwendet wird, eine völlig andere Syntax verwendet. Du siehst sie in meinem Link oben. Warum auch immer nicht einfach die Overpass Query an die overpass API sendet wird und statt dessen eine eigene Syntax aufbaut erschließt sich mir nicht. :cool:
Vielleicht will man komplexe iterierende Abfragen (wie diese hier) verhindern.
 
Ich bin aktuell ein wenig genervt: ich bekomme es in keinem Profil (außer Rennrad) gebacken, dass auf Bergaufstrecken die Engine nicht immer Wanderwegabschneider zwischen den Straßenkehren einbaut. Ob "MTB hard" oder "Gravel schnell" - das ist der KI nicht beizubringen, dass man es bergauf lieber entspannter angehen möchte, um sich die gesparten Körner für die knackige Abfahrt aufzusparen.
Ich muss also ständig zwischen den Profilen wechseln (bergauf nur Straße, bergab Singletrail bis S3). Das aber geht nicht, weil die Routine dann alles neu berechnet.

Ich mach mal ein Beispiel: wenn ich von Susa über den Col delle Finestre und die Assietta-Höhenkammstraße nach Sestriere fahren möchte, dann legt mir Bikerouter eine Strecke zusammen, die kein Mensch so fahren würde, weil mehrere eklatante Fehler darin sind, sowohl bergauf, wie bergab.
Gravel schnell: mehrere Abschneider über Wanderwege! Obwohl ich auf der Höhenstraße einen Zwischenpunkt am Colle Costapiana (2323m) gesetzt hab, verlässt der Vorschlag die Passhöhe sofort und fährt ins Chisone-Tal ab, um dann wenige Kilomter später wieder alles bergauf zu fahren (teilweise über unfahrbare Wanderwege). Das ist schlicht idiotisch.
Mit Gravel (quälnix) ist es zumindest bergauf besser, aber entspricht halt bergab nicht meinen Vorstellungen.
Irgendeine Idee, wie ich vorgehen soll, um zu brauchbaren Ergebnissen zu kommen?
Das beschriebene Problem passiert mir eigentlich überall in den Alpen...
https://bikerouter.de/#map=13/45.10...44;6.878686,44.957814&profile=Trekking-tracks
 
@isartrails, mein Profil ist ja eigentlich darauf ausgelegt, Trails zu meiden, aber wenn du diese Zeile:
Code: 
assign downhillcostfactor multiply costfactor ( switch is_paved 5 1 )
oberhalb von
Code: 
# way priorities used for voice hint generation
einfügst und außerdem die mtbpenalty wie folgt abänderst:
Code: 
assign mtbpenalty
    if mtb:scale=     then 1.0 else    if mtb:scale=0-    then 1.0 else
    if mtb:scale=0    then 1.0 else    if mtb:scale=0+    then 1.0 else 9.0
sollte das Profil deinen Geschmack besser treffen.
 
Zeitangabe im Höhenprofil lässt sich auf einfachem Weg leider nicht umsetzen.

Das ist aktuell alles hard-coded in der HeighGraph Library und es gibt keine Möglichkeiten, die Darstellung von außen ohne wilde Kopfstände zu beeinflussen. Die Änderung muss also upstream direkt in der Library gemacht werden. Norbert Renner hat die Library für BRouter-web bereits schon geforkt (vermutlich auch, weil upstream nichts mehr passiert), aber auch um ihn ist es zuletzt ruhiger geworden.
 
quaelnix schrieb:
...
und außerdem die mtbpenalty wie folgt abänderst:
Code: 
assign mtbpenalty
    if mtb:scale=     then 1.0 else    if mtb:scale=0-    then 1.0 else
    if mtb:scale=0    then 1.0 else    if mtb:scale=0+    then 1.0 else 9.0
sollte das Profil deinen Geschmack besser treffen.
Zum Vergrößern anklicken....
Ich finde nur
Code: 
assign mtb_scale_penalty  if not consider_smoothness then 0.0 else
Code: 
mtbpenalty
finde ich nicht. Welche Zeile (Zahl)?
 
quaelnix schrieb:
mein Profil ist ja eigentlich darauf ausgelegt, Trails zu meiden, aber wenn du diese Zeile
Zum Vergrößern anklicken....
Blöde Frage, aber ich hab den Thread nicht in jedem Detail verfolgt: Welches ist dein Profil?

Womit ich zuletzt gekämpft habe, sind Tracks von Stuntzi aus den Abruzzen. Dort sind in der Karte leider (noch?) viele Straßen als gesperrt vermerkt. Wenn man nun den Track als Route lädt, dann routet der Brouter ganze Weltreisen um diese gesperrten Abschnitte herum, obwohl der Originaltrack das natürlich nicht tut. Selbst mit vielen manuellen Punkten und Direktverbindungen ist das nur Murks, ich sehe da aber keine Lösung: Beispiel
 
Schnellste Lösung ist wohl das Profil zu ändern, z.B. "Dummy (leer)" ....dann wird bei mir "sinnvoll" auf den vorgegebenen Punkten geroutet.
Bei der "Strada Provinciale 64 Nursina" ist ein Eintrag "access: no" vorhanden. Wenn dieser der Realität entspricht, darf man da wohl wirklich nicht fahren. Wenn der Eintrag falsch ist, sollte man ihn korrigieren bzw. ergänzen, dann klappt auch das Routing mit Radprofilen.
 
MartinSt schrieb:
Die Lösung besteht darin, die OpenStreetMap-Daten zu aktualisieren. Der Fehler wurde hier schon gemeldet: https://www.openstreetmap.org/note/3468446
Zum Vergrößern anklicken....
Ich finde nicht, dass das die „Lösung“ ist. Du glaubst doch nicht ernsthaft, dass sich Stuntzi von verbotenen Wegen (ob in OSM oder real) abhalten lässt, einen Weg auszuprobieren. Für mich als User ist es daher relevant, dass mir die OSM zwar sagt, dass der Weg verboten ist, mir aber nicht vorschreibt, wo ich zu fahren habe. Das möchte ich nach wie vor selbst entscheiden dürfen. Von einem Routingtool erwarte ich daher, dass ich die vorgeschlagene Route ohne trickreichen Aufwand so umgestalten kann, wie es mir passt. Und genau darum geht es Fubbes.
 
isartrails schrieb:
Ich finde nicht, dass das die „Lösung“ ist. Du glaubst doch nicht ernsthaft, dass sich Stuntzi von verbotenen Wegen (ob in OSM oder real) abhalten lässt, einen Weg auszuprobieren. Für mich als User ist es daher relevant, dass mir die OSM zwar sagt, dass der Weg verboten ist, mir aber nicht vorschreibt, wo ich zu fahren habe. Das möchte ich nach wie vor selbst entscheiden dürfen. Von einem Routingtool erwarte ich daher, dass ich die vorgeschlagene Route ohne trickreichen Aufwand so umgestalten kann, wie es mir passt. Und genau darum geht es Fubbes.
Zum Vergrößern anklicken....

Wie geschrieben, kommt es aufs Profil drauf an...wenn du ein Radprofil auswählst, dann bleibt dem Router doch nix anderes übrig, als die Datengrundlage von OSM zu nehmen und entsprechend zu routen. Und wenn ein Weg als nicht passierbar getagged ist, dann darf er eben auch nicht dafür hergenommen werden.
Ich verstehe schon, um was es dir/euch geht, aber "logisch nach Daten" ist es halt nicht. Da beißt sich die Katze in den Schwanz.
 
@Marcus Gab es ein Update zum Graveloverlay? Ich muss einen deiner Blogbeiträge übersehen haben...

Friedhöfe werden flächenbezogen hervorgehoben 👍 Gibt es noch andere Änderungen?
 
Servus, ich hatte bisher (vor längerer Zeit) einige Routen über OruxMaps mit BRouter geplant und nun auch mal Bikerouter.de ausprobiert - das ist natürlich deutlich komfortabler. Irgendwie bekomme ich in OruxMaps (7.4.27) aber keine Abbiegehinweise mehr, weder visuell auf der Route, noch als Ansage (was früher schon ging). Egal ob ich die Route direkt in OruxMaps über die BRouter App berechnen lasse, oder ob ich eine GPX-Datei von Bikerouter.de importiere. Bei letzterem hatte ich in den Optionen auch extra schon den "turnInstructionMode" auf "oruxmaps-style" gestellt. Hat jemand eine Idee wo das Problem liegen könnte?

PS: Ich hoffe ich bin hier richtig, eine weitere Struktur-Ebene / eigene Threads innerhalb dieses Themas würden einer besseren Übersicht nicht schaden.
 
@Andre-as, vermutlich sind die neueren BRouter Versionen nicht vollständig rückwärtskompatibel mit OruxMaps.
Die schnellste Lösung wäre auf OsmAnd umzusteigen, die Alternative wäre ein GitHub Issue aufzumachen (in dem du das Problem beschreibst), darauf zu hoffen, dass das Problem in BRouter behoben werden kann (ohne neue Probleme zu erzeugen) und dann das nächste Release abzuwarten.
 
@quaelnix Ein Umstieg auf OsmAnd wäre die für mich aufwendigste "Lösung". Alles komplett neu für mich, ich habe sehr viel Zeit in OruxMaps gesteckt, dort mit den Karten von OpenAndroMaps (für die ganze DACH-Region) und sehr detaillierten DEM-Höhendaten alles schön für die Offline-Nutzung eingerichtet, bin mit der Bedienung der App vertraut. Und zumindest die kostenlose Version von OsmAnd kann der kostenlosen Version von OruxMaps nicht das Wasser reichen. Bei OruxMaps hat man fast alle Funktionen der kostenpflichtigen OsmAnd-App (und noch andere), kann unbegrenzt viele Karten runterladen / einbinden (OsmAnd nichtmal ganz Deutschland), hat noch sehr viel mehr Einstellungs-Möglichkeiten...

Danke für den Tip mit GitHub, hab ich auch noch nie gemacht / müsste ich mir erst mal nen Account anlegen. Wenn sonst niemand das Problem hat / eine Lösung mit OruxMaps weiß werd ich das wohl mal versuchen...
 
@quaelnix Danke dir vielmals :)
Ja genau, OruxMaps 7.4.27 (das ist die aktuellste kostenlose Version), BRouter v1.7.3 oder auch bikerouter.de mit "turnInstructionMode" auf "oruxmaps-style" gestellt.
 
Bitte beachte unsere Verhaltensregeln beim Antworten. Danke 🙂
Zurück
Oben Unten