Messages

Aber wenn ich mir vorstelle, ich soll meiner Freundin, die schon durchaus technisches Verständnis hat, den BRouter erklären, da sträubt die sich, das wird ihr zu technisch.

Ich bekam vor ca einem Jahr eine Mail aus Ungarn, und er schrieb, er habe OsmAnd so gepatched, dass es das CGI auf meinem direkt Server aufruft, damit voll integriert ist und auch die automatischen Neuberechnungen funktionieren,  weil so könne er es auch seiner Freundin erklären. Zu der Zeit gab es nur die Datei-Schnittetelle mit den from/to Wegpunkten. Das hatte ich verstanden und daraufhin die Integration vorangetrieben und jetzt sind wir viel weiter, BRouter ist voll integriert, trotzdem völlig offline und zumindest die ungarischen Freundinnen haben überhaupt nichts mehr zu meckern.

Und so ist die Situation zumindest bei OsmAnd: einmal installiert und konfiguriert ist BRouter überhaupt nicht mehr zu sehen. Die Wegpunkte-Schnittstelle kennen die Leute garnicht mehr. Was natürlich auch wieder ein Problem ist: In OsmAnd funktionieren dessen Zwischenpunkte zusammen mit BRouter nicht. Was mich überhaupt nicht stört, denn ich bastele mir meine Routen grundsätzlich mit Sperrzonen zusammen. Dafür muss man aber wiederum die Datei-Schnittstelle verstehen, und da wird's dann wieder dünn..

Das ist ein Produkt für Nerds und Freaks, denen das Schrauben selbst auch schon Spaß macht.

Na ja, ich glaub den Teil der Menschheit, der den Unterschied zwischen Online- und Offline versteht (und das ist nicht der grössere..) dem kann man das auch plausibel machen. Die anderen sollen doch Google-Maps und Komoot mit was auch immer füttern.

Du bekommst doch genug feedback.
Anhand der gerade mal 29 Bewertungen auf GooglePlay kann ich nicht viel heraus lesen und in den anderen App Foren lese ich nicht mit.
Sind denn speziell Locus-User nicht in der Lage zu lesen bzw. zu verstehen oder ist dies auch bei Benutzern von Orucks bzw. Osmad so? Liegt es etwa an Locus selbst?

Hi Gynta,

ich seh' das nicht so negativ. Bei 3300 Downloads und 1300 "aktuellen Installationen" plus paar Hundert Installationen aus dem APK sind 20-30 Supportanfragen, die ich gesehen habe, nicht viel, und einige davon ja auch zu echten Fehlern wie dem Android 4.4 Problem oder der fehlenden Berücksichtigung von Zwischenpunkten in OsmAnd.

Es gibt halt einfach so paar wenige, die mit einer seltsamen Erwartungshaltung und ohne den Willen oder die Fähigkeit, sich irgendwo reinzudenken, auftreten und mir 1-Sterne Reviews in Google Play schreiben. Schau Dir mal die Play-Bewertungen auf englisch an (Handy oder Forefox auf Englisch umstellen).

Oruxmaps spielt sich glaubich viel in Spanien und Italien ab und die supporten sich selbst. OsmAnd ist tatsächle für den EInstieg einfacher, sich mit dem Unterschied zwischen Navigation und Guiding auseinanderzusetzen gibt's da nicht, da gibts nur "Navigiere zu".

Auffällig ist, dass Locus Benutzer immer überzeugte Nutzer sind, während das bei OsmAnd eher so die "geht schon,reicht erstmal" Haltung ist. Wird wohl immer so sein, dass eine mächtigere Software auch mehr EInarbeitung kostet.

Gerade darüber gestolpert und evtl möchte ja jemand den Artikel von Stefan Kuhn auf com-magazin.de lesen ->

http://www.com-magazin.de/praxis/android/offline-routing-rad-wandertouren-465807.html

