BRouter: offline Fahrrad-Routing für Android

Also ein Irrgarten ist ein Sch… dagegen.
Aber Danke.

Gibt es beim brouter eine Maximalzahl an Via-Punkten? Hab gerade was generiert mit 409 Via-Punkte und der mault immer noch nicht… voll krass :slight_smile: openrouteservice.org 50 Punkte möglich, bei graphhopper.com 80 Punkte. Ich fand ja 80 Punkte schon toll :slight_smile:

Hast Du denn auch ein GPX exportiert? Nur dann werden alle Wegpunkte gleichzeitig zum Server geschickt. Bei einer Neuberechnung z.B. nach Setzen einer Nogo-Area passiert für jeden Teilschritt ein Serveraufruf.

Ich sehe solche Export-URLs im Log nur bis ca 200 Wegpunkte oder ca. 4000 Zeichen Länge und bei diesen 4000 Zeichen könnte eine Grenze liegen, weiss ich aber nicht.

Aber so richtig verstehen tue ich den Anwendungsfall mit so vielen Wegpunkten nicht, weil wofür dann noch einen Router wenn man den Weg sowieso selber malt?

Hi, ich stelle da eine Relation nach… Erster Punkt Start und letzter Punkt Ziel… Und dazwischen immer wieder einen via Punkt. Warum? Um im zweiten Schritt sie für mich teilweise umzuplanen… darum… Kann ja nicht meine privat Route in osm speichern…

Danke dass hab ich noch geschaut gehabt mit dem Download, brauch ich aber.

Edit:

Hab nachgeschaut der letzte URL hat 8144 Zeichen. Download als GPX ging :smiley:

Machst du das manuell oder automatisiert per Programm?

Ich nehme an, der Kontext ist die Diskussion in Relation type=route ein überholtes Model? und speziell die Anforderung, entlang einer bestimmten Routen-Relation zu routen/navigieren, als Beispiel aus Beitrag #21 der Altmühltal-Panoramaweg (37187):

http://brouter.de/brouter-web/#map=10/48.9562/11.3908/osm-mapnik-german_style&lonlats=10.753978,49.109507;10.737987,49.084894;10.712325,49.044238;10.781596,49.022705;10.797835,49.002195;10.810526,48.969415;10.864827,48.953463;10.910971,48.95537;10.932984,48.94446;10.962365,48.940115;10.973353,48.930142;10.998705,48.905552;11.017405,48.887507;11.005292,48.870094;11.011511,48.865321;11.03323,48.874096;11.071861,48.875104;11.119547,48.898085;11.15141,48.899034;11.176201,48.903505;11.20142,48.892399;11.252953,48.896383;11.302598,48.934054;11.336862,48.936241;11.373172,48.927869;11.36625,48.947831;11.380568,48.951134;11.374605,48.996615;11.383305,49.000484;11.41608,48.98692;11.450662,49.003763;11.443052,49.014155;11.452762,49.038243;11.469606,49.042088;11.477062,49.0388;11.50264,49.029664;11.560991,49.023186;11.60344,49.013222;11.625919,48.985175;11.662636,48.974925;11.696158,48.972689;11.688546,48.957593;11.733072,48.947418;11.741768,48.95022;11.776068,48.941409;11.794424,48.926405;11.825535,48.90957;11.86759,48.916481;11.870942,48.915873&profile=hiking-beta

