BRouter: offline Fahrrad-Routing für Android

Ich bin darauf angewiesen, Qualitäts-Feedback aus dem Beta-Test zu sammeln, um das Ding erstens fehlerfrei zu kriegen und die Funktionalität an die Erwartungshaltung der Benutzer anzupassen. Und funktioniert ja bisher auch ganz gut und bin ja schon ein ganzes Stück vorangekommen.

Nur: dafür muss ich von den neuen Fehlern erfahren und nicht von den längst behobenen aus älteren Versionen. Und dazu ist es wichtig, die Kontrolle zu behalten über die Versionen “im Feld”. Alle machen das so, nur eben über automatische Updates oder ein serverseitig gesteuerten Update-Trigger.

Mir ist es aber wichtig, den “offline”-Charakter der App nicht anzutasten und Datenschutz-sensitive Benutzer nicht zu verschrecken indem da irgendwas “nach Hause telefoniert”. Also geht das nur mit einem clientseitig gesteurten Expiry.

Ja, schon, wenn’s halbwegs fertig ist. Eigentlich wollte ich auch jetzt soweit sein, aber ich hab’ noch zu viele Ideen im Kopf. Vielleicht sehe ich das ja falsch, aber fehlende Turn-Restrictions, das “schlampige” Wegpunkt-Mapping, die rein technische Beschränkung auf die Zahl der Osm-Tags etc das ist alles noch “zu beta”.

Ähnliches Thema mit der deutschen Dokumentation. Würde definitiv die Nutzerzahlen pushen, aber auch eine Support-Last erzeugen, die die Weiterentwicklung bremst. Also im Moment keine Priorität.

Und es gibt natürlich den Wunschgedanken, irgendwann in Google-Play zu gehen mit einer “Killer-App”, die nicht mehr nur paar hundert, sondern Hunderttausende Benutzer finden kann. Das wäre dann aber nicht mehr der nackte Offline Router, sondern eine integrierte Anwendung, und der Offline-Router in seiner jetzigen Form würde (werbe-)frei bleiben.

Gruss, Arndt

Hallo Arndt,

das hört sich alles sehr gut an! D.h. Du hast große Pläne mit der App und das freut mich sehr! Meine Befürchtung war, dass das Projekt irgendwann einschlafen könnte und dann wenig später auch die App nicht mehr funktionieren würde. In dem von Dir vorgesehenem Szenario bin ich gerne Beta Tester! Ich mag Radfahren und ich mag Radfahrer. Je mehr Menschen auf das Rad umsteigen und das Auto häufiger stehen lassen, desto besser für uns alle :D. Wenn die Version in der bisherigen Art frei bleibt, ist das mehr als fair. Ich drücke die Daumen, dass eine Killer-App dabei rauskommt und trage gern dazu bei, dass die aktuelle Version noch besser wird :).

Hi Arndt
Danke für den Tipp mit dem Kostenfaktor und den via-points.
Aber mal wieder zurück zur Sache, auch um Dir zu bestätigen, daß Du auf dem richtigen Weg bist. Ich finde das der Beta Status schon extremst vielversprechend ist.
Mich stört jetzt eigentlich nur noch eines konkret an Deinem Brouter—das direkte ansteuern der via-points.
Praktisch schaut es so aus, das ich z.B. von Redwitz nach München mit dem Fahrrad fahren möchte-also setze ich via-points-vollkommen logisch.
Allerdings will ich einfach nur sagen–hey Junge–fahre bitte über Bamberg(via) - aber bitte nicht direkt auf dem via-punkt(meist das geographische Zentrum wenn ich in Locus einfach Bamberg als Suchkriterium schnell auswähle) - sondern einfach praktisch Richtung Bamberg aber immer schön dem Profil entsprechend.
Ich denke Du weißt was ich meine— eine Art ungefähre Richtungsangabe
praktisch1 würde ich dann vorschlagen so eine Art “via1-around2000(2km um den Punkt herum)” für die ungefähre Richtung.
praktisch2 würde ich dann für ein direktes ansteuern des via-punktes das “via1” so belassen.

Via bedeutet in dem Sinne für mich — Hey klasse, genau in den Biergarten will ich reingehen als Zwischenziel
Via-around bedeutet für mich — kein Alkohol am Steuergrins - aber fahr mal trotzdem in die Richtung des Biergartens.

