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.
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. 