Re: Looking for the best start option to begin a planned route.
Posted: Tue Jul 29, 2025 11:21 am
Thanks @proofresistant .
Am I correct in the observation that your CEP misbehaves only after the route has been recalculated ?
You may want to skip to the question that I ask at the bottom of the page. Thus is a rather long reason for me asking it.
A while ago with the XT1, I checked whether or not CEP recalculated the whole route. For the tests that I carried out, it didn't. I tested this with routes prepared on Basecamp that had via points at junctions along a main road. It had 2 or more shaping points on side roads - first one side of the main road, then the other. This forced the route to follow a zig-zag pattern crossing to the other side of the main road at each of the via points. Without the shaping points it would take the main road.
I then set BC to strip out the shaping points on transfer to the zumo or gpx file. This can be done in Edit-Options-Device Transfer in BC. Or by right clicking on the route and selecting 'Strip Shaping Points'. The route stays intact without the shaping points and providing that the maps are the same, the Zumo should not recalculate it. So if at any point the route is recalculated, you can tell immediately because will follow the main road, and you can tell whether the calculation affects just the current segment to the next via point, or the entire route.
When navigating, Some operations result in the entire route being recalculated. Going off route is one. Pressing skip is another.
Sometimes only the segment to the next via point is recalculated. At the time of the test on the XT1, Closest Entry Point calculated only to the point of entry. The remainder of the route was left intact.
I did something similar with the. XT2 and it did on one occasion calculate to the end of the route. I didn't do any further tests to find out when and why because I thought that I knew why.
So..... ( all of this has a purpose, honest.... )
Sometimes When the XT1 and XT2 recalculates a route, they both change the nature of the route: It no longer follows the rules of going from route point to route point. It now follows the line that it has recalculated. That line may pass through all of the route points - or the XT2 may have moved them - but they are of no consequence. When you pass by them, they are not removed from the list of remaining points ( which you can determine by tapping skip to see which point is next, and then say no ). And if you wander off the route it will direct you back to its recalculated route at the closest point to your current position. Just like a track-trip *. If you by pass a route point, via or shaping, it doesn't care - the point just disappears from the map.
And when you go off route it chops the route into two parts at the closest point. It discards the part before the closest point, and calculates a new section from your current location to the new closest point. This is now the current route, and the green flag is planted at your current position.
This means that if you deviate from the route in a mathematically awkward way, so that the closest point is behind you, you end up in a never ending cycle. RUT behaviour. Yes indeed - track-trips display RUT behaviour.
I think that this is deliberate on Garmin's part. Garmin designed Basecamp to work with the Trip Planner app on the Zumo 590. People didn't use it because they couldn't be bothered to work out how to use it and in any case - it didn't work on mobile phones. So they used other software, which used different maps - which needed to be recalculated. Or some sort of fuzzy logic was applied to all route points which require them to be relocated slightly so that they worked But how much is 'slightly'. Well it is apparently more than the distance between the A6 and the M6 in N UK, because routes around there regularly jump onto the M6, and take the shaping points with them.
BUT there must be some routes where this doesn't apply. So which nones can we be certain that the route doesn't need altering ? Perhaps the ones created on the Zumo itself. And indeed, such routes never change their behaviour when recalculated. The navigation remains point-to-point. And they never get stuck in a RUT loop.
such routes have their mImported byte set to false - 0 and this can be altered manually; or by using @FrankB's SetTripToSaved utility, or by resaving the route. The latter is achieved by selecting the route, and then use the Spanner i on to copy it. Give it a slightly different name -I use the same name with @ in front so that I know it is the copied version. Run that route.
So the upshot of this essay is a question.
Does the same CEP behaviour happen on 'Saved' routes ?
Nb You could also use @FrankB's Trip Manager - but although that does an incredibly excellent job, it relies on the Zumo to caculate the route from scratch, and that wouldn't be a like for like test.
*Track-Trip is my term for a track that has been coverted to a trip (XT1) or to a route (as the XT2 now calls them.
Am I correct in the observation that your CEP misbehaves only after the route has been recalculated ?
You may want to skip to the question that I ask at the bottom of the page. Thus is a rather long reason for me asking it.
A while ago with the XT1, I checked whether or not CEP recalculated the whole route. For the tests that I carried out, it didn't. I tested this with routes prepared on Basecamp that had via points at junctions along a main road. It had 2 or more shaping points on side roads - first one side of the main road, then the other. This forced the route to follow a zig-zag pattern crossing to the other side of the main road at each of the via points. Without the shaping points it would take the main road.
I then set BC to strip out the shaping points on transfer to the zumo or gpx file. This can be done in Edit-Options-Device Transfer in BC. Or by right clicking on the route and selecting 'Strip Shaping Points'. The route stays intact without the shaping points and providing that the maps are the same, the Zumo should not recalculate it. So if at any point the route is recalculated, you can tell immediately because will follow the main road, and you can tell whether the calculation affects just the current segment to the next via point, or the entire route.
When navigating, Some operations result in the entire route being recalculated. Going off route is one. Pressing skip is another.
Sometimes only the segment to the next via point is recalculated. At the time of the test on the XT1, Closest Entry Point calculated only to the point of entry. The remainder of the route was left intact.
I did something similar with the. XT2 and it did on one occasion calculate to the end of the route. I didn't do any further tests to find out when and why because I thought that I knew why.
So..... ( all of this has a purpose, honest.... )
Sometimes When the XT1 and XT2 recalculates a route, they both change the nature of the route: It no longer follows the rules of going from route point to route point. It now follows the line that it has recalculated. That line may pass through all of the route points - or the XT2 may have moved them - but they are of no consequence. When you pass by them, they are not removed from the list of remaining points ( which you can determine by tapping skip to see which point is next, and then say no ). And if you wander off the route it will direct you back to its recalculated route at the closest point to your current position. Just like a track-trip *. If you by pass a route point, via or shaping, it doesn't care - the point just disappears from the map.
And when you go off route it chops the route into two parts at the closest point. It discards the part before the closest point, and calculates a new section from your current location to the new closest point. This is now the current route, and the green flag is planted at your current position.
This means that if you deviate from the route in a mathematically awkward way, so that the closest point is behind you, you end up in a never ending cycle. RUT behaviour. Yes indeed - track-trips display RUT behaviour.
I think that this is deliberate on Garmin's part. Garmin designed Basecamp to work with the Trip Planner app on the Zumo 590. People didn't use it because they couldn't be bothered to work out how to use it and in any case - it didn't work on mobile phones. So they used other software, which used different maps - which needed to be recalculated. Or some sort of fuzzy logic was applied to all route points which require them to be relocated slightly so that they worked But how much is 'slightly'. Well it is apparently more than the distance between the A6 and the M6 in N UK, because routes around there regularly jump onto the M6, and take the shaping points with them.
BUT there must be some routes where this doesn't apply. So which nones can we be certain that the route doesn't need altering ? Perhaps the ones created on the Zumo itself. And indeed, such routes never change their behaviour when recalculated. The navigation remains point-to-point. And they never get stuck in a RUT loop.
such routes have their mImported byte set to false - 0 and this can be altered manually; or by using @FrankB's SetTripToSaved utility, or by resaving the route. The latter is achieved by selecting the route, and then use the Spanner i on to copy it. Give it a slightly different name -I use the same name with @ in front so that I know it is the copied version. Run that route.
So the upshot of this essay is a question.
Does the same CEP behaviour happen on 'Saved' routes ?
Nb You could also use @FrankB's Trip Manager - but although that does an incredibly excellent job, it relies on the Zumo to caculate the route from scratch, and that wouldn't be a like for like test.
*Track-Trip is my term for a track that has been coverted to a trip (XT1) or to a route (as the XT2 now calls them.
Thank you again.