Da bin ich ja mal gespannt auf Deine Killer-App , da bin ich voll dabei weil ich merke, daß Du genau weißt was Du tust und der Weg einfach passt.
Aber bitte keine Experimente mit Online-Kartenmaterial bzw. Online Verbindung während des Routings.
Wobei ich ganz ehrlich sagen muß, daß ich bereits mit dem jetzigen Zustand sehr zufrieden bin. Am besten ist es in Locus integrierbar, da ich einfach in Locus über die Bedienfelder eine App hinzufügen kann (Dein Brouter) ohne Locus klein schalten zu müssen.
Ein grafisches Interface hast Du Doch in Form von ORUX,OSMAND,LOCUS. > Punkte in der Karte antippen-benennen-Brouter starten > das finde ich sehr komfortabel.
Deine Punkte kann man ja auch schon an-abwählen.
Die App im jetzigen Zustand trifft den Tourenplaner doch eigentlich schon mitten ins Herz.
Ganz klar, ich kann aber Deinen Anreiz nach ner eigenständigen App voll verstehen-zumal Du irgendwann auch mal “Cash” dafür sehen willst.

In diesem Sinne weiter so und ich hoffe das ich mit den ein oder anderen Vorschlägen behilflich sein kann.
Ich programmiere selbst in C und Basic intern in der Firma für unser CAM-System und weiß um die ganze Problematik außen herum … es hört sich immer so einfach an…Ratschläge: mach mal dies und das…aber warum hast Du nicht?..
LG Volker

P.S. : Routenberechnung von Redwitz nach München über via Points !!! “Darf ich dich küssen??” das passt-klasse.

@Arndt:

Kennst Du eigentlich OpenAndroMaps? Das sind großartige weltweite offline Radvektorkarten aus den Daten der OpenCylceMaps. Das Projekt wird von Christian umgesetzt - einem Radfahrer, der sich auch gerne für die Community einsetzt - und das mit Herzblut. Seine Karten sind unschlagbar gut! Eine Offline App mit Deinem Routing, seinen Karten und einem intuitiven Interface wäre die Erfüllung der kühnsten Träume aller Radfahr-Navigatoren ;)!

Ach: Den Punkt von Volker zu den “via1-around” kann ich voll unterstützen! Finde ich sehr sinnvoll und habe ich mir auch schon mal gewünscht.

So, mal meine 2 Cents zur Killer-App :slight_smile:

Wenn Du wirklich die Killer-App willst, ist ja das wichtigste, den Need zu analysieren. Ich fasse hier mal meine Sicht zusammen:

Der Schwachpunkt aller Smartphones ist der Akkuverbrauch des Displays. Beim Energieverbrauch haben OutdoorGPS gegenüber Smartphones einfach das intelligentere Display. Also muß man mit dem Energieproblem umgehen. Hier mein bisheriger Ansatz:

Ich nutze aktuell Dein Routing zusammen mit den OpenAndroMaps in OruxMaps. Zusätzlich setze ich Wegpunkte an Stellen, an denen ich auf die Karte schauen sollte, weil ich nicht nur einfach geradeaus fahren kann. Wenn ich nicht zu faul bin, versehe ich die Wegpunkte mit Text, der dann über OruxMaps ausgesprochen wird, wenn ich an den Koordinaten ankomme. So sagt mir OruxMaps “halb links” und ich weiß Bescheid. Allerdings muss ich den Ansage-Text immer umständlich in den Wegpunkt schreiben (sehr nervig). Wenn ich faul bin, setze ich die Wegpunkte ohne Text (bei 100km braucht man 5-6min, um die ganze Strecke durchzugehen), lasse ich mich am WegPunkt nur akustisch alarmieren und schaue dann kurz auf die Karte. Vorteil im Vergleich zum OutdoorGPS: Ich muss nicht immer auf die Karte schauen. Und genau das will ich auf einer Radtour auch nicht - da will ich die Gegend genießen. Ach: Falls ich bei den Wegpunkten einen vergessen habe: OruxMaps meldet sich, wenn ich die Router mehr als 160m verlassen habe.

Wer jetzt sagt, man könne sich doch bei bestehender Route sehr gut von OSMand sprachlich navigieren lassen, der hat es wohl noch nicht getestet. Die App hört gar nicht auf zu labern. An entspanntes Radfahren ist so nicht mehr zu denken. Manchmal besser als nichts, aber überzeugt hat mich das nicht…

Wenn das Display eingeschaltet bleiben sollte, könnte man es nach 30sek immer automatisch auf eine geringere Helligkeitsstufe regeln. Ein Klick auf den Touchscreen müsste dann sofort für eine Erhöhung der Helligkeit sorgen. Das Gerät nach 30sek ganz abzuschalten ist in meinen Augen keine gute Lösung, weil man es häufig umständlich wieder einschalten muss (Schalter häufig oben oder an der Seite, nicht an der Front). Benutzt man das Handy in einer Handy-Radtasche mit durchsichtiger Folie (vor Wetter und ausreichend vor Stössen geschützt - auf meiner Sicht die einzige sinnvolle Transportlösung), bringt einem der Schalter an der Seite gar nichts - man kommt nicht dran. Ich nutze aktuelle in altes Handy mit Powerschalter an der Front, aber da es sehr lahm ist, ist es nur eine Verlegenheitslösung. Im Sommer nutze ich auch mal eine einfache Halterungen ohne Schutz, aber das mache ich immer ungern (Smartphone ist mir schon mal rausgefallen).

