BRouter: offline Fahrrad-Routing für Android

…NEIN! Deshalb habe ich mich auf den Weg gemacht auf dem Desktop ein Tool zu schaffen, mit dem ich meine Mapsforge basierenden Vektorkarten anschauen kann. Dazu war das Mapsforge Rewrite mit dem Desktop SwingMapViewer eine Steilvorlage und ein Grund zum Einstieg in diese Thematik.

Weiterhin kam hinzu, dass der BRouter leicht zu integrieren war. Somit habe ich eine vertraute Umgebung für meine Android / Oruxmaps Karten/ und BRouterwelt auf dem Desktop. Somit habe ich auch auf dem Desktop einen “grafische” Routenerstellungsmöglichkeit, ohne Onlineverbindung. Karten und Routen sind 1:1 austauschbar.

Wenn sich das Ganze stabilisiert hat kann man eventuell auch über eine Weitergabe auch nachdenken…aber dazu bedarf es einer vernünftigen Doku bzw. Infoseite und das machen Entwickler sehr ungern.

Ps.: Nebenbei eine Frage an NOP.:

Ich weiß ich soll einen eigenen Thread aufmachen, aber weiter oben habt Ihr weit ab vom Thema diskutiert…

Welcher Router steckt hinter der “wanderreitkarte” und wo könnte man Infos für eine lokale Integration und Konfiguration finden?

Es ist eine Schwäche im Wegpunkt-Matching von BRouter. Ich durchsuche für den Match (=nächste Entfernung zu einem in diesem Profil routbaren Weg) nur in 4 1/80-Grad Kacheln, also einem Gebiet von ca 2,5km*2,5km. Ein solcher Wanderweg, der kilometerweit keine Verzweigung hat, kann mir dabei entgehen. Ich werde das nochmal verbessern, also z.B. das Suchgebiet vergrössern, wenn der Match so weit danebenliegt oder lange Wegabschnitte unterteilen. Danke für den Hinweis.

Das “or” hätte noch weg gemusst, sonst ist die Hirarchie des Ausdrucks kaputt. Aber wie gesagt, access=no ist hier ja nicht das Problem.

Ja zu schnell, wie ich finde, die Schwelle liegt bei 30m. Ja, die Funktion ist fast völlig identisch, nur dass BRouter keine Strassennamen liefert (also wenn Du Strassennamen hörst, hast Du den falschen Router eingestellt…) und bei Langstrecken ist das Verhalten anders: BRouter hat einen Timeout von 60 Sekunden, OsmAnd-Intern hat keinen Timeout, verschluckt sich aber irgenwann am Memory-Limit. BRouter kann aber “timeout-freie” Neuberchnungen, wenn zu dem selben Zielpunkt schon eine Route berechnet wurde, und diese Vorberechnung kann man alternativ auch über die BRouter-App machen, so dass man auch Langstrecken mit automatischen Neuberchnungen über OsmAnd (oder Locus…) abfahren kann.

Nein, OsmAnds Plugins sind ja nur eine Mogelpackung, mit modularer Software hat das nichts tu tun. Ich hab’ den Patch als Pull-Request in Guthub eingestellt und erwarte eigentlich, dass Victor ihn “merged”, und dann ist es ganz normaler Bestandteil der Releases.

Hallo Arndt,

in diesem Zusammenhang ein Vorschlag für zukünftige Versionen?

Sollte der gefundene Routen-Endpunkt xxx m vom vorgegebenen Zielpunkt oder yyy m Höhe entfernt sein wird die gefunden Route verworfen. Im Extremfall “keine” Route gefunden.
Möglichkeit der Vorgabe der Maximalen Alternative Routen und der Router gibt die Anzahl der gefundenen Routen (tmp Files) zurück.

Das ist im Falle von Bergwanderrouten wichtig: Worst Case…Es führt genau 1 Weg zum Gipfel, aber es wird ein Routenendpunkt 500m entfernt aber 1000m tiefer gefunden…

Wie denkst du darüber?

