BRouter: offline Fahrrad-Routing für Android

Hallo Ikonor,

Danke, deine Tipps sind ganz interessant!
Mir geht es aber eher darum, das neue Profile mit meinen Radfreunden und bekannten Radvereinen zu teilen, und dafür zuerst eine einfache Möglichkeit zu schaffen, dieses Custom-Profile im Brouter-Web zu verwenden. (ohne die Aufwändigen cut/paste + Hochladen)
Dafür setzte ich inzwischen auf die folgende Entwicklung, die als nächste (Auskunft von N. Renner) geplant ist:

https://github.com/nrenner/brouter-web/issues/26

Nach den Tests in der Breite kann ich natürlich gerne allen zur Verfügung stellen.
VG

Moin!
Irgendwas scheint hier beim Höhenprofil schiefzugehen. Dachte, ich melde es mal:
http://brouter.de/brouter-web/#map=10/53.3649/9.6020/opencylemap&lonlats=8.436554,52.897085;9.664107,53.450137;8.545609,53.520435;8.43647,52.897151&nogos=8.85545,53.062101,4987

Hallo,

Eine neue Verständnisfrage ist bei einer Radtour mir heute aufgefallen:
Es geht um “route_bicycle_lcn=yes”, das vom Brouter für bestimmte Abschnitten geliefert wird.

Die Tour verlief hier:
https://www.openstreetmap.org/edit?way=27278514#map=17/49.94178/8.96038
Die OSM Eigenschaften :
Highway=secondary
maxspeed=70
Ref=L 3065
Surface= Asphalt

Im Brouter-web taucht aber „route_bicycle_lcn=yes“ auf…
http://brouter.de/brouter-web/#map=13/49.9435/8.9989/standard&lonlats=8.953971,49.953804;8.959467,49.940675&profile=fastbike

Bei dem 1236 Meter Abschnitt wird geliefert  highway=secondary surface=asphalt route_bicycle_lcn=yes

Gerne würde ich verstehen, warum der Brouter dieses „route_bicycle_lcn=yes“ liefert, und was es bedeutet.

(eine Dokumentation habe ich leider nicht gefunden. Einige Profiles werten das Parameter als „any_Cycleway aus, anscheinend sollte ich im Rennrad profile lieber nicht übernehmen)

VG

Ich wollte noch sagen, im besagten Abschnitt konnte ich keinen Radweg finden…

Der Weg ist Teil dieser Relation: https://www.openstreetmap.org/relation/299353

Danke GerdP!

Ich bin neu in der Brouter Welt, kante diese Relationen nicht.

Wenn ich richtig verstehe, besagt der Tag, dass dieser Abschnitt Bestandteil einer längeren Route vom Typ “route=bicycle”.
Mag diese Route schön sein!
Es gibt aber keine Garantie, dass irgendeiner Radweg exakt in diesem Abschnitt vorhanden ist?

Die Auswertung des Parameters “route_cycleway_lcn=yes” hatte ich fastbike.brf und fastbike-lowtrafic.brf übernommen, ich glaube, ich werde sie herausnehmen. Nur die Auswertung der OSM Tags selber halte ich momentan für sicher bzw. sinnvoll…

VG

fastbike benutzt die radrouten nur zur berechnung der zugangsberechtigung, nicht für den kostenfaktor.

ganz anders trekking - da sind die radrouten quasi das backbone