Wenn Deine finale App da eine Lösung hätte, wärst Du an der Killer-App nah dran ;).

…man kann aber auch in Osmand den Ton ausschalten und nach den Pfeilen fahren, also was direktes Routing betrifft dann ganz klar Osmand, da es die Gpx-Daten am besten auswertet und informiert. Dafür hat Locus und Orux andere Vorteile-ich mag sie alle drei und entscheide immer kurzfristig. Wenn ich Tracks auf zeichne verwende ich aber meist Locus, da es auch automatisch Sprachanweisungen gibt während dem gpx-routing. Wenn ich mit dem Rennrad auf Speed unterwegs bin,dann nehme ich Oruxmaps, da es bei der Aufnahme Infos in Sprachform gibt über Durchschnittsgeschwindigkeit etc. und das Dasboard klasse ins Display integriert ist.
Zurück zum Thema: Wenn ich Arndts Talent hätte, würde ich versuchen das ganze grafisch aufzuwerten und als Standalone neben Osmand,Orux,Locus laufen lassen. Es wird ungemein schwer an das Potenzial der drei Programme heran zu kommen,also lieber auf die wichtigen Sachen konzentrieren und vorhandenes optimieren und konsolidieren. Ich versuche auch in meinen eigenen Scripts|Makros möglichst modular und konzentriert auf Universalität zu programmieren. Ein gutes Interface mit dem streben nach wenigen Klicks und guter Überschaubarkeit.
LG Volker.

Also Osmand ist die zweitbeste Sprachführung, die ich kenne und nutze. Die beste ist meiner Meinung nach die des Oziexplorers unter Windows Mobile. GArmin ist nicht brauchbar und Locus zu unzuverlässig.

Bei Osmand hat man immer noch nicht gelöst, was Victor auf Englisch das Wenkelproblem nennt. Man fährt auf eine Kreuzung zu, und bekommt statt leicht rechts scharf rechts gesagt. Dies hat etwas mit unzureichenden OSM-Daten zu tun.

Brouter und Osmand sollten aber meiner Meinung eine Sache lösen. Wenn was schief geht, sind es nach Entwicklermeinung ganz gerne die unzureichenden OSM-Daten. Da es aber ähnliche Fehlersituationen sind, sollte man sich vielleicht Heuristiken einfallen lassen, um solche Fehlersituationen zu erkennen und mit ihnen umzugehen.

Z.B. highway berührt in der graphischen Darstellung den anderen highway, sind aber nicht verbunden. Ich würde mal behaupten, wenn es zwei highway=track sind, dann dürfte das de facto ein Fehler sein. highway=track highway=motorway sollten getrennt bleiben.

Heuristiken mögen nützlich sein, um problematischen Situationen (nahe aber nicht verbunden, Kreuzung ohne Verbindung, …) zu erkennen. Allerdings ist es ohne Ortskenntnisse (oder manchmal sehr guten Luftbildern) nicht entscheidbar, ob das nun real so ist oder ob ein Datenfehler vorliegt.

Da erwartest du zuviel von den Routern. Sie sollen ein Problem automatisiert lösen, was aus gutem Grund nicht automatisiert korrigiert wird.

Edbert (EvanE)

Gibt es irgendwo eine Doku zu den Profildateien?
Was heißt z.B.
assign downhillcost switch consider_elevation 60 0
assign downhillcutoff 1.5
assign uphillcost 0
assign uphillcutoff 1.5

Ich hätte eher vermutet, das uphill Kosten verursacht und nicht downhill. :sunglasses:

Chris

Hallo Chris

Es gibt durchaus Leute, die ungern steile Straßen abwärts fahren, da es ihnen dann zu schnell wird. Es soll sogar Leute geben, die in solchen Situationen lieber absteigen und das Fahrrad schieben.

Aufwärts empfinden solche Leute als sicherer, da die Geschwindigkeit sehr viel niedriger liegt.

Edbert (EvanE)

http://brensche.de/brouter/profile_developers_guide.txt

Was hoch geht muss auch wieder runter… Von daher ist es egal, was man zählt. Der Unterschied ist nur, dass man dararuf diese 1,5% Cutoff anwenden kann, also entweder flache Abstiege und/oder flache Aufstiege bevorzugen gegenüber steilen Strecken.

