Rerouting heading

Also @0709’s suggestion in another topic:
add block areas behind user before rerouting.


BRouter supports nogo areas.

GraphHopper plans to deprecate the block_area:
(also used in “Avoid roadblock” feature)

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!

Have a nice day.
MO55 :slightly_smiling_face:

At first Kurviger (like GraphHopper) didn’t even have turn restrictions enabled.

However routing on real road network must respect turn restrictions, heading, …
Or else it is not very useful for vehicles and navigation, except pedestrians.

The turn restrictions were enabled later.
The heading in the routing is unfortunately still not working properly.

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.

What if your distance to target indicator suddenly increases instead of decreasing ? “What action maneuver to expect ?”.

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.

It is a problem of the Kurviger routing (not the app).

Navigation displays / speaks the next turn instruction.
And after rerouting (which is not done in milliseconds)
user is already away from the start (it is behind them).

Yes.
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”)

Yes, indeed!

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.

8.) My old navigation app Navigon, which I cannot use any more, gave me instructions how I can change my direction in this case. Found a new way.

9.) More detail.

As already explained, it a routing problem:
(routing does not respect the heading)


Route must be correct respecting user heading.

If routing server does not solve it,
I may see what is possible in the app:

From the driver’s perspective it doesn’t matter, if the solution is implemented in the routing server or in the app. The main thing is, that we get a good solution.
THANKS MO55 :slightly_smiling_face:

1 Like

Refers to the Kurviger route file in the first example.
https://forum.kurviger.de/uploads/short-url/5TLfkHH6lNlSPpfWvt5z922CdB7.kurviger

Rerouting ON and the “snap to route” (visual) ON.

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.

However.
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.
Example 1.

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)
Example 2.
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.

Snap to route is for visual effect, not really needed / used anywhere.


There are off route warning and tone in voice guidance settings.
When you hear either of them, you are off route, then can “return”.


The routing heading needs to be fixed in the server.
Otherwise the rerouting heading in the app (somehow).

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.

Translated with DeepL Translate: The world's most accurate translator (free version)

Let’s not keep going in circles and complicate the app and its maintenance.

It is not an app problem.

It is a Kurviger routing problem that does not respect user’s direction and calculates wrong routes:

If Kurviger routing does not want to fix it…
I may look for alternatives to the app in the future.

The truth is also that a *router cannot route backwards and therefore does NOT generate a U-turn at the then new (re)starting position, but always and only can and will technically route into a forward direction (the user can interprete such generated direction than as backwards, but the router can not) and so than does generate a “Straigth” command (sometimes suppressed) directly towards its next (new) target point.

  • as well the Kurviger GH and the Brouter

Compare. This is just like (re)starting a platoon in the army. “Forward…mars”.

Routing services calculate routes based on their parameters.

Some of them have a heading parameter and they must respect it.
Software can be very simple if it just follows the rules.

If they do not have heading or turn restrictions,
then they are not suitable for forward moving vehicles.
Only for pedestrians or seen as academic works.


In any case, let’s not make this topic lose its meaning.

The root of the problem lies in the Kurviger routing.
I may look for workarounds in the future.

One of them might be to disable Kurviger rerouting in navigation.
I will see what is best for the navigation experience. :thinking: