turn instructions are skipped in special situations

[EssBee59]

1203.gpx.txt
1203_missedTurns.gpx.txt

Hello,
By navigating with use of GPX tracks/routes I miss in some locations the "turn instruction"!
The problem does not occur often, but, as it can be reproduced, I spend time to analyse it... in the hope, it could help the Osmand developers and consequently the users.

(I am using the option "turn screen on/off", so a missing turn instruction leads generally to a navigation error / deviation from the route)

The environment:
OSMAND: 3.9.8 (test also with daily build from 12.03)
Smartphone: Xiaomi MI 9T pro (Snapdragon 855, dual band gnss)
Navigation type: BRouter (MTB), but also observed using the "bike" profile of Osmand
Navigation input: Follow a gpx-track (generated with BRouter-web and containing a track and a route with the turn instructions)

Problem:
By navigating with the attached file "1203.gpx" (152 rtept=turn instructions + 1.013 trkpt) 4 turn instructions are missed!
(see attachment’s 1203.gpx.txt and 1203_missedTurns.gpx.txt)
Below I will use for these 4 positions the names "Skipped_Turn_1", "Skipped_Turn_2"..." Skipped_Turn_4"
"missed turn instruction" means:

• on the display / left panel, the distance and direction for the nextturn is in error (it indicates the distance/direction to the nextnextturn!)
• in the same way, the voice messages refer to the nextnextturn, so most of the times no voice message is activated at the nextturn, and the screen remains longer "off"!

Analysis:
With the help of the android logcat and special traces I found a lot of information’s about the error situation:
At each skipped turn instruction, I found the following lines in the logcat:

03-18 17:10:36.271 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:36.271 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:36.297 773 970 E LocSvc_SystemStatus: PQWP7parser - invalid size=404
03-18 17:10:36.319 780 886 I chatty : uid=1000(system) HwBinder:780_1 expire 46 lines
03-18 17:10:36.325 31715 31715 D net.osmand: RoutingHelper Processed point bearing deltas : 84.18744659423828 0.233123779296875
03-18 17:10:37.239 31715 31715 I net.osmand: RoutingHelper Recalculate route, because wrong movement direction: 58.04298

==> the "Skipped_Turn_4" ossurs near to here!!!!!!!!!!

