Looking for the best start option to begin a planned route.

[jfheath]

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.

[proofresistant]

Am I correct in the observation that your CEP misbehaves only after the route has been recalculated ?

Yes, that's how it's described in my instructions
CEP only causes the observed behavior issue on my test route after recalculation.
I also think, and am almost certain, that CEP does not recalculate from the entry point. Presumably, only the route to the entry point is calculated.

Thus is a rather long reason for me asking it.

I'm still trying to understand it, give me some time.

So..... ( all of this has a purpose, honest.... )

I won't say much about that right now, firstly because I need to understand the detailed explanation properly first.
Secondly, I haven't seen any program that manipulates routes as much as the zumo XT2 or even the Tread app.

So the upshot of this essay is a question.
Does the same CEP behaviour happen on 'Saved' routes ?

Yes, copy or not, import flag true or false ('Saved') makes no difference. If CEP wants to work incorrectly, then it works incorrectly.

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.

I testet it also with the great TripManager, also with or with out post process, but in my CEP issue example this options doesn't matter.

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

I my live i name this trk2rt (Track 2 Route)

[smfollen]

This seems to be entirely consistent with what I am seeing in my case. If I import the route via gpx file, CEP behaves as expected, heading to the closest point on the magenta line - same behavior as previous XT1 testing.

If I save the route, or recalculate it, or generate a .trip file with Trip Manager, CEP behaves differently. It appears to head to the next via point, but I am not yet sure if that is exactly what it is doing.

Toggling the mImport bit does not affect results in any of these cases.

Still digging ....

[FrankB]

Couldn't resist testing this. Here is what I did:

Imported the GPX in BC. Kept only the route: CEP Tst RatSol BCshp Nok
Duplicated that route as 'Fixed'. Moved/deleted all shaping point placed at junctions, or requiring a Turn. Basically the shaping points that were already identified as problematic.
Created Waypoint 'Mettmann' to serve as point where to start the CEP from.
Attached the GPX in the zip.

Transfered Trips,Tracks and Waypoints to my XT (!) using TripManager.
Using the GPS simulator set my location to Mettmann
Started both routes with CEP.

Nok was indeed NOK

21740.png (845.75 KiB) Viewed 1796 times

Fixed was indeed fixed

19770.png (756.46 KiB) Viewed 1796 times

My conclusion is that CEP does not like shaping points that require a u-turn, nor does it like shaping points on junction. Let me share my theory on that.

A junction (or crossing) is a point where the gps coordinates are the same, but the road Id's can be different. If the Zumo, after recalculating, thinks that the road crossed is meant, it would require also a u-turn.
In the attached example 'Humans' mean 'Mettmanner strasse', the Zumo might think you mean 'Hasselbecker Strasse'.

junction.jpg (79.35 KiB) Viewed 1796 times

Now I fully understand that my results may not apply to the XT2, and that on the XT2 other parameters come in to play.
But to me, with my XT, this is just a variation of viewtopic.php?p=5801&hilit=glitch#p5801

I do agree:
- 'mImported' is not related.
- Recalculation can play a role, especially if the recalculating changed (slightly) the coordinates of routepoints. As was observed with Tread and the XT2

Frank

[smfollen]

I think @FrankB has nailed it. I found that my problem route did have a shaping point at an intersection and another just off the road. (I think this was due to a map update since the route was created, but it doesn't matter.)

Those points were miles past the section of the route which needed to be recalculated by CEP, so I am surprised they had an effect, but they did. I fixed the points and CEP behaved well for imported, saved and recalculated versions of the route.

Another thumbs up for Frank Thank you again.

... and another reason to carefully check, and re-check all route points at close zoom level ... and then do it again after a map update.

[FrankB]

@smfollen @proofresistant

Just to be clear. I do think that it is an error in CEP. To me there is no logical reason why a few 'misplaced shaping points' should skip so many others. But until now it is the only remedy that I have found to work.

What makes it worse that whenever you start a route, CEP is proposed as the default.(At least on the XT it is) Even if starting from the beginning would be perfectly logical and yields a good result.

Who is brave enough to report this to Garmin? I have lost confidence

Frank

[proofresistant]

...

I took the trouble to recreate such CEP malfunction over the course of several days.
The goal was to report the error to Garmin!
And that's what I did

Then it's definitely best to use CEP to beginning the trip.
Using the planned starting point wouldn't be good idea, because unfortunately the XT doesn't remember where it's already been and would therefore always want to navigate to the planned start first.

Then @FrankB
Can you give me a few key points for Garmin Support from a “developer” perspective. Then I could report these key points as additionally answer to Garmin support

[smfollen]

I agree it's a bug. I also agree that reporting it to Garmin would be a waste of time, but I may do it anyway at some point when I have nothing better to do.

The important thing is that we now know what's going on and how to avoid the issue.

@proofresistant pointed out that u-turns are a key. Thank goodness for pizza stops
@FrankB helped me understand that a point at an intersection can look like a u-turn to the XT2.
I suspect a point misplaced just off the road might also be a u-turn.

MisplacedPoint.png (23.29 KiB) Viewed 1781 times

[FrankB]

Then @FrankB
Can you give me a few key points for Garmin Support from a “developer” perspective. Then I could report these key points as additionally answer to Garmin support

Well... Let me put it this way. If there is anything I can do to help you when communicating with Garmin I'll be glad to. When you are talking about "developer perspective" I'm afraid there is nothing I can think of in relation to CEP. The test's I did can be done by anyone, you dont have to be a developer.

[proofresistant]

@smfollen en keep in mind

1000063 - Kopie.png (115.07 KiB) Viewed 1772 times

1058797 kopie.png (142.96 KiB) Viewed 1772 times

@FrankB I will forward these workaround images to Garmin Support if necessary.
Garmin Support already has the demo with the error and the description shared here, including the error but without the solution chapters.