Messages

So, user steps are:
1. Attempt Brouter navigation in Locus but get timeout.
2. Use Brouter app to do same calculation, using remote.brf profile and selecting a to point and a from point.
3. Now it will work in Locus so either import track, or recalculate.
Am I right? If so it's still not very user friendly.

I uploaded a new version with some (60%) Performance improvement, and with a new shortcut to simplify this workflow:
(not yet on play, only here: http://brouter.de/brouter/revisions.html )

After a timeout, if you start brouter-app (within 5 minutes) you see "<repeat timeout>" in the profile list, and this way you can redo the timed-out calculation and update the reference track without any further click.

More user friendly?

BTW, seems that in the current Locus version, the display of timeout-messages (or any other error-messages) is broken.

Ich denke, es kommt auf die Anzahl der Möglichkeiten (Kreuzungen) an, die auf Deiner Strecke liegen. Irgendwann schlägt dann das timeout zu. Welchen Fehler bekommst Du genau? screenshot?

Fehlermeldungen sind so ne Sache, weil Menion in der neuesten Locus Version die Anzeige der Fehlermeldungen zerschossen hat...

Ich hab' eine neue Version hochgeladen (1.4.4, noch nicht bei google, nur hier: http://brouter.de/brouter/revisions.html ) mit etwas (+60%) Performance-Verbesserung und mit einem neuen Shortcut, um nach Timeout leichter die Berechnung zu vollenden und so eine Timeout-freie Berechnung aus Locus vorzubereiten.

Die neue Version, mit einem neueren Gerät (ARM Cortext A53 Prozessor) sollte auch in dicht gemappten Regionen die 100km ohne Timeout voll kriegen. Mit den KFZ-Profilen auch mehr.

Und wenn doch timeout, dann ist's mit dem neuen Shortcut ja auch nicht so schlimm.

I think one BRouter feature would have to be addressed - Timeout free route precalculation in BRouter server mode.
It serves to prevent 60s routing timeout for the Locus 1st time route calculation or route recalculation with ( distant ) point priority.

Hi,

Both features do work in that constallation. And by the way, that was my main development effort when I implemented the remote-profile option for brouter 1.4.3

Every request with a remote profile saves that profile on the brouter-side as brouter/profiles2/remote.brf

So after a timeout, you can repeat that long-distance calculation using the brouter-app, using the exact same destination point and a close-by starting point. That will automatically store the "reference-track" as brouter/modes/remote_rawtrack.dat, and with the help of that file the next try from Locus is guaranteed not to time out. Same for automatic recalulations (using endpoint priority). Recalculations should always be faster than the initial ones.

@Arndt: What about modifying the profile syntax like

assign  avoid_toll  [%avoid_toll%] 0   # profile for both, [] means optional

Nice try, but this ball goes back to Menion :-) When using a comment syntax instead, compatibility is not broken, so I don't have to repair. I would go one step further and define a comment-syntax that also provides the label-text and the label description text, and that also allows profile-defined parameters (currently, only build-in parameters work). Like that:

assign  avoid_toll  = false   # %config-option% Toll roads | Allows toll roads

regards, Arndt

- I read about no single problem till now, that car-fast, car-slow ... etc. cause problems to anybody.

I can help you remember :-)

http://forum.locusmap.eu/index.php?topic=5066.msg42633#msg42633

So this system as is, is usable and logical for users.

The system, as it is used, is not logical. In my mapping I mapped "moped" -> "car slow". A moped is not a car, so this is not logical, it's just a workaround. When zossebart maps 5 biking-profiles on the 5 transport modes and has a hard time to remember what "car slow" actually is, then there's also a usability problem.

What comes now is a complication - "profiles". You care about "average users". I care currently more about less then average users. They don't care about profiles. I expect, they will use all settings as is, no need to modify it.

I do not agree. The complication is the fact that there are two "namespaces" with a mapping between them. If there's only one namespace, whether you call it a mode or a profile is just wording. A user seeing a combobox with items like "car" "moped" "roadbike" "velomobil" "bike" "hike" will be less confused than a user that has to learn that a moped is a slow car.

- anyway good point is with extra parameters. As I think about it, agree they should be shared and agree they needs to be visible easily directly during creating navigation definition (start/stop).

Think about consistency. As poutnik pointed out, it's quite arbitrary where you put the "cut" between having distinct profiles or controlling behavior via parameters (and in current beta there are far too many profiles, because most differnces would be better implemented by parameters).