03-18 17:10:37.240 31715 31715 D net.osmand: AbstractPrologCommandPlayer abandonAudioFocus
03-18 17:10:37.252 31715 32157 I net.osmand: RouteProvider Start finding route from Location[mProvider=fused,mTime=1616083837233,mLatitude=49.9836702,mLongitude=8.5978151,mHasAltitude=true,mAltitude=104.63290101882819,mHasSpeed=true,mSpeed=2.5284154,mHasBearing=true,mBearing=273.21997,mHasAccuracy=true,mAccuracy=12.344,mHasVerticalAccuracy=true,mVerticalAccuracy=3.0 to Lat 50.02628 Lon 8.672062 using BRouter (offline)
03-18 17:10:37.256 31715 32157 I net.osmand: RouteProvider Finding route contained 156 points for 4 ms
03-18 17:10:37.262 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:37.262 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:37.264 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_GNSS_SV_INFO_IND_V02
03-18 17:10:37.264 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:37.264 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_POSITION_REPORT_IND_V02
03-18 17:10:37.265 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:37.266 773 2004 I LocSvc_ApiV02: <--- globalEventCb line 170 QMI_LOC_EVENT_NMEA_IND_V02
03-18 17:10:37.288 773 970 E LocSvc_SystemStatus: PQWP7parser - invalid size=404
....

I had further a look at the Osmand-code (RoutingHelper.java) and made a list oft he events leading to a Skipped Turn..

1-Error " E LocSvc_SystemStatus: PQWP7parser - invalid size=404"
2-Message: net.osmand: RoutingHelper Processed point bearing deltas
3-Message: I net.osmand: RoutingHelper Recalculate route, because wrong movement direction: 58.04298
4-Message I net.osmand: RouteProvider Start finding route from.. (and following)

Where is the origin oft he skipped turn?

1-Error " E LocSvc_SystemStatus: PQWP7parser - invalid size=404"

This message appears every second, it is probably as result to a position-request from Osmand.

• but these messages also appear with other Apps
  -I did nor see a correlation between this message and errors in the position or the bearing
  ( I did a trace of the curentPoints during a new routing: very few positions were in error, few positions had a wrong bearing, possibly do to MTB trails with non straight routes..)

So, I think this is only a warning?

2-Message: net.osmand: RoutingHelper Processed point bearing deltas

This message occurs at each new trkpt.
I did not find any issue with this message...

3-Message: I net.osmand: RoutingHelper Recalculate route, because wrong movement direction: 58.04298

Many remarks about this event:

3-a

" Recalculate route" "in case of reverse direction" was enabled during the navigation... but this was not intentionally!!!!
I think, a confusion was made in the text of Osmand-Settings, leading to an opposite behaviour ..
I opened a separate issue fort hat; See #11206

After changing the option "in case of reverse direction" to "enabled", the recalculation did not longer not start (!!!)
==> and no Turn-Instruction is skipped during navigation any more !!!!!!!!!!

The solution I am using now!!!

3-b

A further condition for "recalculate" the route is the result of the function "RoutingHelperUtils.checkWrongMovementDirection":
Is a deviation of 60 degrees between bearing of currentPosition and the Routedirection not too strong?
I think, "reverse direction" only really exists when the deviation is 180 degrees?

Remember; MTB / hiking tracks are not always straight, deviations are possible: the best example is Skipped_Turn_4 as above documented!

I made a trace with 2 values for checking, 60 and 120 degrees...and navigated again my track:
1.024 times checkWrongMovementDirection (60 degrees) return "true"
367 times checkWrongMovementDirection (120 degrees) return "true"

As 367 times is too much, I think a good recommendation for MTB / Hiking profiles should be NOT to recalculate the route "in case of reverse direction" ???

4-Message: I net.osmand: RouteProvider Start finding route from.. (and following)

If a route-calculation (or recalculation) occurs on the route between the last Turn and the 4 "Skipped Turns" points, the calculated route is in error:
The nextnextturn is returned, not the nextturn!
Any explanation for that?

Conclusion:
For my own, I will "deactivate" the route recalculation "in case of reverse direction" for biking!
I suggest to implement a solution to #11206...
AND if possible, to recommend, not to use the "route recalculation" for biking!

Regards
Ess Bee

[scaidermern]

Do you use the "attach to the roads" feature when using a GPX track for navigation? If not, it is expected that turn instructions for slight turns will be missing.

[EssBee59]

Hello Scaidermarn,
Sorry, I could not find this option (I am using the Brouter for routing!), or can you help me?
But as the turn instructions are in the GPX (the route part of it), I thought Osmand do not change these instructions previously created with brouter-web?

[scaidermern]

Sorry, I have no experience with brouter + OsmAnd.

[EssBee59]

I come back to the reported probem..

If a route-calculation (or recalculation) occurs on the route between the last Turn and the 4 "Skipped Turns" points, the calculated route is in error:
The nextnextturn is returned, not the nextturn!
Any explanation for that?

This problem only occurs in the very special situation where...

• A route calculation (or recalculation) starts
• A gpx file is used as input
• the gpx file contains a track AND a route with OWN turninstructions
• The current position is on the track, so that no "routing" is necessary

Only in this situation, the nextnextturn is used once for the first turninstruction after the (re)calculation instead of the nextturn!
Probably only few users are concerned...
The problem has more negativ impact when the user (unintentionly due to a settings problem) activated the option "recalculate route "in case of reverse direction...

So, if a quick solution can be found, perfect!
If not, feel free to close the issue!
Regards