Navigation-Instructions in GPX-Format (BRouter-Interface) ?

[abrensch]

Hi Menion,

I'm working on providing map-based voice-hints from BRouter in order to have a more precice voice-guiding.

My understanding is that I can simply carry them along with the GPX, either imported explicitly into Locus or requested via BRouter's aidl-interface. Howver, I failed to get any vital sign from Locus actually using my hints.

I tried the simple syntax with the <wpt>-Tag:

<wpt lon="8.615649" lat="49.695896">
  <name>right</name>
  <sym>Right</sym>
  <type>Right</type>
</wpt>

as well as a version with locus specific extensios ( <extensions><locus:rtePointAction> ...), but with no success.

Any hint what I have to write into the GPX in order to hear my own voice-hints while navigating with Locus?

thanx in advance, Arndt

[Menion]

Good day Arndt,

I think that best option is to create really simple track in Locus with some navigation commands and then export it into GPX file. You may then check difference compare to you own solution. Anyway solution with <extension> should work after import in all cases. Also you may attach any file that do not work here and I'll tell you where is a problem.

[abrensch]

Anyway solution with <extension> should work after import in all cases.

Thanks Menion,

now it works for me when I manually import the GPX Track. The waypoints look like:

  <wpt lon="8.608944" lat="49.674370">
     <name>right</name>
     <extensions>
        <locus:rteDistance>292.0</locus:rteDistance>
        <locus:rtePointAction>7</locus:rtePointAction>
     </extensions>
  </wpt>

Everything fine, I am hearing MY waypóints in MY lamnguage - perfect.

However, it does not work when I initiate the GPX-calculation via Locus. When I select the "calculate instruictions" checkbox, I hear the locus-generated waypoints, and when I do not select it, I get nother type of display (guiding?) amd yet another style of voice messages, which are also no my ones.

See the discussion here:

https://groups.google.com/d/msg/osm-android-bikerouting/1ZRP9qzn3-k/pgQw3s2xAgAJ

Can you confirm that you always ignore the waypoints when reading a GPX from BRouter's AIDL-Interface?
It there a quick solution or do we need a software change?

thanx, Arndt

[Menion]

Good day abrensch,

also from a post in a discussion group, may I understand that you are a part of development team behind BRouter and wants to extend it? Finally .

So as I read, main problem is format, how to exchange some data, right? My opinion is, that BRouter should be the one, who define format. Other apps may use it if wants. So I see some option like "export for OsmAnd, export for Locus, ..." quite crazy.

Also there is no universal format for this task. TCX format may include some instructions, but is quite limited = useless. GPX by default do not have any extension for this case. So I really suggest to create own extension to GPX format with all information you may provide. I'll gladly, as well as other app developers, adapt it to own applications.

Anyway if you will wants to use format I use in Locus, less work for me, anyway it's not clear solution I think. Locus is app who wants something, so it should adapt to BRouter format, not opposite (in this case of course, when we do not have any universal format).

About "ignoring waypoints". It is quite possible. Locus by default do not merge them into track. If you may provide me some beta version, I'll fix it of course. Let me know ... I'm here at your service!

EDIT: ehm, sorry. I finally looked on your name Arndt. I'm sorry, we already talked about BRouter long time ago, so I didn't recognized you immediately.

[tommi]

Menion, wouldn't the format of data which Graphhopper exchanges with Locus perfectly match the needs for integration of BRouter?

[Menion]

I do not know what format are you talking about. GraphHopper add-on use Java objects (classes) for exchange, not any readable format.

[tommi]

Well then these Java objects are the "data format" which are used to exchange information.
But maybe you are in direct contact with Arndt and have already found a solution with him.

[poutnikl]

Arndt has mentioned in Brouter Google group idea of advanced hints info in the GPX comments.

https://groups.google.com/forum/#!topic/osm-android-bikerouting/1ZRP9qzn3-k

[abrensch]