Dazu zähl ich mich nicht. Bei mir kann es downhill schonmal 3 stellig werden. :sunglasses:

Nun ja, es ist dein Leben.
Hoffentlich hast du hervorragende Bremsen.

@abrensch: Für eine einfache Strecke oder einen Rundkurs gilt deine Aussage
“Was hoch geht muss auch wieder runter”
nur begrenzt. Oder berücksichtigst du die Richtung der Route nicht?

Edbert (EvanE)

Man kann sowas ähnliches machen mit 2 nogo-Kreisen, zwischen denen der “via-around” als Durchgang frei bleibt.

Was mit via-Punkten ja ohnehin schwierig ist, ist dass man damit nicht dynamisch neu berechnen kann, weil man ja nie genau weiss, ob man einen via-Punkt jetzt noch beachten muss oder man ja “eigentlich” schon dran vorbei ist, ohne ihn wirklich erreicht zu haben. Nogo-Areas haben dieses Problem nicht, weshalb sie als Planungs-Hilfsmittel in Verbindung mit dynamischer Neuberechnung die bessere Wahl sind (DAfür bringen sie aber bei der Rechenzeit nicht den selben Gewinn wie via-Punkte)

Wenn ich sowas wie “via-around” implementieren würde, würde ich’s also wohl intern auch über einen Kostenaufschlag für die Nachbargebiete abbilden.

Wenn wir BRouter das erste Mal öffnen wollen, erhalten wir die Meldung “Enter SDCARD base dir: (no basedir configured previously) /mnt/sdcard” angezeigt. Sobald wir auf OK drücken erscheint danach jedesmal die Meldung “An Error occured: from-position not found! (coordinate-source: /mnt/sdcard/oruxmaps)” beim Start der App. OruxMaps ist auf dem Android installiert. Welcher Pfad müssen wir beim ersten Start angeben?

Die Fehlermeldung “from-position not found!” belegt eigentlich, dass mit dem Pfad alles in Ordnung ist (D.h. BRouter benutzt das selbe Basisverzeichnis wie Oruxmaps), es fehlen einfach nur die Wegpunkte “from” und “to”, die Du im Oruxmaps anlegen musst, um BRouter zu sagen, von wo nach wo er routen soll.

Da steht:

Download the file "brouter_0_8.zip" 

Ich finde die nicht. Ixh nehme an, Du meinst http://brensche.de/brouter/BRouter.apk

@abrensch: Vielen Dank für die schnelle Antwort. Nun erscheinte bei uns noch eine andere Meldung "An Error occured: The segments-directory /mnt/sdcard/brouter/segments2 contains no routing data files (*.rd5). see … Habe mir dann die readme.txt Datei mal genauer durchgelesen. Und siehe da. Wer lesen kann, ist klar im Vorteil. Wir mussten noch eine der *.rd5 Dateien extra herunterladen. Jetzt sollte alles supi funktionieren. Besten Dank.

Da redest Du jetzt jetzt aber von Fahrrad-Navigation? Ich glaub bei Auto-Navigation sind die Marktführer schon noch einen Schritt weiter.

Bei OsmAnd ist vieles noch nicht gelöst, nur in dem Fall kann es schlicht nichts mit unzureichenden OSM-Daten zu tun haben, weil OsmAnd an dieser Stelle die OSM-Daten überhaupt nicht nutzt, sondern ausschliesslich den berechneten Track verwendet.

Ich denke in der Tat, dass es genau hier den Preis zu gewinnen gibt. Wie schon gesagt, ich experimentiere zur Zeit mit der Integration in OsmAnd und beutzte dazu BRouter als Online-Dienst. Habe mir dazu OsmAnd so gepatched, dass es meinen Server kontaktiert statt den des konfigurierten Dienstes und einen gesonderten Dienst auf dem Server gestartet. Die automatischen Neuberechnungen sind schon ein echter Vorteil. Wenn ich das jetzt noch so hinkriege, dass es komplett offline läuft, langstreckenfähig und voll konfiguriertbar ist (=Profil + nogo-Areas), dann wäre das schon nicht schlecht, wenn da nicht diese grottenschlechten Sprachansagen wären.

Und da denk ich drüber nach, ob man nicht als ersten Schritt zur Integration zunächst mal den Neuberechnungstrigger und die Sprachausgaben in BRouter abbilden kann und damit erstmal die “Hemdentaschen-Navigation” brauchbar kann. Und ob man dann noch selbst eine offline-Karte rendert oder eine definierte Schnittstelle zu maptools baut, die das übernehmen, würde sich dann schon ergeben.

Wow! Das hört sich sehr vielversprechend an :).