BRouter: offline Fahrrad-Routing für Android

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,?

Schau dir einfach mal die Diskussion zu Graphhopper an. Dort stoßen verschiedene Theorien aufeinander.

Graphhopper benutzt laut Infoseite schnellere Varianten des Dijkstra
mit vorausberechneten Daten.

Die Dateigrößen der rd5 sind ja doch recht kompakt.
Na, vielleicht passt das dann doch nicht so recht zusammen.
Man müsste schon im Detail die Datenstrukturen vergleichen.
Vielleicht hat auch OsmAnd einen kompaktierten Datensatz für das Routing
drin, der lediglich aus den Knoten und Verbindungsmetriken besteht.

Ich verstehe euer Problem: je besser sich BRouter in OsmAnd integriert
desto schwieriger wird die Unterstützung für andere Kartenapps.
Mein Favorit wäre natürlich eine Totalintegration in OsmAnd, so dass
alle dortigen Vorzüge genutzt werden, die Kartenbasis und die Möglichkeit
des Routen-Neuberechnens.

Gerade das ist mir unterwegs auf dem Rad wichtig, da ich immer wieder
mit Absicht von der Route abweiche, und vom Router verlange, dass
er das gleich berücksichtigt, ohne anzuhalten und am Gerät herumfummeln zu müssen.

Ich weiss nicht, ob die anderen Apps dafür die Voraussetzungen mitbringen.
Jedenfalls ist eine OsmAnd-Integration einfacher, weil der Sourcecode frei ist.

Jetzt fehlt nur noch das schöne Wetter zum Testen.
Als die Sonne geschienen hatte musste ich noch im Büro sitzen …

OsmAnd und Brouter … ob das eine Erfolgsgeschichte wird bzw. werden kann?
M.E. eher nicht … Zuviele Köche verderben den Brei.

Gruß Klaus

Hallo Brouter Gemeinde,

ich hab mal “just for fun” den BRouter in einen Desktop-MapsforgeViewer eingebaut. Das GANZE ist “gefrickelt” und in einer frühen Beta Phase. Aber das funktioniert erschreckend gut. Ich habe als Ziel, dass ich auf einem Windows PC meine “Fahrradrouten” und “Wanderrouten” planen kann. Was mir besonders gefällt ist, dass im BRouter “vernüftige” alternative Routen berechnet werden, zumindest soweit ich das beurteilen kann.
Ich hoffe, dass BRouter nicht nur in Richtung OSMAND geht und die “Desktop-Schnittstellen” erhalten bleiben und weiterentwickelt werden. Das ist eine persönliche BITTE an Arndt.

Arbeitet daran noch jemand (Thema:Desktop-Mapsforge-Router)?

In diesem Sinne
Achim

Ps: An die Grashopper-Kenner…wie kann man Grashopper in eine DesktopAnwendung einbinden? Keine ServerVersion sondern über eine entsprechende API-Schnittstellle like BROUTER?

Zwei Meister ihres Fachs. OsmAnd hat die Kartenapp und einen mittelmäßigen Router. Brouter hat den besten Router (to be field tested), aber mangelt es an einer Karten-App. Beide ergänzen sich gut.

Welche Alternativen gibt es? OsmAnd ist die einzige gute Karten-App, die als OpenSource publiziert wird.
Ich finde auch wesentlich besser als Orux und Locus (Wikipedia-POI mit Kurztexten, Offline-Suche in POIs, Einblenden der POI,
vor allem Routing an POI-Ziele, Routing entlang GPX-Strecke, Auto/Rad/Fußgänger-Profile, Offline-Routing).
Die Waypoint-Verwaltung ist vielleicht bei anderen besser ausgereift,
aber über Favoriten doch noch machbar.

Nur wenn man als Radfahrer in der Nacht Routing-Unterstützung braucht und das dumme Teil dann
über die Gipfel steigen will, mangels Höheninformation, dann merkt man, dass noch etwa fehlt.

Und für Locus und Orux nicht vergessen, denen fehlt ja auch das Offline-Routing.

…das verstehe ich nun nicht! Oruxmaps kann doch in Verbindung mit BRouter "Offline-Routing, oder habe ich da was falsch verstanden? Ich nutze das ständig.

BRouter ist doch auch eine Art Server. Was also spricht dagegen den Graphhopper als Server zu starten und dann anzusprechen?

Also BROUTER hat eine entscheidende Schwäche. Er kann gut Fahrradrouting und vielleicht auch für Wanderer. OSMAND hat aber auch Autofahrer als Ziel. von ÖPNV wollen wir mal gar nicht reden. Das macht wahrscheinlich derzeit noch keine offline App.

Meinte ich ja. Ohne BRouter würden die beiden ohne Offline-Routing-Lösung dastehen. OsmAnd hat schon eine eingebaut, mit Sprachansage. BRouter wäre nur eine Verbesserung der Routingfunktionalität für Radfahrer.