ich finde das gut, wenn Journalisten sich dem Thema annehmen, weil es ja doch mehr Breitenwirkung hat als Forenartikel und weil sie auch präziser schreiben können. Und ging ja auch ein Beitrag allgemeiner über Locus und OpenAndromaps vorraus. Aber die Hoffnung, dass Jounalisten die Dokumenation übernehmen können ist natürlich trügerrisch. In dieser Präzision, wie er die Installtion beschreibt auch noch das Mode-Mapping, die Sperrzonen, die Timeoutfreien Neuberechnungen etc, so eine Doku fehlt noch.

Was mir auch gerade mal wieder auffällt ist, dass Wanderrouten doch einen erheblichen Teil des Interesses an BRouter ausmachen, aber noch nie irgendjemand ein ernsthaftes Wanderprofil veröffentlicht hat. Da sollte man auch mal was machen...
 

Ich benutze intensiv Locus Pro um mich offline in schwierigem Gelände zu orientieren und zu geocachen. Hier auf den Kanaren gibt es viele Bereiche die nicht mit Mobilfunk abgedeckt sind.

Da ich gerne nur ein Programm für Alles verwenden möchte habe ich mich mit Brouter beschäftigt. Noch überzeugt er mich nicht wirklich.

Perfekt funktioniert das Offline Navigationsprogramm Osmand. Die Navigation per Auto, Bike und Trekking funktioniert gut.
Da ist Brouter leider noch keine Alternative. Es wäre schön wenn es anders wäre

Das geht aber schon arg durcheinander. Das eine ist die Gesamt-Integration als Navigations-Lösung, und da hat OsmAnd schon was für sich. Das andere sind die Routing-Resultate, und da ist das beim Bike-Routing bestenfalls so lala. Die Leute, die das machen, fahren einfach kein Fahhrad. Höhenbewusstsein, Sperrzonen, die Korrektheit der Acces-Rules, die Falle durch Fähren, die nicht fahren: vergiss es. Weiter als zum Bäcker kommst Du damit nicht. Deswegen sollte sich die Erkenntnis durchsetzen, dass die Navigations-Lösung und die Routing-Lösung zwei getrennte Paar Schuhe sind. Und Du kannst auch BRouter mit OsmAnd verwenden, zumindest zum Fahhrad-Fahren. Zum Autofahren fehlt da noch bisschen was, insbesondere die Voice-Hints und die Fahrtzeiten. Du guckst dann halt auf eine komisch gerenderte Karte mit blauen Autobahnen, und ein Höhendiagramm kriegst Du nicht zu sehen. Also nimm doch lieber Locus..

Version 0.9.9 finde ich dort. Im Google Play Markt finde ich 1.0 was ist tatsächlich neuer?

Die Play-Version hat schon alle Erweiterungen der 0.9.9, meldet sich aber noch mit 0.9.8, da hab' ich bisschen geschludert. Die "1.0" hat Google vergeben, das kommt nicht von mir.

Play-Version und APK aus dem Distribution Zip unterscheiden sich aber auch darin, dass letztere den Download-Manager nicht enthält und keine Internet-Berechtigung anfordert.

Hi und Danke für das Feedback zu dem "Plug&Pray" Setup aus dem Play-Store.

