BRouter: offline Fahrrad-Routing für Android

Danke für den Tipp .-)

Sieht gut aus - jetzt geht`s ans testen.

ludwich

Ich habe heute die Version 0.94 deployed, die diese Änderung enthält. Siehe http://brensche.de/brouter/revisions.html

Alle unterstützten Mapttools (osmand/locus/oruxmaps) werden jetzt immer zusätzlich unter /mnt/sdcard gesucht (genauer: unter Environment.getExternalStorageDirectory() )

Ausserdem habe ich einen Fehler in der Fehlerbehandlung im Service-Interface behoben, so dass man dort jetzt bessere Fehlermeldungen bekommt.

Hallo Arndt,

…werde ich dann mal testen. Danke für das Update.

Bei OruxMaps ist das unangenehm, dass man bei jedem Routen die Parameter neu einstellen muß. Oder dass man das in der Konfiguration einstellen kann. Hast Du einen direkten Draht zu dem Oruxentwickler um das anzuregen, im Forum geht das meistens unter.

Eine andere Frage: Kann mann mit Oruxmaps mit der Routingfunktion auch gleich die alternativen generieren (zB.:Parameter Anzahl=3) und es werden entsprechend Brouter Files erzeugt, ohne BRouter extern aufrufen zu müssen…

Hallo Arndt,

also auf meinem LG_P700 mit der Android Version 4.0.3 läuft das in Verbindung mit Oruxmap jetzt.

Was mir (!) nicht so gefällt ist folgendes, aber man kann damit leben!!!

Ich habe zur Zeit OruxMaps V5.5.3beta11.

OruxInstallationsdir: /mnt/sdcard/oruxmaps/
OruxDaten: /mnt/sdcard/external_sd/OruxData

BRouter DirAnfrage : /mnt/sdcard/external_sd/

-Installation funzt jetzt.

Was mir nicht so gefällt, dass BRouter wenn man den außerhalb von Oruxmaps mit den “from/to” Parametern startet werden die Routingfiles im Oruxmaps dir wo die Datenbank ist abgelegt ==> /mnt/sdcard/oruxmaps/tracklogs

und nicht im erwarteten OruxDatendirektory also auf ==>/mnt/sdcard/external_sd/OruxData/tracklogs

Oruxmaps sucht aber DEFAULT mäßig im konfigurierten Daten-Verzeichnis:==> /mnt/sdcard/external_sd/OruxData/tracklogs

Somit muß man jedesmal beim Laden der “brouterx.gpx” Files jedesmal das Direktorie wechsen und das ist unschön.

Schön wäre auch, wenn man mit einem Lauf von BRouter gleich x Alternativen (zB: 4) generieren könnte, ohne jedesmal den BRouter zu beenden und wieder neu zu starten.

Aber ich kann damit leben und das soll nur als eine konstruktive (!!!) Kritik aufgefasst werden.

Für Deine Arbeit nochmals vielennDank
Achim

Habe heute die Version 0.9.5 von BRouter deployed ( http://brensche.de/brouter/revisions.html )

Neben einer allgemeinen Performance-Verbesserung und einer Sonderlocke fürs Car-Routing (“car-subset” files) addressiert das insbesondere das Problem des Timeouts im Service-Interface, und ich nenne das “timeout-free recalculations”.

Das alles mit dem Ziel, eine praxistaugliche Lösung für die Langstrecken-Navigation zu schaffen.

Ist im Moment noch bisschen akademisch, weil das Service-Interface ja bisher nur von Oruxmaps unterstützt wird, und Oruxmaps aber keine dynamische Neuberechnung macht, wenn man von der Route abweicht. Locus unterstützt das Service-Interface aber in einer beta-Version auch schon ( http://forum.locusmap.eu/index.php?topic=3423.msg24024#msg24024 ), und Locus kann dynamisch neu berechnen.

Ich selbst benutze es aber meist mit OsmAnd und einer ziemlich wackeligen Proxy-Strecke, denn OsmAnd selbst kann BRouter noch nicht direkt aufrufen.

Wa jetzt funktoniert ist, bis zu mittleren Distanzen (=30km Luftlinie Fahhrad, 50km Luftlinie Auto) einfach garnicht drüber nachzudenken, sondern einfach das Ziel in’s Maptool einzugeben, und bis zu "gewöhnlichen Langstrecken (300km Fahhrad, 500km Auto) die Strecke einmalig über die BRouter-App zu berechnen (was dann 10 Minuten dauern kann), dem dann aber per Zielfürhung mit schnellen automatischen Neuberechnungen nachzufahren.

Aber wie gesagt: interessant wird das, wenn OsmAnd das kann (ich bleib dran…).

Hallo

ich habe mir mit dem BRouter Bundle 0.92 eine Desktopanwendung in Verbindung mit dem GPXCreator zusammengebaut. Das funktioniert eigentlich sehr gut, aber nur für kurze Strecken. Ich finde keine Möglichkeit das “Ende” eines Routingauftrags an BRouter zu erkennen. Nur die Abfrage ob der entsprechende File da ist scheitert, weil dieser vermutlich noch nicht vollständig generiert ist.
Eine Funktion die wartet und das Ende des Routingauftrag signalisiert wäre super.

Gibts dafür eine Lösung oder ein neues Desktop Bundle?

Wird die Dektopvariante (API) weiterhin gepflegt und unterstützt?

Derzeit wird auch im Routconverterforum über eine Integration vom BRouter in Verbindung mit dem Mapsforge-Rewrite diskutiert, dazu sollte aber die obige Funktion realisiert werden können.

Ich habe im Google Forum sinngemäß die gleiche Frage gestellt, da ich erst heute entdeckt habe.

Grüsse Achim

Ps: Ich habe mal das brouter095.jar versucht, analog zu der brouter095.jar Version, aber da wird keine Ausgabe generiert. WindosXP mit Java 1.7
Segmente und Profiles sind geladen.
Gibts für das Main Programm wieder eine Source?

Aufruf:



D:\GPS\BRouter\brouter_0_9_5>java -jar brouter095.jar segments2 8.774144 48.914457 8.821399 48.913996 profiles2/trekking.brf
BRouter 0.95 / 01092013 / abrensch

...keine weiter Ausgabe und es wird kein GPX File generiert.....


Hallo Achim,

und sorry, dass ich bisschen “mailfaul” war.

Ja, das ist genau die Idee, dem distribution-zip zukünftig immer auch die Server-Variante als jar-file beizufügen, und in der 0.95 ist’s ja drin, nur leider, wie Du ja festgestellt hast, nicht ganz zuende getestet. Und leider auch nicht dokumentiert, die wenige Zeit, die ich letzte Woche hatte, hat einfach nicht gereicht und mein Focus war die Performance und dieser timeout-freie Neuberechnungsmechanismus im Service-Interface, war mir wichtig, aber eine harte Nuss.

Ich habe tatsächlich in 0.95 den asynchronen Aufruf, der Deine Probleme mit dem Abbruchkriterium verursacht, eliminiert (das war ja nur für die Android-App sinnvoll) und durch einen ganz normalen synchronen Aufruf ersetzt. Daher kommt aber der Fehler, den Du unten beschreibst, da fehlt noch eine Anpassung.

Ich bring das heute abend mal in Ordnung und schick Dir dann die passenden Sourcen.

Hallo Arndt,

gibt es schon eine “NEUE” Desktop Version mit dem synchronen Aufruf?

Grüsse Achim

Ja seit eben gibt es die Version 0.96: http://brensche.de/brouter/revisions.html

Den Source-Code habe ich Dir per Email geschickt.

0.96 beinhaltet im wesentlichen Bugfixes, aber etwas interessantes ist auch dabei für die, die sich für den Algortithmus näher interessieren.

Denn erstens habe ich den bisschen beschrieben: http://brensche.de/brouter/algorithm.html

Und zweitens die “heuristischen Koeffizienten” in die Konfiguration übernommen, sodass man sie ändern kann und damit rumspielen (und z.B. die superschnellen, aber ungenauen Berechnungen herbei-patchen, von denen manche ja glauben, bei OsmAnd, Skobbler, Navit und co. könnten die Entwickler zaubern…)

Und noch was interressantes habe ich: ich hab’s geschafft, OsmAnd aus den Sourcen zu bauen (in der Version ohne native Bibliotheken) und da die direkte Schnittstelle zu BRouter reingebaut. Das ganze ist noch schwebend als Pull-Request auf GitHub:

https://github.com/osmandapp/Osmand/pull/537

Aber eine Binär-Version habe ich jetzt einfach mal bei mir hochgeladen:

http://h2096617.stratoserver.net/brouter_bin/osmand_161_alpha_nolibs_brouter.zip

Das ist natürlich Bastelkram, ohne die nativen Libs ist das rendering schon spürbar langsamer, und das APK ist mit dem Debug-Key signiert (man muss also eine release-version erst deinstallieren), und paar Übersetzungen musste ich auch löschen, aber die Verbindung zu BRouter funktioniert tadellos und die automatischen Neuberechnungen (auch bei langen Strecken) machen richtig Freude.

Ich denke, ich bin da mit der GPL-Lizenz von OsmAnd im reinen, habe ja den Source-Code der Änderung als Pull-Request publiziert und das ganze im beliegenden readme.txt beschrieben - wenn’s jemand besser weiss wäre ich für einen Hinweis dankbar.

Ich bin guter Hoffnung, dass der Patch in die OsmAnd releases eingeht, Victor ist noch bisschen zickig und will z.B., dass man die Option in OsmAnd nur sieht, wenn BRouter bereits installiert ist, aber das krieg ich hin.

Hallo Arndt,

die neue Version mit dem sychronen Routingaufruf funktioniert jetzt bei mir sehr gut!

Vielen Dank
Achim

Könnte man das nicht einfach als Plugin für OsmAnd machen, oder wäre das zu aufwendig?
Einige Features von OsmAnd sind ja eh schon als Plugin ausgelagert (Parking, Höhenprofil …).
So wäre man etwas unabhängiger von Victor und seiner OsmAnd-Entwicklung.
Wenn der BRouter sowieso noch extern installiert werden muss, könnte man das gleich
ins Plugin bündeln.

Hallo Arndt,

ich habe mal die 096 Version auf meinem LG P700 mit Android 4.0.3 und auf einem Huawei X3 mit Android 2.3.3 installiert, das läuft soweit mit OruxMaps zusammen.

Mir ist folgendes aufgefallen:

Startet man BRouter und routet from/to kommt am Ende bei der Version 0.95. Man kann also nict erkennen ob die 0.96 installiert ist.

Ferner ist bei der Android 4.0.3 das leidige Problem mit den Pfadangaben. Routet man mit BRouter mit from/to/via1…viax/ werden die Ausgabefiles auf die interne SD Karte abgelegt.

Bei mir zB: /mnt/sdcard/oruxmaps/tracklogs

Erwartet bzw. gewünscht hätte ich mir, dass das auf der externen SD Karte liegt bei mir zB.:

/mnt/sdcard/external_sd/OruxData/tracklogs

da dieses auch das “standard” Direktory für Oruxmaps zum Laden von Tracks und Routen ist.

Ist das im Sinne des Erfinders (Bug oder Feature)?

Grüsse Achim

Zwei Fragen:

  1. Gibt es in der Android-App (irgendwie) eine Möglichkeit, sich die aktive Zuordnung zwischen den Profilen und Service-Modes (als Übersicht) anzeigen zu lassen?

  2. Gibt es bzw. und wenn ja wie sehen die Planungen in Richtung Sprachunterstützung aus?

Gruß Klaus

Der BRouter braucht sowieso noch eine Karten-App.
Bei OsmAnd ist die Sprachunterstützung bereits eingebaut.
Die funktioniert auch, wenn die Route nicht vom internen Router berechnet wurde,
sondern als GPX hinzugeladen wird.

Braucht BRouter auch bei der OsmAnd-Integration noch zusätzliches Kartenmaterial
zum Routenberechnen, oder greift der dann direkt auf die OsmAnd-Karten zu?

Eine allgemeine API für Routing-Provider stelle ich mir für Routing-Apps schwierig vor,
weil man ja nicht nur eine Route auf Anfrage zurückgibt (so wie bei Online-Routern),
sondern bei der Berechung auf App-Interna wie das Kartenmaterial zugreifen muss/möchte.
Je nach App haben die Karten auch verschiedene Datenformate.
Es wäre schon unpraktisch, wenn man Kartenmaterial doppelt installieren müsste,
einmal fürs Routing und einmal für die Kartenapp.

Wie ist das mit den Höhen? Könnte man die
Germany_europe_srtm_elevation_contour_lines_2.obf
von OsmAnd nicht für BRouter nutzen? Ist vielleicht schwieriger, weil es
nur die Höhenlinen sind und nicht Höhenrasterdaten wie im STRM-File.

Leider ist meine SD-Karte schon voll. Weitere Karten kann ich nicht mehr installieren.

BRouter hat seine eigenen Routing-Daten in Form von 5°x5° Quadraten, die ca. 250-300MB groß sind. Normalerweise kommt man in seiner weiteren Heimatregion mit 2, maximal 4 davon aus. In Locus kann man mittlerweile für eine geführte Navigation BRouter genauso auswählen wie andere Navigationsdienste. In OSMAND kommt das hoffentlich noch, ein Pull-Request dafür wurde vom Autor jedenfalls gemacht.
Bei OSMAND steht das natürlich in einer gewissen Konkurrenz zum eingebauten Offline-Routing, aber im Vergleich wird speziell das Fahrradrouting in OSMAND eher stiefmütterlich behandelt, Einbahnstraßen mit erlaubter Gegenrichtung werden z.B. immer noch nicht berücksichtigt.

Hi,

hier mal gebündelt Antworten zu den letzten 3 Beiträgen:

Ja, also hellsehen kann ich nicht, und der “Sinn des Erfinders” ist tatsächlich, nach der aktuellsten Wegpunkte-Datenbank zu suchen und relativ von da das Tracks-Directory zu vermuten. Wenn in Oruxmaps was anderes konfiguriert ist, komme ich da nicht ran.

Werde aber in der nächsten Version als Workaround eine Weiterleitungs-Mechanismus hizufügen, so dass man dan im “falschen” Zielverzeichnis ein redirect-file ablegen kann, in dem der Pfad zum “richtigen” Zielverzeichnis steht.

Nein. Aber seit 0.95 liegen diese Konfigurations-Dateien auf der SD-Karte (brouter/modes) so dass man sich die Dateien anschauen könnte, wäre aber bisschen mühselig.

Ich werde in der nächsten Version nach dem Speichern der Service-Konfiguration noch einen Feedback-Dialog nachschalten, in dem die gesamte Konfig als Übersicht gezeigt wird (nur Profil-Name und Zahl der Nogos)

Meinst Du Mehrsprachigkeit der App oder meinst Du Sprachausgabe?

Nein, die App weiter aufzubohren in Richtung Mehrsprachigkeit hab’ ich keine Ambitionen. Deutsche Doku steht aber schon weit oben auf der Liste.

Thema Sprachausgabe ist aber spannend. Wie openzzz schon schreib, macht OsmAnd das ja schon recht ordentlich, aber auch OsmAnd kann zusätzliche Informationen vom Router verwenden, um bessere Ansagen zu machen, und Locus ist ohne solche Infos ziemlich sprachlos, also das ist natüclich Thema, diese Information zu liefern, also Sprach-Hinweise, die nicht nur aus dem Verlauf der Route abeleitet werden (“jetzt rechts”), sondern tatsächlich aud dem Netztwerk (“an der nächsten Kreuzung geradeaus”).

“Hemdentaschen-Navigation”, also SPrachhinweise, die so gut sind, dass man die Karte nicht mehr braucht, wäre ein coole Sache.

Nein, BRouter braucht immer seine eigenen (*.rd5) Dateien

Nein, mit sowas wird man nicht froh.

Naja, bei < 1Euro/GB hat der eine oder andere den einen Euro für Deutschland-Abdeckung mit RD5-Files schon übrig.

Meine 32 GB µSD ist voll. Die 64’er kostet 44€. Kaufe ich erst wenn es unbedingt notwendig ist, also nicht diesen Winter.
Einige Gigabytes gehen schon für die Wikipedia EN+DE drauf. Das ist offline im Urlaub ganz praktisch.
Luftbildkarten und Raster-Topo-Karten schlucken auch recht viel.

Leider brauchen die meisten Routing- und Kartenapps jeweils eigene spezielle Karten.
mapsforge können sich noch Locus und Orux teilen, aber der “MapFactor Navigator” braucht
wieder eigene. OsmAnd hat auch ein eigenes Format.

Ich hatte es schonmal angesprochen: kann man sich nicht irgendwie auf ein Vektorformat einigen,
damit man die Länder nicht doppelt und dreifach installieren muss?
Hat RD5 einen Vorteil gegenüber dem OsmAnd-Kartenformat?
Zumindest ist OsmAnd OpenSource, d.h. das Format und der Code zum Lesen und Schreiben ist publik.
Es gibt auch noch ein PC-Programm für OsmAnd zum Erzeugen der OSM-Karten.
Falls die Unterschiede zu RD5 nicht groß sind könnte man das bestimmt irgendwie verheiraten.
Vor allem brauchst du dann nicht einen eigenen Distributionszweig für RD5-Karten aufbauen.
Die OsmAnd-Karten liegen für viele Länder auf dem Downloadsever bereit (http://new.osmand.net/list.php)

Für die Höhenkarte, Ok, das ist ein anderer Fall. Die Höhenprofilkarte (Höhenlinien) kann man so nicht nehmen.

Naja beim navigieren kommt es immer darauf an, dass die verfügbaren Tags richtig interpretiert und dann gewichtet werden. Beim navigieren kommt es ja nicht immer darauf an den kürzesten zulässigen Weg zu finden. Manchmal möchte man auch den schnellsten/schönsten Weg haben.
Und OSMAND wie auch andere Vektorkarten werten einfach nur den für sie relavanten Teilbereich der Keys aus. Möglicherweise wird dann auch gleich noch ein “Mittelwert” berechnet, um dann nicht die “ganze Arbeit” im Mobildevice zu machen.
Daher wird es schon grundlegende Unterschiede geben. Zumal sich rd5 eben gerade nicht um Darstellbarkeit und aussehen kümmert.

Zu 1: Unterstützung in der nächsten Android-App … das hört sich gut an. In welche Datei müßte man, bis es soweit ist, denn reinschauen?

Zu 2: Ja, ich meinte die Ausgabe von Sprachtexten während der Streckenführung. Du hast es aber auf den Punkt gebracht: “Hemdentaschen-Navigation, also Sprachhinweise, die so gut sind, dass man die Karte nicht mehr braucht, wäre ein coole Sache.”

Ich übernehme deine Antworten (in den nächsten Tagen) mal ins Locus-Forum: http://forum.locusmap.eu/index.php?board=27.0 Die User dort sind zwar nicht so viele, aber sehr bemüht die Dinge weiter zu entwickeln.

Gruß Klaus

PS: Vielleicht hast du aber Lust dich im Locus-Forum selbst zu äußern …

Das Wegenetz (die ganzen Knoten und Polygonzüge/Koordinatenlisten) braucht man aber für beide Zwecke. Es stehen noch ein paar Infos zur Berechnung der Pfadmetrik drin, und die Verknüpfungen der Wege, aber eigentlich lässt sich das gut verheiraten. Mit einer Datenbankstruktur (sqlite-File?) incl. Index ist auch der Datenzugriff relativ flott. Auch für eine routingfähige Display-Karte kann man viele Keys weglassen oder effektiver speichern.

Die Trennung ist natürlich dann praktisch, wenn BRouter für andere Apps als OsmAnd routet und deren Karten nicht routingfähig sind. Als OsmAnd-Plugin wäre es aber schon praktisch wenn es die vorhandenen routingfähigen Karten nutzen könnte. Die muss man sich vor einem Urlaub sorgfältig zusammenstellen, damit alles auf die SD-Karte passt. Europa gesamt wäre schon heftig. OSM hat eben viel mehr Details in der Karte als bei den kommerziellen Routing-Lösungen.

Gibt es bei den Entwicklern Interesse, einen gemeinsamen Standard für routingfähige Vektorkarten zu formulieren? So wie bei mapsforge für die nicht routingfähigen? Wäre das OsmAnd-Kartenformat ein guter Einstieg,?