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.
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â.
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 ??
â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).
Human perception is completely different than mathematics.
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.
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.
Another idea that might work better:
Nearest point on route, that does have turn instructions.
In other words nearest âyellow dotâ.