There's no good reason to treat these two ways of configuring the router on different levels of visibility/reachability. So if I convinced you to put the parameters directly on the Navigation Screen, I will also convice you to put the profile name there. Then you have a layout problem because of the extra space that needs, and convice yourself that you need to remove the transport mode buttons :-)

Locus v3.18.6.2+: Huch, da sind ja jetzt viele Profile auswählbar! Muss ich die Tage testen. Wo sind die denn gespeichert? In Locus integriert?

Ja, die sind wohl nicht im Dateinsystem zugänglich. Aber wenn du welche unter Locus/data/brouter hinzufügst, sind die auch dabei. Aber ob man da dann auch Optionen definieren kann, weiss ich nicht.

Ünbrigens ist das zuletzt "gesendete" Profil dann auch auf Seiten BRouter im "profiles2" Ordner als "remote.brf" sichtbar.

Da sieht man dann auch, dass es sich um "Poutnik"s Profile handelt. Da ist noch einiges im Argen, weil Poutnik ja ein "Template-Konzept" hat, um aus einem  Template Profile verschiedene Parametrisierungen zu machen, und Menion hat jetzt ein neues Parametrisierungs-Konzept mit den Optionen - für genau das selbe Problem. Das muss noch aufgeräumt werden.

Aber bzgl. dieser verrückten Idee, das "transport.mode-mapping" in BRouter dadurch abzuschaffen, dass man in Locus ein transport.mode-mapping implementiert, hab ich aben schon im (englischen) "versions" Forum einen Kommentar geschrieben...

... first attempt to custom configuration for BRouter profiles directly over Locus.
Locus will now display also profiles stored in Locus/data/brouter (for those who wants to play with it). Such profiles also support "on the fly" definition of "avoid_motorways" and "avoid_toll" parameters. Check sample attached file if interested. Hope you find it useful.

Thanks, and works for me as intended.

However, I think that needs a second thought.

The issue was that the transport-mode mapping in BRouter is too abstract for the average user, and you need something more intuitive. And now you come up with ....... a transport mode mapping....

So everytime the word "transport mode" comes to your mind, just say 3 times:

  "There's nothing like a transport mode - there are just profiles with options"

  "There's nothing like a transport mode - there are just profiles with options"

  "There's nothing like a transport mode - there are just profiles with options"

I know that for MapQuest you have a similar concept: the options (there are 4 options for MapQuest) are configured deep in the configuration, and the transport mode is selected on the navigation screen. This is already dangerous: it's easy to forget such an option, and you will be confused by unexptected results.

But now, things are even worse: while for Mapquest, you have one set of options, now you have a set of options for each transort mode. That's a multiplication of entropy and the way to hell.

So the concept that I have in mind is much simpler: put the profile-selection AND the options directly on the navigation screen.Maybe two lines, the first with a combobox for profile selection + a trigger button, and the second line with checkbox icons for the options. And have the values for the checkboxes shared over profiles, that is, if you change the profile selection, the options keep their values, but the visibilty of the option icons depends on whether the selected profile evaluates that option. Of course that does not offer space for the (multi-language?) option descriptons, so they must be places somewhere else.

I am aware that you need a transport mode also to initialize the voice navigation. But you can take that from the gpx-response, the same way you do it when importing a gpx.

regards, Arndt

Ausgangspunkt war hier 51.817556, 10.438778

Was hat denn die Meldung die ich erhalten habe speziell zu bedeuten ?

Es ist eine "Insel". Eine Insel am Startpunkt äussert sich durch "no track found at pass 0 ", eine am Zielpunkt heisst "target island detected". Ich weiss, ich sollte eigentlich in beiden Fällen die Insel beim Namen nennen...

Die Insel entstaeht dadurch, dass die Wege innerhalb des Campingplatzes als öffentlich zugänglich gemappt sind, der Zugangspunkt aber mit "barrier=lift:gate access=private".

Mit solchen Inseln kommt BRouter nicht klar.

Falls ich den Kommentar in der Eile richtig verstanden habe, wird es erst einmal mit einer der nächsten beta-Versionen eine Änderung geben. Erfahrungsgemäß dauert es ca.(!) 4-6 Wochen bis zum nächsten PRO update.

Was muss ich denn jetzt machen?

Und was ist eigentlich genau das Problem.

Hauptproblem scheint zu sein, dass es eine Regression gibt ("Navigation funktioniert nicht mehr"), wenn nach einem BRouter Update nicht auch die Profile ge-updated werden. Den Hinweis kann man noch so fett schreiben - lesen tut das eh keiner.

