OruxMaps turn instructions no longer working

[quaelnix]

Forward from mtb-news.de:

Somehow I no longer get turn-by-turn instructions in OruxMaps (7.4.27), neither visually on the route nor as an announcement (which was possible before). It doesn't matter whether I calculate the route directly in OruxMaps via the BRouter app or whether I import a GPX file from Bikerouter.de. For the latter, I had already set the "turnInstructionMode" to "oruxmaps-style" in the options.

Used software versions:

• OruxMaps v7.4.27
• BRouter v1.7.3

[afischerdev]

When I control what OruxMaps is sending v=motorcar, fast=0, lats=[49.84404362156558, 49.84844371984589], lons=[8.788161277770996, 8.806228637695312], instructions=1, trackFormat=gpx, turnInstructionFormat=locus I can't find orux turninstruction mode. When I do with this data an external BRouter routing with orux export and import this into OruxMaps, so all voice hints are visible.

[quaelnix]

Supposedly it does not work if the turnInstructionMode is set to oruxmaps-style.

[rkflx]

OruxMaps turn instructions no longer working

vs.

Somehow I no longer get turn-by-turn instructions

IMO you are jumping to conclusions here, which makes an unbiased root cause analysis more difficult. Technically, "User unable to get BRouter-generated turn instructions working in OruxMaps" is all that can be inferred. It could be caused by a user error or by changes to OruxMaps, BRouter, BRouter-Web or bikerouter.de.

For me, exports via BRouter-Web (both legacy server-side and modern-style client-side) and via BRouter Android (called from OruxMaps) all show TBT waypoints in OruxMaps just fine when configured properly for oruxmaps-style turn instructions. I do not see any evidence presented which warrants the "bug" label at this point, which makes this more of a "How to get X working" type of question.

Supposedly it does not work if the turnInstructionMode is set to oruxmaps-style.

I'd suggest to always check claims users make critically, get other users to confirm the problem and/or try to reproduce the issue yourself before forwarding a bug (the issue tracker is not supposed to become a user support forum, after all). Maybe they tried to make that settings change, but it did not actually take effect? This should be easy to verify by looking at the resulting GPX file or trying to import a known-good file into OruxMaps yourself.

I bet they simply did not press the "Apply" button on bikerouter.de (which admittedly is missing a proper inactive/active transition on unsaved changes) and were thwarted by BRouter Android's lovely (/s) config UX as well.

---

turnInstructionFormat=locus

It is difficult to investigate (due to the closed-source nature and unavailability of old versions of OruxMaps) whether that used to work in the past.

All I can tell is that neither locus (checked via BRouter-Web's server-side export) nor locus-old-style (checked via BRouter-Web's client-side export) seem to work right now for OruxMaps imports. IOW, to make TBT waypoints appear for BRouter routes requested from within OruxMaps without needing to edit .brf files, turnInstructionFormat= would need to be changed inside OruxMaps' source code itself (including verification of that code path on the BRouter Android side, of course).

[vodie]

On Android OruxMaps calls BRouter via service interface with turn instructions in Locus Maps style and convert them internally. Since the Locus Maps turn instructions are changed, they no longer work with OruxMaps. The OruxMaps style was created by me for brouter-web to get turn instructions in the exported file. This was done after OruxMaps developed the turn instruction import on Android.

To solve the problem OruxMaps has to change their import via service interface on Android.

[afischerdev]

I can confirm, with an edited profile it will work.

@vodie The easiest way could be to switch the parameter turnInstructionFormat in the interface call. I tested with this in BRouter app to get your favorite result:

      params.remove("turnInstructionFormat");
      params.putInt("timode", 6);

Please have a look at the interface definition. May be you like to change some other things that are new in the interface. And there are some new voice hints that are not included in your export. Please let us know when you need some changes in voice hint export.

[rkflx]

This issue has an issue: Which of the following cases are we actually talking about?:

1. Import into OruxMaps from bikerouter.de (with turnInstructionMode set to oruxmaps-style)
2. Import into OruxMaps from BRouter Android (with .brf configured to use oruxmaps-style / 6)
3. Import into OruxMaps from BRouter Android without changing anything (i.e. locus vs. locus-old-style)

Cases 1. and 2. are layer 8 issues, 3. should be rather called "New Locus turn instructions no longer working via OruxMaps service interface import". The latter is caused by either OruxMaps not keeping up or by BRouter unnecessarily breaking backward compatibility by changing the old format instead of introducing a new format.

turn instructions in Locus Maps style and convert them internally

So that conversion only takes places when importing data via the BRouter service interface, but does not happen when importing via the GPX file type intent?

[afischerdev]

@rkflx

The latter is caused by either OruxMaps not keeping up or by BRouter unnecessarily breaking backward compatibility by changing the old format instead of introducing a new format.

Yes, that is the point. But please keep in mind the OruxMaps v7.4.27 is from 1. January 2017 and someone has to change the app (Locus or OruxMaps), in this case OruxMaps because the change was related to Locus export. OruxMaps was informed about the changes and has already updated the Play Store version - I think.

[rkflx]

Due to the lack of proper API versioning in BRouter one of the only options left now seems to be the addition of client version-based workarounds (e.g. we might investigate if it is feasible to detect a request originated from an old OruxMaps version and send an oruxmaps-style reply unconditionally, further complicating the codebase).

[afischerdev]

Due to the lack of proper API versioning

That had to be said. It wouldn't have helped with the problem mentioned above. If we had set the version number to 1.8.0 or 2.0.0 - whatever - the old OruxMap version would still have a problem.

As suggested, I picked out the calling instance. So now the question:

@vodie Should we incorporate the workaround, or is there an update to OruxMap version 7.4.27 in the near future?

The workaround looks like this:

      if (callingName != null && callingName.equals("com.orux.oruxmaps") && callingVersion <= 70427) {
        params.remove("turnInstructionFormat");
        params.putInt("timode", 6);
      }

Would this also fit the current OruxMaps version 10.5.0GP in the Play Store? Should be neutral.

[vodie]

@afischerdev I am not involved in OruxMaps. I did only the OruxMaps export on BRouter to help someone from velombilforum.de.

[rkflx]

If we had set the version number to 1.8.0 or 2.0.0

I was talking about API versioning, not the application version.

As suggested, I picked out the calling instance.

I have no idea what that means. Anyway, I have no desire to discuss #584 again. My point was merely that this will keep haunting us in the future, so we should make sure that we never ever do such things again.

Should we incorporate the workaround

If you decide to go for it, please document this properly both in the code and in public documentation, so that neither developers nor users will get confused as to what is going on with that workaround.

OruxMaps was informed about the changes

Why don't you use this point of contact again?

[oruxman]

Hello everyone!

Tomorrow I will release the free Oruxmaps version 7.4.28 which will fix this issue.

The fault was OruxMaps, which was using a mode intended for another app.

Sorry for the problems caused!

orux

[afischerdev]

@vodie Yes, sorry, I didn't recognize at that moment.

@oruxman Great, thanks a lot.

@rkflx

I have no desire to discuss #584 again.

Me too - but you started.

[afischerdev]

a new OruxMaps version 7.4.28 is available.

@oruxman Thank you