Ok. Prima. Dann wird das sicher bald meine bevorzugte Routing-Engine. Meistens, so wie heute, benutze ich OsmAnd nur informativ als Karte und als GPS-Logger. Wahrscheinlich komme ich erst wieder im Frühjahr zu längeren Touren in unbekannte Gebiete. Im Winter fahre ich nicht gerne. Bis dahin ist BRouter dann hoffentlich schon in der Release-Version von OsmAnd drin. Meinst du das funktioniert mit Victors Plänen zur C+±Umstellung? Ich kann mir nicht vorstellen, dass die App komplett nach C++ umgestellt wird. Geht das überhaupt bei Android? Ich dachte die App-APIs sind in erster Linie in Java ausgelegt und C++ hat dann im Prinzip nur die Linux-Betriebssystem-APIs zur Verfügung. Ich sehe den Mix verschiedener Programmiersprachen nicht so kritisch. Bei mir nutze ich oft mathematischen Code aus Fortran, der über DLLs angebunden wird. Fast alle Supercomputer machen das so für HPC. Bei klar definierten Schnittstellen und unabhängigen Modulen ist das kein Problem. Auch der Mix von Python und C++ ist sehr beliebt in der OpenSource-Welt.

Also hatte ich das vorher richtig eingeschätzt, dass das Memory-Limit die größte Einschränkung beim Routing ist, oder? Mein Billig-Samsung hat nur ca. 150 MB RAM. Das ist nicht viel.

Dass du dein Wegenetz konsequent auf Routing-Performance optimiert hast ist verständlich. Aber ist das so stark reduziert, dass du keine Referenz (ID, Index, Pointer) mehr zur OsmAnd-Vektorkarte herstellen kannst? Da stehen die Straßennamen schon drin.

Ok, so hatte ich das auch ursprünglich verstanden. Dann muss ich wohl auf die nächste Release warten.

Aber was ist das Problem mit den Plugins aka “Zusatzmodule” ? Die werden im Android-Market separat zum Download angeboten (Parking-Plugin, STRM-Plugin etc.) Oder sind die alle schon im Hauptprogramm vorhanden, werden quasi durch den Extra-Download nur freigeschaltet? Ein modulares Plugin-Konzept ist natürlich schwieriger zu realisieren. Ein Routing-Plugin würde Zugriff auf interne Datenstrukturen benötigen, z.B. auf die Kartendaten, die in OsmAnd geladen werden.

in dem Zusammenhang eine interessante Meldung:

Dalvik-Nachfolger: Google lädt zum Testen der neuen Android-Runtime ein
http://www.heise.de/newsticker/meldung/Dalvik-Nachfolger-Google-laedt-zum-Testen-der-neuen-Android-Runtime-ein-2041644.html

Man kann Java natürlich auch normal zum Maschinencode statt Bytecode compilieren. In GCJ gibt es das schon länger (wohl nicht so gut optimiert). Google will das jetzt auch für Android umsetzen. Maschinencode ist einfach vom Prinzip her schneller als Bytecode. Bytecode ist für ARM und x86 immer ein Fremdkörper, der in virtuellen Maschinen emuliert werden oder übersetzt werden muss. Nur spezielle Java-Prozessoren können den ausführen. Bytecode hat sicherlich Vorteile, ist aber nie performance-optimal.

Verschiedene Sprachen geben aber verschiedene Möglichkeiten, einen Algorithmus zu optimieren. Java und Python leiden darunter, dass man die Speicherbytes durch Pointer nicht so gut unter Kontrolle hat. Das wird der ART-Compiler von Google auch nicht lösen können. Das ist sprachinhärent.

Es kann durchaus sein, dass es für das Routing-Problem keine so große Rolle spielt, denn die Speicherverwaltung im dynamischen Routing-Graphen würde man vermutlich auch in C++ nicht manuell übernehmen.

Einen Unterschied gibt es auch bei den Datentypen. Bei Java wird immer eine virtual table für Objekte benötigt (richtig?). Wenn massenweise Datenobjekte verwaltet werden (z.B. in Vektoren und Matrizen), ist das deutlich weniger effizient als C+±Objekte ohne virtual tables.

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?