A to B route redirection

[RetiredWingMan]

I was out yesterday and had a great ride. When it was time to head home I opened an A to B route (non curvy) just for the fun. When I deviated from the route MRA worked hard to try and get me back onto the original route. It worked so hard that it even ignored my routing options and tried sending me down gravel roads and onto a Toll road even though those options had been disabled when I started the route. V 4.1.3 312.

[Con Hennekens]

@RetiredWingMan, Are you sure you did not add a curvy option? I have just tested it, but the straight line route to destination still generates a route, and not a track. Since in a route all route calculation is explicitly done to the finish waypoint, I don't see how it frantically could send you back to a track. You can test if it is a track or not by enabling flightmode, because we all know tracks cannot be calculated offline Also remember that in THE APP the roads need to be disallowed (off) where in the WEB PLANNER they need to be avoided (on) in their respective options.

[Jörgen]

I had something similar yesterday. I went off a planned route to a nearby station, and the new calculated route sent me to a gravel way that ended in a footpath.
I would like to simulate this, but how to do?

[RetiredWingMan]

@Con-Hennekens yes, I'm positive it was a route and I didn't select a curvy option. Yes, I know toll roads and gravel roads were not enabled. And I was in offline mode. This is not the first time I've seen this behavior.

[GT JWR]

Ironically, I had a similar issue just yesterday as well...started an A-B route, about 175mi from home. With about 60mi to go, I was in very familiar territory, and I knew every possible scenario of route choices to take, that were all within ± 10 mi distance between them all.

This pic shows the A-B drawn route, and the start of the deviation I took:

I deviated from the drawn route to the shortest route (the A-B route did not have that as the selected option) - AND FOR 22! mi, it tried to get me to do a u-turn and go back to the route drawn by the app.

It was not until 22mi later, the app finally redrew - up until then, it wanted me to do a u-turn

[Con Hennekens]

@GT-JWR, That does not sound completely unplausible though. There is (like you already experienced) no method to change from quickest to shortest route while navigating. Therefore the app continues directing you the quickest route. Since the road you took as a deviation does not even show on the map in that zoom-level (I guessed the red line) it is likely a small country road, and the way back through the original route is quicker until a certain deviation from it is reached.

If you still have the screenshots with the correct timestamps (or the clock visible) and the log-file, you could ask @Corjan-Meijerink to do a simulation, to see the reasoning for preferring the previously calculated route. Maybe it is worthwhile, because in this case it indeed seems to prefer a longer route.

[GT JWR]

@Con-Hennekens the red line you drew is pretty close to what took place. The fact that the map does not even show the road is an indicator of how, IMO, the zoom level is sub par. The zoom level was on, for both speed and distance.

As for which is fastes or not, the speed limit on the app drawn route vs the way I went is within reason, as is the 'amount' of towns/cities that have to be ridden through. So all in all, the 2 options should have been very comparable. The fact that the app did not redraw for 22mi is the real shocker here....the ZUMO XT that I had on (for backup, becauze of this type of issue with the app, and the battery drain issues) immediately redrew within a couple of miles, as would be expected. As I said, this is a very well known area for me, I know the time it takes, etc, on both routes. Anytime I have alternate nav apps on, they redraw within a reasonable quick time period...not excessive miles.

Unfortunately, it was a spur of the moment A-B route, and it is longer available, nor would the log be. Not to mention, the 'avoid highways' was also enabled, so there is no way the app route shoud have wanted to take me to one of the biggest Interstate freeways there is in the entire US.

Out of curiousity, here is what Google Maps shows - this 1st snip is the way the app orignially drew - it is 54.4mi, 1hr2min estimate. And the secondary route it shows, 59.3mi, 58min, is quickest, although it is not the chosen route...just pointing it out.

The way I went is 54.8mi, 1hr 5min....so you can see, there seems to be no logic in the app taking 22mi to redraw the route.

....and also just to point out a big difference in the zoom level vs Google...Google shows a lot of the secondary roads whereas, as you pointed out, the app does not.

Plenty of room for improvements.

[Con Hennekens]

@GT-JWR, I am not sure what you mean by:

there seems to be no logic in the app taking 22mi to redraw the route.

Was there no calculation, and therefore no blue line leading the way?

[GT JWR]

@Con-Hennekens not sure I understand your question - if you are referring to a blue line leading in the direction of the deviation, yes, it was there.

Again, you have pointed out, IMO, a flaw in the app, - the lines are just aggressivley large and as a resullt, mask a lot of things, such as fine detail on the road, and in this case, the blue leading line. Part of the reason why it is not seen in the above pics is that in order to capture the route overview as well as the deviation taken, the route had to be zoomed out manually, and as soon as that is done, the resulte is the ungawdly thick blue lines, creating unecessary distortion/distraction.

[Con Hennekens]

@GT-JWR, by "taking 22mi to redraw the route" I understood that there was no recalculation, but it seems that there was, just not in your prefered (or logical) direction then).

It is not that there are parameters to send you "back to the route" against any other logic than the fastest or shortest route. It would have to be simulated to see on what logic the route is been decided. I have no means of assisting in that.