Rerouting problem at start of navigation


First off I love both the kurviger (pro) app as well as the website and have been using them for more than two years now.

I do think I found an issue in the rerouting algorithm. To illustrate, I attach two screen-shots indicating the route before and after the rerouting took place.

What happens is that when you start off the loaded route and chose to reroute to the nearest point on the route kurviger seems to add a (shaping) point at the closest (euclidean?) distance. When the route is then recalculated some parts of the route are visited twice as shown in screen-shot after.png.


1 Like

Can you post more details, like the app version and what rerouting settings you use?

Rerouting in nearest route point works like that, sets a new waypoint in nearest route coordinates and triggers a new route calculation.
The result depends on how router does the calculations and on existing route geometry.

You can try also the other rerouting options in “Settings | Navigation | Rerouting mode”.

Version is the latest beta 1.13.5. Settings for rerouting are “nearest route point”


It also happened to me sometimes. Is it because Kurviger measures point-to-point distance not by street (blue) but by air (red) ?

Navigation knows only user location and the route.
Road network is available only in the route service.

So in the example the nearest route point is the (1).

1 Like


Thinking more about this I believe you can only solve it iteratively. The scenario in my screen-shot would be the first (sub-optimal) iteration. From there you’d have to move around the added point (no. 1) and recalculate the route. In my simplified example the solution is obvious (move the point to the first intersection with the original route). But would that work in general ??

We cannot do continuous recalculations, specially online, to just find a near point.

That’s why the other rerouting modes exist and are default, as better alternatives.

What I mean is a one off operation (when you start the navigation and chose to reroute).

From a user’s point of view the problem effectively means you have to manually check the route everytime you hit start/reroute.

Cannot know road details without run a graph traversal on the road network.

There is an open discussion for extra rerouting options at start of navigation.

I don’t follow. Shouldn’t the two polygons be enough?

Thanks for the cross ref. From my point of view the options are perfect as they are !

It’s not clear what you mean.

“Nearest route point” is supposed to find (from user location) the nearest point on route geometry - which consists of a series of (invisible) coordinates.
Nothing more is known, just a reference point and a series of coordinates, so the nearest is (1).

Sorry. My bad. Let me try again.

Looking at my screen-shot, the app sends me in the wrong direction and then asks to make a u-turn at the inserted point.

This is counter-intuitive IMO.

My expectation was/is that it somehow leads me to the nearest point to join the route. Isn’t that what "“nearest route point” suggests?

Understood. My comment was meant as an ‘extension’ to this logic/algorithm.


Human perception is completely different than mathematics. :slightly_smiling_face:

How can maths know that there is not a near road between the 2 points?
We cannot perform multiple route requests until we find one that we “like”.
That’s why other rerouting modes exist or can be available also in start(?).

If the user would have manually set a WP at the (1) nobody would be surprised.

So the “issue” is that humans think that *nearest point on route" should be at the intersection (blue arrow). The driver can ignore the shaping point (1) and navigation should continue normally, so it is not a big deal.

I think (in theory) this could be solved with only a single route calculation.

  • keep the original route in memory
  • do a route calculation towards nearest point on route
  • the point where the new route hits the original one, should be the correct place to merge the two routes.

Probably a lot of work for a simple problem.

Precisely, it’s easier to just add also the “Nearest waypoint” in the start options.

If nearest waypoint is at the (1) the same thing would happen.

There is no waypoint at (1) when start.
(1) was created because of rerouting.
(see first image)

Nearest waypoint in example is destination.

Assuming that every case is as simple as the one depicted in the screen-shot you are right of course.

I doubt that a single rerouting operation will do. The first rerouting operation is needed to get the actual intersection with the original route.

The point I was trying to make is that once you obtained this route, you can identify the intersection by using the two polygons (original and new) of the two routes. The identification itself doesn’t need the routine engine. Once the point was identified you then need the routing engine a second time to compute the final route.

I agree in that the problem doesn’t look all too complicated. Whether or not this is difficult to implement in the given application, however, is a different story.

To my point of view this is needless nitpicking. Too much effort for such a tiny issue. When I am starting off the planned route for example because of reloading the route and I am somewhere out in the fields let’s say near wp25, then I don’t care if it routes me to a turning point x or y near the wp25 as long as it doesn’t guide me back to wp1 till wp24 and I mean this independent from the routing options set (my new default is strictly following the route).


Waypoints could exist anywhere on the route. Although there is no WP at (1) in the above example, there could have been one. So you would gain only a little. But users would not be surprised if app routes towards a WP. :wink:

Another idea that might work better:
Nearest point on route, that does have turn instructions. :thinking:
In other words nearest “yellow dot”.