BRouter: offline Fahrrad-Routing für Android

Hallo Arndt,

der BRouter verhält sich an vielen Stellen sehr seltsam. Am Kartenmaterial kann es beinahe nicht liegen, da das Graphhopper problemlos packt.

Exemplarisch 1 Beispiel:

BRouter ==> http://www.gpswandern.de/gpxviewer/tvanzeige.shtml?url=http%3A%2F%2Fh2096617.stratoserver.net%2Fcgi-bin%2Fbrouter.sh%3F8.467605_48.792984_8.46915_48.790765_shortest_0

Graphhopper ==> http://graphhopper.com/maps/?point=48.792984%2C8.467605&point=48.790765%2C8.46915&vehicle=FOOT&locale=de-de

Viele Grüsse
Achim

Hi Achim

oh ja, passiert immer dann, wenn start- und endpunkt auf dem gleichen wegabschnitt liegen, da findet er den zielpunkt nicht und durchsucht dann den rest der welt. Danke für den Hinsweis.

War noch nie ganz richtig an der Stelle, nur bisher war es so, dass dann der Zielpunkt falsch gemappt wurde (auf die nächste Kreuzung, nur irgendwann (wird wohl die 0.95 gewesen sein) hab’ ich’s dann wohl verschlimmbessert.

Wird wohl Zeit für die 0.97… muss nur erst paar andere, langweilige Dinge (wie Steuererklärung…) vom Tisch kriegen bevor ich mich wieder rein vertiefen kann.

Gruss, Arndt

Hallo Arndt,

erstmal Danke für den Brouter, Dank dir kann ich den Frühling kaum erwarten :slight_smile:
Bis vor kurzem hatte ich den Router nur ab und zu mal testweise genutzt (in Locus), aber es war mir auf Dauer zu umständlich mit den from/to Wegpunkten und dem Öffnen des Tracks.
Jetzt mit der Android-Schnittstelle und der dazu passenden Implementierung in Locus macht das schon viel mehr Spaß! Ich hab auch mal angefangen an einem MTB-Profil zu basteln, welches meinen Anforderungen entspricht, und das sieht jetzt schon ganz vielversprechend aus! Is echt toll dass man die Profile selbst anpassen kann!

Nun meine Frage: Ist es in der aktuellen Version möglich, AlternativRouten im Server-Modus über die Intents-Schnittstelle zu bekommen?

Mit Locus scheint das bei mir nicht zu funktionieren. Ich hab es versucht, indem ich mehrmals hintereinander Navigation mit exakt den gleichen Start- und Zielpunkten ausgeführt habe. Die Punkte waren dabei POIs aus meiner Datenbank, d.h. die Koordinaten sollten zwischen den Aufrufen wirklich genau gleich gewesen sein. Ich erhalte aber immer die gleiche Route.

Über den manuellen Aufruf der Brouter-App (from/to Wegpunkte gesetzt) funktioniert das Berechnen von Alternativrouten problemlos.

Ich hätte zwei Ideen:

  1. Locus macht irgendwas bei den Intents falsch. In diesem Fall würde ich im Locus Forum weiter fragen.

  2. Da du ja im Server-Modus schnelle partielle Neuberechnung unterstützen möchtest, funktionieren Alternativrouten in dem Modus nicht mehr. Bei der zweiten Berechnung findet eine schnelle Neuberechnung der Route statt (da gleicher Zielpunkt), aber keine Alternativ-Berechnung.

Oder ist es doch was anderes?

Gruß und Danke!

Nein. Ich könnte den Parameter “Alternativ-Index” zwar in der Schnittstelle exponieren, aber ich wüsste kein Maptool, was das Konzept kennt.

Beim Aufruf der Brouter-App geht das Triggern von Alternativ-Berechnungen über einen Dateivergleich: wenn er die Ergebnisdatei mit exakt dem gleichen Ergebnis überschreiben würde, macht er stattdessen eine neue Runde für die nächste Alternative. Also wenn sich irgendwas an den Parametern ändert, was das Routing-Ergebnis beeinflusst, fängt er wieder von vorne an.

Aber es gibt auch eine “Alternative zu den Alternativen”… wenn mir eine Route nicht passt, erzwinge ich die Alternative normalerweise über Sperrpunkte. Und die wirken auch beim Aufruf über die Schnittstelle, wenn sie in einen Routing-Modus hineinkonfiguriert wurden. Und an der Stelle denke ich tatsächlich drüber nach, ob man das nicht vereinfachen kann, also einen neuen Sperrpunkt aktivieren einfach indem man ihn als Wegpunkt anlegt, ohne anschliessend extra nochmal die BRouter-App starten zu müssen.

Ok das stimmt. Ich dachte nur, ich kann es “herbeitricksen”, indem ich die gleiche Strecke mehrmals berechnen lasse, was ja beim standalone-brouter so geht.

Die Methode erklärt natürlich, warum das über den Intent nicht geht. Da wird keine Datei “überschrieben”, sondern das Ergebnis direkt an die aufrufende App zurückgegeben. Danke für die Erklärung!

Das klingt auch gut! Das momentane Verfahren ist mir auch zu umständlich. Brouter lässt sich zwar relativ komfortabel aus Locus heraus starten, aber dann kommt ja noch die Profil-Auswahl, die Auswahl der Via- und Nogo-Punkte und am Ende die Zuordnung des Routenprofils. Das dauert doch alles relativ lange…
Wie würdest du das genau umsetzen? So dass einfach alle gefundenen nogo-Punkte verwendet werden? Weil einen zusätzlichen Auswahldialog in der Kartenapp gibt es ja dafür nicht.

…ok! Umgekehrt wird ein Schuh daraus. Es gibt kein Tool das dieses Feture unterstützt, weil es keine (?) Router gibt die “Alternativen” generieren. Eine “GROSSE BITTE” an dich, gebe bitte das Feature der Alternativen-Routen-Generierung nicht auf. Zumindest in der Desktop Version.
Derzeit generiere ich für jeden “Routing-Abschnitt” eine GPX Datei in die ein Wegpunkt und mehre TrackSegmente, die dem Wegpunkt und seinem Vorgänger zugeordenet sind. Die entgültige Route kann ich mir dann aus dieser GPX Datei zusamenstellen durch Auswahl welche Routingsegment mir passt (Steigung,Länge …etc).

Oder denkst du darüber nach dieses Feature ganz aufzugeben?

Ich weiss es nicht, ich darf da nicht zuviel Heuristik reinbasteln, weil sonst versteht es keiner mehr und dann ist es nutzlos. Aber die Anforderung scheint zu sein, dass, wenn ich vor einem Hindernis stehe, dafür eine nogo-Wegpunkt anlege und dann die Route neu berechne, dass dieser Nogo-Punkt dann automatich aktiv ist, weil warum hätte ich ihn sonst eingetragen. Gleiches gilt dann auch für’s Löschen von Nogo-Punkten.

Dafür muss ich aber das Konfigurationskonzept bisschen ändern.

Hm ja, ist alles ein bisschen kompliziert, wenn die Maptools nur simples Routing von A nach B unterstützen. Aber vielleicht sollten die da auch irgendwann mal weiter denken. Kommerzielle Navi-Apps bieten ja z.B. auch mehrere Alternativrouten an.
Aber dafür dann einen Konsens zu finden, den dann alle nutzen wird wahrscheinlich auch schwierig.
Die Idee mit den nogo-Punkent wäre aber auch schon nicht schlecht. So wie es jetzt ist, sind die nogo-Punkte für mich relativ nutzlos, da sie nicht schnell genug konfigurierbar sind.

Was anderes:
Ich hätte mal noch eine Frage zu den Routingprofilen. Was genau bewirkt “uphillcutoff” bzw. “downhillcutoff”? So wie ich das bis jetzt verstanden habe, hat es wohl was mit den Anstiegen zu tun, aber was genau bedeutet ein Wert von z.B. 1.5?

Kurzgesagt: downhillcutoff = 1.5 heisst 1,5% Gefälle sind “gratis”, führen also nicht zu Strafpunkten in der Bewertungsfunktion. Das ist einerseits funktional begründet, weil man bei leichtem Gefälle seine Energie zurückbekommt und nicht in die Wind- oder Bremsreibung steckt. Andererseits stabilisiert es aber auch die Berechnung, man kanns also auch nicht einfach weglassen, ohne komische Effekte zu riskieren.

Die lange version ist in diesem Thread hier: https://groups.google.com/forum/#!topic/osm-android-bikerouting/5oB5h4bI1vg

Danke, dann hatte ich es richtig verstanden.

Habe heute die Version 0.97 von BRouter online gestellt, siehe http://brensche.de/brouter/revisions.html

Da sollten jetzt wirklich alle Issues behandelt sein, die hier in diesem Thread besprochen wurden und wo ich irgendwann mal gesagt habe, dass ich es in der nächsten Version ändern werde. Sollte ich irgendjemanden vergessen haben, dann bitte ich um einen Hinweis.

Das Thema mit den Sperrpunkten in der Service-Schnittstelle habe ich glaubich ganz gut gelöst, indem ich die Logik invertiert habe, ein Routing-Modus speichert jetzt also nicht mehr die Liste der aktiven Sperrpunkte, sondern die, die de-selektiert wurden, also die Veto-Liste. Auf diese Weise kann man jetzt im Maptool einfach Sperrpunkte anlegen und löschen, und das ist immer sofort wirksam.

Und das man jetzt Wegpunkte auch in der BRouter-App aus der Liste aller verfügbaren Wegpunkte wählen kann ist für die meisten Fälle eine echte Vereinfachung. to/from/via Punkte sind damit im Normallfall nicht mehr nötig.

Ich hab mich wirklich auf diese Bugfix-Themen beschränkt, um jetzt den Kopf freizubekommen für echte Erweiterungen, da steht auch schon wieder einiges auf Liste, Fahrzeit-Berechnung, Voice-Navigation-Hints, Foolprof-Installer-App… aber nächstes Jahr ist ja auch noch Zeit. Jetzt erst mal feiern gehen, Euch allen guten Rutsch, und nochmal Danke für den vielen Feedback, den Ihr in 2013 zu BRouter geliefert habt und durch den das Projekt wohl ein ganzen Stück vorangekommen ist.

Ich hab mal im OSM-Wiki gesucht:

Haben wir eigentlich noch keine eigene Seite dort für BRouter?

Mein Schnittstellen-Patch zu OsmAnd wurde von Victor jetzt übernommen, er ist jetzt also im Nightly-Build enthalten:

http://download.osmand.net/latest-night-build/OsmAnd-default.apk

bisher zwar nur Nightly-Build und kein Release-Build, aber das ist ja jetzt nurnoch eine Frage der Zeit, auch bis es in Google-Play ankommt. Ist aber auch schon gleich ein fieser Fehler drin bei der Konfiguration der Navigations-Dienste: offenbar bezieht sich eine Änderung des Navigationsdienstes zu einem Modus (car/bike/foot) jetzt nicht mehr auf den Modus, den man in diesem Dialog auswählt, sondern auf den Default-Modus, den man woanders eingestellt hat. Verwirrend, aber wenn man’s weiss kommt man zurecht.

Damit ist BRouter jetzt auch in OsmAnd gut integriert.

Und eine neue Version (0.98) mit paar Bugfixes habe ich auch online gestellt:

http://brensche.de/brouter/revisions.html

Zu der Frage mit dem OSM-Wiki: ich pflege nur den Eintrag in der Router-Vergleichsmatrix, aber eine (deutsche) Doku, die bisschen die Möglichkeiten und die Alleinstellungsmerkmale beschreibt gibt es in der Tat nicht. Es gibt bisschen was im deutschen Locus-Forum. Meine eigene (englische) Web-Page ist mittleirweile als Doku auch nicht mehr wirklich gut, weil sie historisch gewachsen ist und die eigentlich wichtigen Anwendungsfälle nicht wirklich klar werden.

Hallo Arndt,

vielen Dank für die neue Version!

Jetzt funktionieren auch meine Problemfälle auf dem gleichen (langen) Wegsegment mit meinem Mapsforge-Rescue Mapviewer auf dem Desktop.

Irgendwann (brouter_092_bundle) war mal BRouter.java dabei. Kannst du das zukünftig wieder ins Paket mit aufnehmen?

Vielen Dank
Achim

Hallo,

Danke auch nochmal von mir! Das neue Handling der nogo-Punkte funzt super, hat mir letztes WE im Wald schon geholfen :slight_smile:

Eine Frage: wie oft aktualisierst du eigentlich die Routing-Files?

Es sollte jetzt jeder neue Planet-Dump verarbeitet werden, also wöchentlich, wobei da aber ab und zu einer ausfällt, aber in letzter Zeit scheint’s stabil zu laufen. Mein Skript schaut einmal täglich nach einer neuen (PBF-) Version und braucht dann ca 6 Stunden für die Verarbeitung.

Ich hab’ allerdings noch eine Leiche im Keller beim Routing über Files aus verschiedenen Präprozessor-Läufen, das wird technisch nicht verhindert und kann auch funktionieren, kann aber auch schiefgehen, wenn an den Rand-Knoten editiert wurde. Also besser nicht so häufig aktualisieren, aber wenn dann alle Files ersetzen.

Dieses “bundle” war nur eine Notlösung, um Integration zu ermöglichen ohne Zugriff auf die Quellen.

Jetzt sind die Quellen öffentlich (und GPL-ed ):

https://github.com/abrensch/brouter

und Da findest Du auch die gesuchte Java-Datei (unter brouter-server/src/main/java/btools/server )

Gruss, Arndt

Hallo Arndt,

vielen Dank. Mein Ziel ist es ein Jar zu generieren. Ich bin keine großer Maven Kenner aber Mapsforge etc. kann ich übersetzen.

Leider schaffe ich das mit Brouter noch nicht. Hast du mir da einen Tipp?

Viele Grüsse
Achim

Nachtrag: Ich habe die depency im pom File von JUNIT auf 4.11 geändert dann gehts…? wie bringt man das mit 4.12 zum gehen?

mvn -DskipTests clean install

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.828s
[INFO] Finished at: Sun Jan 19 17:17:58 CET 2014
[INFO] Final Memory: 11M/31M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project brouter-util: Could not resolve depend
encies for project org.btools:brouter-util:jar:0.98: Could not find artifact jun
it:junit:jar:4.12 in central (http://repo.maven.apache.org/maven2) → [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyReso
lutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command

Sehr schön, freut mich. Danke.

Gruß,
Norbert

Da haben wir was gemeinsam, ich bin da auch noch in der Lernkurve

Eigentlich schon krass, dass Maven, dessen Stärke ja gerade die Handhabung von Dependencies ist, bei den eigenen Dependencies so zickig ist.

Also ich benutze maven-3.05 mit android plugin 3.6.0 und Android SDK platform 10 und Junit 4.11 und es geht auch nur genau in der Kombination (weil ich mir zur Zeit keine neuere Android SDK Plattform installieren will). Ich hatte den Pull-Request zum pom.xml übernommen weil ich dachte ich bin einfach out-of-date mit meinen Tools.

Aber nur um das Jar-file zu bauen (nicht das APK) ist das alles schon mit Kanonen auf Spatzen, man kann’s auch einfach compilieren:

javac -d . brouter-util/src/main/java/btools/util/.java
javac -d . brouter-expressions/src/main/java/btools/expressions/
.java
javac -d . brouter-mapaccess/src/main/java/btools/mapaccess/.java
javac -d . brouter-core/src/main/java/btools/router/
.java
javac -d . brouter-server/src/main/java/btools/server/.java brouter-server/src/main/java/btools/server/request/.java
javac -d . brouter-map-creator/src/main/java/btools/mapcreator/*.java
jar cf brouter.jar btools

Oder in einen Eclipse Workspace importieren…