Wenn man im “Wandern” Profil (analog zu Beitrag #24 - hast du ja auch schon ausprobiert) das “stick_to_hiking_routes” aktiviert und gleichzeitig das “non_sticky_route_penalty” deutlich hochschraubt (z.B. von 0.5 auf 10.0), müsste man eigentlich mit deutlich weniger Zwischenpunkten auskommen:


assign   stick_to_hiking_routes   1 
assign   non_sticky_route_penalty 10.0

Damit werden auch solche Schleifen nicht abgekürzt:

http://brouter.de/brouter-web/#map=16/49.0220/10.7764/osm-mapnik-german_style,Waymarked_Trails-Hiking&lonlats=10.772492,49.022645;10.77773,49.021041

Bei diichtem Routennetz gibt es aber halt trotzdem noch etliche Abweichungen über andere Routen.

automatisiert per Html+JavaScript… über ID hole ich die Relation von der OSM-API ab und werte aus :slight_smile:

Ja den Altmühltal-Panoramaweg hab ich genommen. Ja mit den Optionen ist es deutlich besser… (#26) :sunglasses: hab jetzt nur weiter getestet mit verschiedenen Routern was möglich ist und wo die Grenzen liegen. Bei BRouter keine gefunden :wink:

Bei dem Altmühltal-Panoramaweg hab ich ohne Optionen mit 50 Via Punkte noch schlechte Ergebnisse erzieht… also mit ca. alle 4 km ein Via… mit 100Via also ca. alle 2km war das schon sehr gut… dann hab ich noch weitergemacht… (bis auf 2 Fehler in den Daten #49 )

Als Wanderer hat man mehr Auswahl an Wegen muss ich feststellen und da zählt vielleicht mal die Aussicht und die nähe zur Altmühl eine Role als Effizienz und Schnelligkeit. Deshalb braucht man da deutlich mehr Via-Punkte als für ÖPNV Routing :wink:

Gruß Miche

Die Brouter Seite gleich mit den geänderten Profil aufrufen, geht nicht oder? Bei github ein wenig durchgeklickt, gibt es noch nicht die Möglichkeit :confused:

Kann es sein, dass beim Höhenprofil an einem Tunnel immer davon ausgegangen wird, dass Start und Ende auf der gleichen Höhe liegen?
Hier ist das offensichtlich nicht der Fall und es wird ein ziemlich unsinniges Höhenprofil erzeugt:
http://brouter.de/brouter-web/#map=15/45.0075/5.4283/osm-mapnik-german_style&lonlats=5.40532,45.014636;5.42289,45.000647
Auch interessant: Wenn man die Wegrichtung umkehrt, wird die Höhe des Tunnels auf 710m anstatt 585m angesetzt.

Nein, noch nicht.

Alternative ist eine lokale Installation und dort ein neues Profil hinzufügen.

Hab ich mir auch schon mal überlegt :slight_smile: Wenn ich mal einen Tag zeit hab, probier ich es mal…

Diese data-files für den segment4 Ordner ist das eine Kachelangabe? Ost… West… für z.B.

München ( https://www.openstreetmap.org/#map=10/48.1826/11.6304 ) braucht man dann:
E10_N45.rd5

Versteh ich das richtig?

hier gibt es ein Grid:

https://www.google.com/maps/d/u/0/viewer?mid=1ZHjQ8Jcyw3Upe-EIizvSDNFmkCA&ll=49.99999999999999%2C10&z=5

ok, danke :slight_smile:

BRouter kann den Höhenunterschied beim Anstieg berücksichtigen. Das gibt beim Fahrradrouting, sofern man ein dafür ausgelegtes Profil verwendet, im Allgemeinen gute Ergebnisse. Es passiert mir aber immer wieder, dass bei gleichem Höhenunterschied über eine zwar kürzere aber weitaus steilere Strecke geroutet wird. Es ist (für mich) ziemlich ärgerlich, wenn ich über eine kurze Strecke mit knackigen 12% Steigung geführt werde, obwohl es eine doppelt so lange Alternative mit gemütlichen 6% gibt. Daher meine Frage: Ist es möglich, BRouter so zu konfigurieren, dass Strecken entsprechend der Steigung penalisiert werden?

Das Thema ist ein Dauerbrenner, einen aktuellen Überblick gibts hier:

https://github.com/poutnikl/Brouter-profiles/issues/20

Hallo Arndt,
das dürfte Dich interessieren:
https://forum.openstreetmap.org/viewtopic.php?pid=760981#p760981

Grüße

Hallo,

ich nutze schon längere Zeit BRouter unter Oruxmaps und sehr intensive das Webinterface für meine Radplanungen. Dafür herzlichen Dank an @Arndt.

Seit kurzem verwende ich auch OSMAnd in Verbindung mit BRouter und Android 9 auf einem Huawei PSmart 2019. Dabei ist es mir mehrfach passiert, dass mitten in einer Route die Meldung kommt “BRouter not available”. Aufruf von Brouter geht, verlassen im Servermode. Beenden von OSMAnd bringt keine Änderung. Reproduzierbar kann ich das nicht beheben. Ich Glaube d.h. wenn mann mehrmals zwischen den Profiles hin und her schaltet geht es wieder.
Wie schon geschrieben alles funtioniert, aber irgendwann ohne manuellen Eingriff kommt bei einer erforderlichen neuen Routenberechnung (Abweichung von der vorgegebenen Route) die Meldung “…BRouter not available”.

Kennt jemand dieses Verhalten und hat einen Tipp wie man das beheben kann?

Ich vermute einen Zusammenhang mit aggressivem Energiesparen:
https://dontkillmyapp.com

Mir ist das auch schon passiert, auf einem Samsung J3 Android 5. OSMAnd durschstarten hat aber geholfen (“richtig” beenden, so dass er anschliessend mit dem Splashscreen startet).

Es ist zumindest plausibel, dass es was mit dem Lifecycle zu tun hat ( “onPause/onResume” ) Das ist aber der Kern von Android und kein Fehler, und wenn heutzutage ein onPause → onResume Zyklus so selten ist, dass ein App-Entwickler damit durchkommt, das nicht wirklich zu testen, wo liegt dann der Fehler im System?

…ich glaube nicht, dass es mit dem Energiesparen zusammenhängt. Ich habe alles was ich da finden konnte freigegeben. Ich habe beim Radfahren immer einen externen Akku mit 15 000mah dran.

Weiteres seltsames Verhalten von OSMAnd. Auf meinem Huawei PSmartPlus 2019 habe ich mit 3 Programmen gleichzeitig auf einer längeren Strecke geloggt und zwar mit OSMAnd,Oruxmaps,Gpslogger. Der GpsLogger hat nahezu keine Ausfälle, Oruxmaps ist akzeptabel aber OSMAnd hat zwischendrin sehr große Lücken. Gpsaufnahme steht auf 1s.

Es kann also nicht der GPS Empfang und die Hadrware sein.

Ich habe Loggs da liegt OSMAnd um mehr als 300m daneben und das ist zum naviegieren im Wald schwierig. Ich habe deshalb immer noch mein LG_Wine_Smart dabei, welches ich vornehmlich als Logger benutze (oruxmaps) seit mein BT747 das Zeitliche gesegnet hat. Das ist aber ein kleiner Bildschirm, hat mich aber noch nie im Stich gelassen.

Genau das ist ja eines der Probleme.
Manche Hersteller entfernen manche Apps nach kurzer Zeit komplett aus dem Arbeitsspeicher, wenn diese sich im Hintergrund befinden. Selbst dann wenn der Benutzer alle Energiesparoptionen abschaltet. Dem Nutzer ist es hier nicht mehr möglich bestimmte Apps hiervon auszunehmen.
Die betroffenen Geräte haben nur eine interne Liste, welche vom Nutzer nicht verändert werden kann, auf der die Ausnahmen stehen.
Das hat z.B. teilweise die Folge, dass selbst bekannte Fitness-Apps nicht mehr richtig funktionieren, falls diese nicht auf der Liste stehen.

Interessant, ist das der GPSLogger hier:
https://github.com/mendhak/gpslogger/
Was mir hier als erstes auffällt, evtl. bevorzugt das Gerät Apps welche Google Play Services verwenden:


    implementation 'com.google.android.gms:play-services-base:16.0.1'
    implementation 'com.google.android.gms:play-services-location:16.0.0'
    implementation 'com.google.android.gms:play-services-auth:16.0.1'

https://github.com/mendhak/gpslogger/blob/master/gpslogger/build.gradle

Außerdem wird neben GPS_PROVIDER auch NETWORK_PROVIDER verwendet, falls verfügbar.
Wichtiger dürfte aber die Verwendung des AlarmManagers in setAlarmForNextPoint() sein:
https://github.com/mendhak/gpslogger/blob/master/gpslogger/src/main/java/com/mendhak/gpslogger/GpsLoggingService.java

edit:
Bei OsmAnd fällt auf, dass der AlarmManager bei Android API > 19 gezielt nicht verwendet wird, indem das GPS-Intervall zwangsweise auf 0 gesetzt wird, das wird evtl. vom Gerät bestraft:


	public int navigationServiceGpsInterval(int interval) {
		// Issue 5632 Workaround: Keep GPS always on instead of using AlarmManager, as API>=19 restricts repeated AlarmManager reception
		// Maybe do not apply to API=19 devices, many still behave acceptably (often restriction not worse than 1/min)
		if ((Build.VERSION.SDK_INT > 19) && (getSettings().SAVE_GLOBAL_TRACK_INTERVAL.get() < 5 * 60000)) {
			return 0;
		}
...

https://github.com/osmandapp/Osmand/blob/d863bf61b27f70e3c213e915a885a0b46c813ab8/OsmAnd/src/net/osmand/plus/OsmandApplication.java#L873