Danke, das hätte eigentlich behoben sein sollen, da fehlte aber noch was (siehe Issue #147).

Ich konnte das auf die Flußquerung per Fähre eingrenzen, da gibt es wohl keine Höhendaten, die entprechenden Nodes werden jetzt einfach übersprungen:
http://brouter.de/brouter-web/#map=13/53.5097/8.6364/standard&lonlats=8.584442,53.538267;8.565903,53.529595;8.545475,53.520411

Danke, das ging ja flott :slight_smile:

Danke nochmal für die Hilfe! (ich hatte hier wohl “cycleroute” und “cycleway” durcheinander gebracht)
Eine Frage, die in den Forums bisher leider negativ beantwortet wurde, stelle ich hier nochmal, manchmal tauchen neue Ideen auf…
In meinem Profile (Rennrad mit minimalem Verkehr) bestrafe ich Strassenabschnitte mit “maxspeed” 30 oder 50 weniger als bei höheren max-Geschwindigkeiten.
Leider sind zum Beispiel ca. 30% der highway=secondary mit dem maxspeed Attribut nicht bestückt…(Diese Info ist für Autofahrer doch wichtig?)

Hätte jemand eine Lösung? (zum Beispiel eine Möglichkeit abzufragen, ob der Abschnitt im bewohnten Bereich liegt)
Bisher habe ich nur herausgefunden, das ca. 85% der Strassenabschnitte, die mit “name=” versehen sind, maxspeed <=50 haben
(Auswertung der Abschnitte wo maxspeed vorhanden ist)

Die Auto-Profile, die das kinematische Modell verwenden, berücksichtigen ungetaggtes maxspeed innerorts, indem eine Berührung mit highway=residential am Knoten ein maxspeed=50 impliziert und das die Durchfahrt runterbremst. Aber das lässt sich für ein Rad-Profil nicht so einfach übernehmen…

Ich glaube die Zeit bringt die Lösung. maxspeed-coverage nimmt ja zu.

Andererseits ist highway=secondary maxpseed=30 ja oft ein schwieriges, enges Nadelöhr, soll man sowas wirklich suchen für ein road-bike-profil?

Hallo Abrensch,
Ja, “secondary mit 30” sind für Rennradfahrer, die allein in der Woche unterwegs sind, viel besser als ist secondary mit 100: Da überholen Autos, LKW und Busse…
Zur Zeit habe ich das Problem, dass innerorts ohne “maxspeed” die Führung (zu) weite Umwege über “residential” erfolgt.

Super Dank für die Erklärung des kinematischen Modell, auf diese Lösung muss man kommen…
Ja, leider nur im Routing Engine selber implementierbar, in einem Script wie im Brouter sehe ich keine Chance.

Leider auch meine angedachte Lösung (Prüfung ob das Highway das “Name” Attribut besitzt) funktioniert nicht:
“unknown lookup name: name”
Wäre keine perfekte Lösung, aber mit einer hohen Wahrscheinlichkeit richtig.

Hallo,

Es gibt heute in Städten einzelne “Fahrradstraßen”, bei mir ist so eine mit “bicycle_road=yes” getaggt.
Würde begrüßen, wenn dieser Tagg im Lookup (mittelfristig) aufgenomen wird.
VG

Hallo,

ich nutze den brouter mittlerweile oft für meine Mountainbike Touren (meist mit dem Profil von Zossebart, was ich immer ein bisschen versuiche anzupassen). Das klappt schon toll, daher erstmal vielen Dank dafür! :slight_smile:

Was ich schon länger suche, ist eine Info zu den einzelnen Belägen bzw. der Art der gefundenen Wege. Die Infos liegen in der OSM - Datenbank ja vor, weil sie ja auch im jeweiligen Profil verwendet werden. Es geht ja dann (wenn ich das richtig verstehe?) nur darum, diese Infos mit auszugeben. Wäre das irgendwie möglich?

So ähnlich geht es, das sieht man ja bei Beispielen in overpass-turbo. Da kann ich aber nicht den Track hochladen und das nachträglich auswerten, ist auch eig. verständlich.

BRouter-Web ( http://brouter.de/brouter-web ) zeigt Dir das, wenn Du nach einer Berechnung auf das Tabellen-Symbol klickst.

Standard-mässig werden nur die Tags gezeigt, die das Profil auch auswertet. Wenn Du alle Tags sehen willst, die in der lookup-Tabelle enthalten sind, musst Du Dein Profil noch um “assign processUnusedTags = true” ergänzen.

Die BRouter-App kann das auch, wenn Du eine Routenberechnung aus einem Maptool in der BRouter-App wiederholst (“<repeat:…”) oder auch (klassisch…) eine Berechnung über die BRouter-App startest, dann liegt anscliessend eine csv-Datei irgendwo rum (am wahrscheinlichsten im BRouter-Base-Directory) und die kannst Du in einem Spreadsheet öffnen.

Die BRouter-App schreibt keine csv-Datei. (Die logfilebase beim RoutingEngine Aufruf in der BRouterView.java ist null.)

Danke, super genau das meinte ich! :smiley: Die Infos kann ich ja dann in Excel&Co noch weiter bearbeiten.

verstehe ich nicht so ganz, gibt es dazu irgendwo eine genauere Erläuterung?
Das soll doch heissen, dass ich einen einmal gerechneten Track einfach nochmal rechne? Dann bekomme ich diese Infos nachträglich wieder. Das geht nicht im Web-Client oder?

Moin,
sehe ich das richtig, dass ich im Profil Trekkingrad keinen Zugriff auf das Tag smoothness habe? Bin bei meiner letzten großen Tour mehrmals auf smoothness=very_bad oder schlimmer unterwegs gewesen. Mit 'nem Trekkingbike mit Starrgabel ist das nur bedingt sinnvoll. Bergauf stört es mich nicht so sehr, nehme ich eher als sportliche Herausforderung, aber in der Ebene oder bergab nervt es schnell und verschleisst die Bremsen. Jetzt wolle ich mal schauen, ob ich das schon bei der Planung besser vermeiden kann.
Habe nichts gefunden.

trekking.brf wertet smoothness nicht aus, das ist richtig, aber in der lookup-Tabelle ist es enthalten ( http://brouter.de/brouter/profiles2/lookups.dat ) und andere Profile werten sie aus, z.B. die vm-forum Profile ( Liegerad/Velomobil ) oder die von Poutnik, die auch in Locus-Maps eingebaut sind ( https://github.com/poutnikl/Brouter-profiles/wiki ).

Dass “trekking.brf” bisschen old-fashioned ist ist mir bewusst, Problem ist einfach, dass nicht die Test-Systematik existiert, um da fundamental dran zu schrauben, deswegen der never-change-a-working-system Ansatz.

OK, danke, ich werde mal schauen, wie die genannten Profile das auswerten. Wenn ich was für mich brauchbares hinbekomme, werde ich es hier veröffentlichen.