Hab' hier 2 Möglichkeiten: entweder ich baue ein besseres Konfigurations-Management, also z.B. automatische Ersetzung von Profilen, die nicht geändert wurden.

Oder, ganz böse, aber im Moment wohl die einfachste Lösung, ich "fälsche" die BRouter Version im GPX-Output, so dass da wieder 1.3.2 steht, wenn keine Sprachhinweise enthalten sind.

Zweites Problem scheint wohl (immer noch?) zu sein, dass auf Guidance geschaltet wird, wenn wegen trivialität keine Hinweise enthalten sind. Wenn ich Menion richtig verstehe, kann ich selbst die "Zielfahne" zu den Hinweisen dazuschreiben (woraufhin er das dann nicht mehr tut), und dann hab' ich immer einen Hinweis und alles ist gut?

Drittes Problem scheint zu sein, dass ich das shortest-profil nicht angepasst habe. Kann ich die Version von erfi übernehmen.

Hab' ausserdem noch einen krassen Fehler im  weg-punkt-datenbank-Adapter für Locus (und Oruxmaps) gefunden, der dazu führte, dass alle Latitude-Werte mit Rundungsfehlern von bis zu 5 Metern geelesen wurden. Das führt dazu, dass ein wichtiges Feauture von brouter, die Vorberechnung von Langstrecken, um sie anschliessend über die dienste-schnittstelle abzufahren, mit locus und oruxmaps einfach noch nie funlktioniert hat. Weil die Prüfung, ob der Zielpunkt derselbe ist, nur eine Abweichung von 2m erlaubt... Allein das ist schon ein Grund für die Version 1.4.3...

Irgendwie bin ich jetzt selbst bei Locus hängengeblieben, wo ich doch jahrelang OsmAnd benutzt hatte, aber nach bisschen Training bin ich jetzt mit der brouter/locus Kombo ganz glücklich. Mit folgender Konfig: weg-Abweichung Alarm = 50m, Neuberechnung ab 100m, Neuberehnung Zielpunkt-Orientiert. Maan bekommt ziemlichen Sprachsalat, wenn man das anders macht...

Danke für Euren Feedback hier. Hab' gerade nicht soviel Zeit, aber werde die Version 1.4.3 bald machen

Oder ist es uninteressant, welche Brouter- Version installiert ist???
Im Moment bin ich wieder zur BRouter v1.3.2 zurück gekehrt.
Danke für eine kurze Info

Locus 3.17 schaut auf die BRouter-Version und erwartet ab 1.4.1 von dort die Hinweise - und wenn da dann keine sind - weiss nicht, wie es sich dann verhält.

Wenn in den  BRouter-Profilen nichts zu Sprachhinweisen steht, dann macht er auch keine. Kann es sein, dass Du entweder:

- die Profile doch nicht ersetzt hast
- oder das "shortest" (=foot) Profil verwendest, was ich noch nicht angpasst hatte?

Ich sollte das   shortest-profil noch anpassen.

Und Menion überreden, statt der BRouter-Versions-Prüfung eine Prüfung auf die Existenz der Locus-Extensions zu verwenden...

Deinen U-turn kann ich mir aber nicht erklären...

Der Fangradius fängt nicht nur andere Anweisungspunkte ein, sondern auch Drehwinkel ohne Kreuzung, und das in beide Richtungen, und wenn Du von diesem u-turn 40m vor und zurück gehst hast Du grob 180 Grad.

