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 openrouteservice.org 50 Punkte möglich, bei graphhopper.com 80 Punkte. Ich fand ja 80 Punkte schon toll
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
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:
automatisiert per Html+JavaScript… über ID hole ich die Relation von der OSM-API ab und werte aus
Ja den Altmühltal-Panoramaweg hab ich genommen. Ja mit den Optionen ist es deutlich besser… (#26) hab jetzt nur weiter getestet mit verschiedenen Routern was möglich ist und wo die Grenzen liegen. Bei BRouter keine gefunden
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
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?
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?
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.