Thank you for all your explanations.
I’ve searched for other topics with the same/similar problem and I’ve read those.
I think there is no further explanation and discussion necessary why the problem exists.
Please keep in mind!:
I am using only my smartphone to navigate. The smartphone is always in the motorcycle jacket. I only drive according to voice instructions. This is the only solution for me to be navigated on my naked bike (motorcycle)! The voice instructions have to come unambiguously and at the right time. I definitely want to avoid stopping and pulling my smartphone out of my jacket to see the display or to interact with the app! And notice, with only voice instructions it’s more likely to take a wrong turn!
I have spent some effort to create this problem report.
Because its a serious problem for me. And I assume for others too!
The problem has been known since Feb 2021 or even longer.
So developer, I beg you very earnestly: !!! Please fix it as soon as possible! !!!
And I guess you will be rewarded with an even better rating (Google Play Store) and more satisfied Kurviger (Pro) users!
You don’t need to search for a good intersection.
A simple u-turn announcement if routing headig differs too much from calculated route would improve turn instructions a lot.
Another crude idea would be, to “throw” a shaping point in front of the vehicle.
Something like this: Route with heading 270° and a shaping point in direction of vehicle movement.
This way at least a u-turn announcement is created.
I think, that would mean, that you are driving backwards.
The expected action should be a recalculation.
Kurviger2 does this if “setting | Navigation | recalculate if in opposite direction”
(I think Kurviger1 does also trigger a recalculation)
The recalculated route should either find a new way in the new direction, or turn around (= u-turn).
The issue is, that routing engine does not generate u-turn message in this situation.
If you put a WP just in front of you, u-turn message at that WP would be generated.
That was my idea with the route example above
It may generate it in the 1st turn instruction at new route’s start.
But this is not useful, as users are already moving away from the new route,
which was calculated behind them! And u-turns should be avoided.
The proper solution is to calculate correct routes, respecting the user heading.
I may see the block area idea, if / when I have free time in the future.
(as the server refuses to fix the routing heading)
If so, user should hear a “turn around” message. I have never heard one.
Do you suppress 1st message?
Even if you are moving away from the new route, a u-turn message could help users who navigate solely by audio. Not ideal, if you drive away from new generated route, but a u-turn message (after recalculation) might help audio only users.
1.) The recalculated route should either find a new way (best way, shortest way) in the actual driver direction. Recommended solution.
2.) Or turn around as soon as possible (= u-turn). The issue is, that routing engine does not generate u-turn message immediately in this situation like this “Turn around anyway”. (In the actual implementation you hear only “Calculate route”)
There are situations there is no other way but back (u-turn). See my example at the beginning of the topic (sreenshots and video). This can happen more often with the setting Navigation(Pro)->Strict route following: yes.
My old navigation app Navigon, which I cannot use any more unfortunately, gave me instructions how I can change my direction in this situation.
7.) Again, the situation after several root re-calculations.
If you miss the turn, the distance indication to target (Finish) suddenly increases. THE APP (not the router) could generate a “return” even before the first recalculation trigger.
An additional difficulty is that the road on which is driven stays close to the route. Therefore the route design sometimes remains just in the “snap to route” navigator catch range. (Even with visual snap to route display off, this function still remains).
The navigator therefore wrongly thinks it is on the route. As a result, the navigator presents itself very confusingly for a while. A stable distance indication increase to target (Finish) is only there once you are out of the “snap to route” range. If the route and the road you are driving on are further apart then, it is more stable clearly.
Therefore, here is a slightly different demo route design where the “snap to route” function does not cause any additional confusion.
You miss the turn and so you drive wrong. The distance counter to target (Finish) then increases, and the app notices this. If the distance increases and each time the “snap to route” is then released, could the app possibly generate a “return” alert even before a recalculation is triggered? dorfstr.-schulkoppel_alt.kurviger (1.2 KB)
No (auto)rerouting activated.
The TTS “Please go back” trigger occurs the moment the snap to route action moves out of the hold range. By Kurviger Setting: (auto) rerouting OFF.
The video is on low speed vehicle so that you can easily follow the operation.
The “Calculate route” message was set to not active but instead uses the “tone”
I prefer the short off route tone, and yes sure, I do know what that tone than means.
The snap to route operation is always there internally anyway.
Without it you do not have a navigator but a freeride indicator ?
The request was:
I then understand this question so as follows.
Tell me by TTS what to do instead of that recurring “Calculate route” message.
So…I suggest…= a free idea or a workaround…
The time when the snap to route “arrow releases” is slightly earlier than the “Calculate route trigger”.
Use this specific moment to notify “Come back” before the “Calculate route” TTS msg soon but later comes. So the “route” calls you back even before any help is requested by a trigger to the router engine app.
I so do suggest to use than the softer “Come back” instead of the command “Make a U-turn”.
Or the missed route so friendly calls you back by TTS > “Come Back …Calculate route”.
Always know this:
“Treat turn instructions as requests that you consider rather than commands you obey”.
The story goes that a GPS user did not even wait for the ferry boat but drove straight into the water.