Die Erwartungen sind hier sehr unterschiedlich. Die einen erwarten Blind-Person oder Hemdentaschen-Navigation (das wird's sicher nicht), die anderen möglichst wenig Trigger, hauptsache keinen wesentlichen verpassen.

Mein Gefühl ist, dass es ziemlich egal ist, womit ein Trigger beschriftet ist, hauptsache, man bekommt ihn, und man bekommt nur die nicht-trivialen. Aber ich hab' in 1.4.2 einen Patch von Volker übernommen, der die Anweisungen eindeutiger machen soll. Beispiel: Regulär wärs "rechts abbiegen", aber rechts gibt's zwei wege, und davon der linke ist der richtige, also wird's "leicht rechts". Das geht in Richtung Hemdentasche, aber ich glaube wie gesagt nicht, dass es ohne den Blick auf's Display gehen wird.

Ich plane eine kurze Test Strecke "Foot"  ... [nur] mit einem zusätzlichen Zwischenschritt bei der Erstellung wird die erwartete Strecke (pink) mit 2,6 KM berechnet. was mach ich falsch?

Jungs,

das wichtigste, das ich hier mitgenommen habe ist, dass das Mode-Mapping ( also die Abbildung z.B. "Foot" -> "shortest") abstrakt, komplex und fehleranfällig ist, und das deswegen unter anderem Menion es möglichst bald abschaffen wollen.

Wenn ich hier solche Fehlerbeschreibungen lese muss ich einfach zuerst vermuten, das das der "Fehler" ist, denn das beschriebene Verhalten ist exakt das, was "fastbike" macht, und hier steht einfach nicht dabei, welches Profil denn unter "Foot" gemappt ist.

Um Routing-Fehler zu untersuchen und rauszufinden, ob es sich um ein Problem in der Karte, im Routing-Profil oder vielleicht doch in der Routing-Software handelt, eignet sich BRouter-Web wunderbar.

Aber Joachim's (ursprüngliches..) Problem ist ja wohl tatsächlich ein algorithmisches, und ich glaub, ich hab's auch verstanden:

Es ist tatsächlich so, dass Locus-Beta immer dann seine eigenen Instructions einbaut, wenn BRouter keine erzeugt hat, auch dann, wenn die Strecke einfach so kurz war, dass da einfach keine hingehören. Und das gilt im Locus-Route-Planner pro Segment, ist also, wenn man da mit vielen Zwischenpunkten plant, ganz klar lästig und ein Fehler.

Im Routenerstellungsmodus in Locus habe ich "Route berechnen" gewählt, Profil Fahrrad schnell oder Fahrrad Kurz und hab einen Haken bei "Berechne Anweisungen" gesetzt. Funktioniert nicht, macht sehr viele Anweisungen bei jedem Knick im Weg.

Hab' dann auch mal kapiert, wie man an die Beta-Version kommt, und bei mir funktioniert das auch, sowohl im Routen-Erstellungsmodus als auch bei der direkten Navigation zu einem Zielpunkt.

( Beta-Test steht hier: http://forum.locusmap.eu/index.php?topic=3879.0 )

Hab' allerdings auch gemerkt, das dieses Testverfahren, mit der Beta-Version als Locus-Free, die zwar viele Daten, aber nur einen Teil der Konfiguration mit der Pro-Version teilt, fehleranfällig ist, weil man leicht die falsche Software verwendet (pro statt free) oder leicht vergisst, Konfigurationen nachzuholen, wie zum Beispiel die Routing-Quelle (da ist Yours die Voreinstellung, nicht BRouter).

Hab' dann zum Beispiel auch gemerkt, dass Locus doppelte Ansagen kann ("rechts abbliegen, dann links halten") und weiss jetzt auch nicht, ob das ein neues Feature ist oder ich es in der Pro-Version einfach nur weg-konfiguriert hatte. Ist halt einfach doch komplex alles...

Was mache ich falsch?

Bist Du sicher, dass Du die Profile aktualisiert hast? Am einfachsten machst Du das, indem Du den "profiles2" Ordener löschst. Der wird dann automatisch mit dem Inhalt aus dem APK neu angelegt. Aber drüberschreiben aus dem ZIP müsste ja auch getan haben.

Ich glaube, ich werde das für das Google-Play Release noch bisschen aggresiver machen, so dass zumindest Profile, die nie geändert wurden, automatisch überschrieben werden.

Sind die Abbiegehinweise denn drin, wenn Du ein GPX über die BRouter-App erzeugst?

Das mit den separaten Wegpunkten in Locus, wenn man eine solche Datei importiert, liegt an dem Haken "Punkte mit Track zusammenführen". Der muss gesetzt sein.

Kömnte jemand aus der Beta-Test-Gruppe mal testen, ob die Überahme der Sprachhinweise beim direkten Aufruf von BRouter in der aktuellen Beta funktioniert ? Danke !

I have one more questions for You if possible. Can you imagine, that request over AIDL should contains also a name of file with "profile"? Because I can imagine UI selection of profile directly in Locus.

Sure no problem. But 2 API Extension would be two-fold:

- request to get all availabe profiles
- parameter to select profile by name

I would not favor an API that sends net data of profile directly (or absolute path to it somewhere on sd-card), because the tight coupling between brouter software and profile would raise compatibilty issues.

However, if you want that for the next release you would have to give me 3 days...

ragards, Arndt