es war ein hartes Stück Arbeit für mich, wo ich mich mit UI Design nicht wirklich auskenne, aber an der Stelle ist es gelungen und keiner bleibt wirklich hängen (bis auf den Durschnitts-Ami aus dem mittleren Westen - gibt's nicht eine Weltekarte mit US-Bundestaaten?).

Speedlimit werde ich ändern, wollte einerseits meinen Server schützen wenn wirklich mal tausende Downloads kommen sollten (aber noch sind's ja erst 300), andererseits die UMTS-Anwender schützen, dass sie sich nicht aus versehen ihr Daten-Kontigent leersaugen.

Mir ist natürlich klar, dass man das noch deutlich DAU-fester hinkriegt (aber sind die Kartenprogramme das denn auch?) und dass man die Dokumentation noch besser machen kann. Aber ich bin halt ein Hobby-Bastler und kein Weltkonzern. Deshalb hör ich sehr genau hin bei Showstoppern, die auch denen das Leben schwer machen, die die 4000 Zeichen Google-Play Description bis zu Ende gelesen haben, aber bleib gelassen bei  Problemen von lese-unwilligen.

Noch zu den Fragen/Anmerkungen:

Ich habe jetzt mal ein bisschen mit der Streckenberechnung rumgespielt.
Längere Strecken erreichen tatsächlich das Timeout und die Berechnung bricht ab. Dies lässt sich natürlich problemlos umgehen, indem man die Berechnung in kürzere Teiletappen aufteilt.

Richtig Problemlos ist das nicht, weil man in der Regel eine bessere Strecke findet, wenn man sie komplett rechnet anstatt in zwei Hälften, denn man sucht ja eine grössere Fläche ab nach den guten Gelegenheiten. Aber man kann sie ja rechnen über die App. Die hat keinen Timeout, weil man sie ja abbrechen kann. Der Dienst muss einen Timeout haben, weil sonst könnte man ihn durch eine falsche Anfrage dauerhaft blockieren. Man kann Langstrecken übrigens auch über die App vorberechnen und dann über die Diensteschnittstelle "partiell" neu rechnen.

@Abrensch: kann es sein, dass Fahrrad schnell und kurz immer die gleiche Route berechnen? Ich habe mal mehrere Strecken berechnen lassen und die waren immer identisch (auch in Städten mit vielen Straßen, wo es durchaus einen Unterschied zwischen schnell und kurz geben sollte). Oder muss ich hier noch eine Änderung an den Profileinstellungen vornehmen?

Wahrscheinlich hast Du die schon vorgenommen, wenn man den "Server-Mode" Butten werden immer beide Modi vorgeschlagen, und wenn man das so übernimmt, hat man beide gleich konfiguriert. Einfach nochmal über den "Server-Mode" Button gehen, alle Modi abwählen, dann siehst Du die aktuelle Konfiguration.

... und benenne mal folgende "Baustellen":
- Brouter-App via Play-Store installierbar
- 6 vordefinierte (und gut getestete) Standard-Profile für Auto, Fahrrad und Zu Fuß: jeweils Schnell+Kurz
- Laden der rd5-Routingdaten über die App (grafisch unterstützt)
- übersichtliche Anzeige aller getroffenen Einstellungen
- Optional: die Möglichkeit Routingprofile im Smartphone zu editieren

Anders ausgedrückt: Nach der Installation und (benutzerfreundlichen) Konfiguration der Brouter-App, kann der Locus-Nutzer die Offline-Routing-Möglichkeiten sofort und problemlos nutzen.

Hab' jetzt BRouter in Google-Play plaziert und bin diesem Wunschzettel ein gutes Stück näher gekommen. D.h. es gib einen graphisch unterstützten Download-Manager und ein vorkonfiguriertes Mode-Mapping. Dokumentation und übersichtliche Darstellung der aktiven Konfiguration haben aber noch Potential für Verbesserungen..

Gruss, Arndt

Es schein auch abhängig von der Entfernung zu sein.
Westerland (Sylt) --> Reit im Winkel geht nicht.
Kiel --> Reit im Winkel geht.

Wenn Du mit "geht nicht" OutOfMemory meinst ist das o.k., irgendwo ist halt einfach ende. Es hängt nicht nur von der Entfernung ab, sondern vor allem vom durschnittlichen Kostenfaktor. Zwei Punkte, die durch eine gerade Linie mit Kostenfaktor=1 (also Autobahn bei car-test.brf) verbunden sind sind einfacher zu routen als so eine Geschichte mit Sylt, wo man erst mal einen grossen Bogen nach Norden und die Syltfähre (+10km Strafe für Fähren!) braucht.

Solche sporadischen Fehler, wie sie franc berichtet machen mir mehr Sorgen, nur wenn es wirklich sporadisch ist (also nicht reproduzierbar) muss man immer auch die Speicherkarte im Verdacht haben. Ich werde mal in der nächsten Version eine Prüfsumme ergänzen, um sowas detektieren zu können.

Ich bin auch verwundert, dass es zunächst in der Animation so ausieht, als wäre die Strecke schon berechnet. Aberdann fängt der BRouter quasi von vorne an und bildet erst mal einen "Arbeitskreis" in der Animation rund um den Startpunkt. Jettzt kommt es wohl darauf an, ob das Ziel innerhalb von 600? Sekunden gefunden, bzw. erreicht wird.

Das ist hier bisschen beschrieben: http://www.brensche.de/brouter/algorithm.html

Die Punkte, die dargestellt werden sind das "open set", also die Endpunkte der pfade, an denen noch gerechnet wird. Der erste Durchlauf dient dazu, eine obere Kostenschätzung zu ermitteln, liefert aber nicht das optimale Ergebnis.

Man kann tatsächlich den zweiten Durchlauf abschalten und sich das Ergebnis des ersten Durchlaufs geben lassen:

assign pass2coefficient -1

aber das ist natürlich Unsinn (aber es ist genau der Unsinn, den sie bei OsmAnd machen und das dann "non-precise routing" nennen!)

1. Strecke von ganz Süden Deutschlands bis ganz im Norden definiert (in locus from, to)
..
6. nach über einer Minute kommt dann die Fehlermeldung:

Nee sollte schon funktionieren, auf meinem LG-E440 München->Flensburg in 25 Minuten. Aber "normale" Langstrecken sind für mich sowas wir Frankfurt-Berlin oder Frankfurt-Paris, und das geht in 2-3 Minuten.

Aber nicht innerhalb des 60-Sekunden Timeouts in der Service-Schnittstelle, aber für den Zweck gibt es die "Timeout-Freien-Neuberechnungen" : wenn man eine Langstrecke in der BRouter-App berechnet hat und anschliessend über "Server-Mode" die Konfig speichert, funktioniert eine anschliessende Berechnung über die Service-Schnittstelle mit einem Ergebnis nach höchstens 60 Sekunden.

Was genau bei Dir da den Fehler erzeugt hab' ich bisher keine Idee. Wenn das mit der aktuellen Version (0.98) passiert, dann hätte ich gern mal den Testfall (also die start-ziel Koordinaten)

Gruss, Arndt

Wohin damit, müssen die [car-subset cd5-Dateien] auch ins segments Verzeichnis ?
Ich finde das gar nicht in der ReadMe Datei.

Es steht in einer eigenen Readme-Datei. Die war bisher nur in dem
Distribution-ZIP enthalten. Aber seit ich die BRouter-Quellen auf
GitHub habe, kann man sie auch da nachlesen:

https://github.com/abrensch/brouter/tree/master/misc/readmes

Gruss, Arndt

Ältere Dateien berücksichtigen halt nicht den aktuellen Kartenstand aber sind kompatibel, kann man also weiterverwenden.
Wenn ich sie komplett aktualisiere mach ich das am PC mit dem Firefox Plugin "Down them all".

Verlassen würde ich mich nicht darauf, dass man über unterschiedlich alte Routingfiles zuverlässig routen kann, die Fehlermeldung aus Reply#40 sieht so verdächtig nach der Sorte Fehler aus, die daraus entstehen könnten.

Übrigens gibt's seit der Version 0.95 ergänzend zu den rd5-Dateien ergänzend (oder auch alternativ) auch die "carsubset" Dateien (cd5), die etwa nochmal halb so gross sind und ohne die das car-routing über längere Strecken nicht funktioniert.
Und ab Version 0.98 wird man auch darauf hingewiesen, wenn man wegen fehlender carsubset-files beim Car-Routing einen OutOfMemory Fehler bekommt.

Den DACH-Download würde ich zumindest nach Norden erweitern, weil sonst fehlt genau der Sylter Norden, und die Dateien da oben ( > 55 Grad) sind ja nicht wirklich gross.

Gruss, Arndt

Wie auch immer: Aktuell ist die Einbindung und Benutzung für den "normalen" User viel zu Umständlich.

Das sehe ich ähnlich und benenne mal folgende "Baustellen":
- Brouter-App via Play-Store installierbar
- 6 vordefinierte (und gut getestete) Standard-Profile für Auto, Fahrrad und Zu Fuß: jeweils Schnell+Kurz
- Laden der rd5-Routingdaten über die App (grafisch unterstützt)
- übersichtliche Anzeige aller getroffenen Einstellungen
- Optional: die Möglichkeit Routingprofile im Smartphone zu editieren

Anders ausgedrückt: Nach der Installation und (benutzerfreundlichen) Konfiguration der Brouter-App, kann der Locus-Nutzer die Offline-Routing-Möglichkeiten sofort und problemlos nutzen.

Ich sehe es auch so, dass das nur zusammen geht, also Google-Play als Deployment-Kanal und eine idiotensichere Installation. Ich denke, es müsste einfach eine komplett andere App sein, die eben nur genau das kann, aber das idiotensicher: Install -> SD-Card-Directory aus einer Vorschlagsliste auswählen, ein Stadt auswählen und einen Umkreis der mit Routing-Daten abgedeckt werden soll und anschliessend steht der Service mit einem Standard-Mapping zur Verfügung. Und noch eine Wiederaufsetz-Fähigkeit bei Download-Abbrüchen.

Wer aber die vollen Möglichkeiten nutzen will (also Langstrecken berechnen mit grafischer Animation, Alternativen berechnen, Sperrpunkte setzen, die service-modes ändern etc) der muss diese App wieder löschen und die "richtige" installieren. Und dann ist man auch die Berechtigung für den Internet-Zugriff wieder los, weil es ist ja schliesslich eine offline-app.

Wäre das ein Weg? Weil der Mercedes mit tausend Konfigurationsmenüs und einem syntaktisch unterstützten Profile-Editor, das kann ich nicht leisten.

Gruss, Arndt

However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalculations if you follow the route and get off the track.

Today I deployed version 0.95 of BRouter ( see http://brensche.de/brouter/revisions.html ) which contains basically this mechanism.

I also did some "hard-work" to improve the basic performance, but this is less than a factor of 2. And I supplied "car-subset" datafiles that allows somewhat longer distances for car-routing.

But the major improvement is this recalculation stuff. I do not anymore call it "fast-partial-recalculation", now I call it "timeout-free recalculations": if you already have calculated a valid track for the same destination and the same routing mode (via the brouter-app or the service-interface), then the next calculation via the service interface for that destination will almost never give a timeout, but, if it does not succeed to finish the full calculation, give you a merged track from the old valid track and the new, partial calculation.

There's no change in the user interface. Just be aware that, when pressing the "Server-Mode" button after you calculated a track using the brouter-app, you do not only store the profile and the nogo-list for use by the service-interface, but also the track itself to be re-used by the service-interface.

Not sure if somebody reported already that 60000 ms (1s) are a too short timeout for brouter.
Just tried with a route from Frankfurt to Praha -> Locus timeout ...

Maybe you could make it a something like: timeout = (geo distance) * (configurable factor)

The timeout is important to protect the device. 60 seconds is the default, but there's a parameter in the aidl-interface, so it can be changed from outside.

However, the long-distance solution I am working on is "fast-partial-recalculation": the idea is that if a route to the same destination-point and for the same routing-profile is already known, a partial recalculation is done and the result is a combination of the old and the new calculation. This way you can do a long-distance calculation by starting the brouter-app, but then have fast recalulations if you follow the route and get off the track.