Anyway if you will wants to use format I use in Locus, less work for me, anyway it's not clear solution I think.

Hi Menion,

sorry for the long delay, but here's what I came up with.

You can use the latest version (1.4.) of BRouter from it's homepage (not yet on Google Play):

http://brouter.de/brouter/revisions.html

use the apk there'in, and also update the routing profiles (they are not automatically overwritten by an APK update. Simplest way is to just delete the "profiles2" directory, it will be re-created on next brouter app start)

After careful consideration, I decided to go with the native turn-instruction formats used by Locus and OsmAnd.

3 ways to generate an GPX, so 3 ways to make sure that Locus format is used:

- when creating a GPX via the BRouter app, nothing special to do. The profiles are configured to "turnInstructionMode = 1 = auto, which means it generates Locus format when using a Locus waypoint-database.

- when creating the GPX by requesting it via the AIDL interface, you must send an additional parameter
  "turnInstructionFormat" with value "locus".(Just the same way you are sending "lons" and "lats", but with a String value)

- when creating a GPX via the Web-Interface ( http://brouter.de/brouter-web/ ) you have to modify the profile to contain turnInstructionMode = 2 (use the "upload" button the upload the modified profile)

I tested the voice hints by manuelly importing them into Locus, and that works fine. So I really wold like to be able to use them also when using BRourer via the AIDL-Interface...

What you have to change for that is:

- send turnInstructionFormat = locus as secribed above

- evaluate the locus extensions containing the turn-instructions the same way you do it when importing with "merge waypoints into track"

What you should also do is look at a bug I encountered when using the "roundabout" hints:
the first instruction after a roundabout that is not a roundabout is announced as the last roundabouts exit count ("third exit") instead of the actual next instruction ("turn left").

Thanks in advance for looking into this,

regards, Arndt

[Menion]

hello @abrensch,

no problem with delay, I was just little worried to make this working till next Locus version. Anyway I'm really glad you made a decision. No matter if native formats or now ... decision

Let's finish method with direct compute over Locus (AIDL):
- first smaller problem in Locus - waypoints before track. Fixed

- second issue are roundabouts. You use method where is only a single navigation command at start of roundabout. For this is needed to include "Simple roundabout" parameter to track.

This may be done by two options.

1. improve your export to GPX as in attached track_modif.gpx file (compare to orginal). Probably best solution as it will improve all GPX files from BRouter to Locus

2. I may setup this in Locus, but it will then work only over AIDL

3. my recommended solution ... this about option to place also second waypoint on place where user should exit the roundabout. In case of huge rounabout, this second command has also a send as Locus then correctly inform about place where to really exit.

So I suggest to make solution no. 1 as soon as possible and later think about 3. option.

[abrensch]

So I suggest to make solution no. 1 as soon as possible and later think about 3. option.

Thanx Menion,

so I implemented solution no. 1 and uploaded revision 1.4.1, see http://brouter.de/brouter/revisions.html

I test-drived it and it really solves my issue with roundabout-announcements.

I will look at the extended roundabout announcements later.

I will upload version 1.4.1 to google play shortly if I do not get any alarms.

looking forward for the new locus release :-)

regards, Arndt

[Menion]

Perfect, thanks!


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. There is a lot of people who make a nice profiles and with this improvements (generated commands), I'm more and more thinking how to get your tool to people in some "more usable form". Or is this a total nonsense and you need to map profiles only over app itself (or file)?

[abrensch]

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

[Menion]

Nono, it's not needed to next release. It will take also some time on my side, so no hurry.

For me, it's not a problem to accept whatever method will be best for you. Request on all profiles and name of profile, or just name of profile that Locus get directly from brouter/profile directory, or maybe a full content of profile file as parameter ( which should be most useful from my point of view as it may allow to include some special profiles directly into app/assets and send them just over AIDL). But what is and what isn't possible, you know it. Thanks for consideration!

[Christian]

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

That would be nice! We can use any profile located in brouter directory even these not mapped in Locus.