BRouter: offline Fahrrad-Routing für Android

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…

Hi Arndt,

vielen Dank für die Antwort. Ich übersetze das zur zeit so:

set M2_HOME=D:\apache-maven-3.1.1
set JAVA_HOME=C:\Programme\Java\jdk1.7.0_40
set ANDOID_HOME=D:_AndroidSDK\adt-bundle-windows-x86-20131030\sdk

set Path=d:\apache-maven-3.1.1\bin;%Path%
set Path=D:\gradle-1.9\bin;%Path%

rem mvn -DskipTests=true clean install assembly:single
rem mvn -DskipTests clean install
mvn clean install
rem mvn clean package
rem gradle clean build

mit gradle übersetze ich das Mapsforge-Rescue Framework. Wie schon geschrieben JUNIT habe ich im pom File auf 4.11 gesetzt…

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] brouter … SUCCESS [6.562s]
[INFO] brouter-util … SUCCESS [11.484s]
[INFO] brouter-expressions … SUCCESS [3.657s]
[INFO] brouter-mapaccess … SUCCESS [4.390s]
[INFO] brouter-core … SUCCESS [4.485s]
[INFO] brouter-map-creator … SUCCESS [10.593s]
[INFO] brouter-server … SUCCESS [6.454s]
[INFO] brouter-routing-app … SUCCESS [22.140s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:18.921s
[INFO] Finished at: Mon Jan 20 10:40:30 CET 2014
[INFO] Final Memory: 25M/62M
[INFO] ------------------------------------------------------------------------

Der Brouter und auch Graphhopper funktionieren jetzt in meiner DesktopAnwendung mit dem MapsforgeRescue sehr gut…

Vielen Dank
Achim

Ps.: Ich habe das in IntelliJ importiert, aber das bilden des JAR klappt (noch) nicht… OK. Jetzt auch

…noch ne Frage zum Jar bilden…woher und wie kommt der Manifest File ins JAR? ====>ERROR: kein Hauptmanifestattribut, in brouter.jar

OK so scheint es zu gehen: jar cfm brouter.jar MANIFEST.txt btools

Weiß jemand welche brouter rd5 Dateien von http://h2096617.stratoserver.net/brouter/segments2/ man für die Alps Karte von http://www.openandromaps.org/downloads/europa braucht? Hier die Kartenabdeckung als Bild http://www.openandromaps.org/wp-content/images/maps/europe/Alps.jpg