proofresistant wrote: Wed Oct 01, 2025 2:35 pm
jfheath wrote: Wed Oct 01, 2025 7:19 am
Routes created on the Tread App get synch'd to the XT2 and that results in a 'variation.
Unfortunately, that's “only” half the story.
Synchronization alone isn't enough for the explanation.
I didn't intend to imply that the synch process did anything to the route or points. That is just data transfer. But before it synchs, Tread has the route. After it synchs the XT2 has the route ( or vice versa) so something happens before or after synch at ine end or the other. or both.
I have seen the Tread app move its own points and move the route onto different roads simply by adding another route point somewhere else. I don't recall seeing a route built on the XT2 screen doing that. So my suspicion is that the Tread App does something to a route before sending or after receiving.
I know that a route created on the XT2 remains intact / doesn't alter. It gets sent to the Tread App / Explore database ans still doesn't alter. Only if you make a change at the Tread App and it synchs back - blue rotating circle - does the XT2 route alter. So adding a full stop to the name of the route will result in the route on the XT2 being changed. So the issue is certainly at the Explore/Tread end of the synch process. Its difficult to isolate whether it is also at the XT2 end of the process.
I reported and evidenced this to Garmin once I had got past the front desk bouncers and passed on to the real technical team. I think that was the last time that I did anything with it. I decided that synching was not the way to get a route onto the XT2 and focused on making gpx files from Basecamp behave.
I need to study your excellent illustrations in more detail. It looks like the shaping points don't move but the route does.
My experiences suggests that the route is recalculated between via points and the shaping points are moved onto the altered route. They can be in significantly different locations. But you often have to zoom right in to see the change.
One theory that I have is that every route point goes through a fuzzy logic algorithm. A different one for vias and shaping. This is probably to address the significant number of issues that they must be getting from numpties who plot a route on Google maps and then expect it to work on the Zumo. So any point is looked up in a database . If it finds the location within say 128 or 256 metres (say) of the expected route between two via points, then the database name and location are substituted for the one in the database - which has the effect of moving the shaping point and the via point onto the faster route, and changing the name.
This sort of behaviour became evident on the 595 when changing a via point to a shaping point. But not vice versa.
I've noticed that this behaviour is not as obvious if a shaping point is placed much further away from a nearby faster route. Those points do not get altered. So the places that you really want a shaping point to work - eg to stop it going onto the nearby 'new' motorway when you really want it to stay on the old twisty main road running nearby - are exactly the same places where the shaping point is moved.
The only way to control this then is to specify the routing preference for each segment of track so that you prevent the route from using the motorway.
It is noticeable that Tread Doesn't export the route ghost points. It exports the route points, the calculation mode , and if the
mode is 'Adventurous' then the Adventurous Level is also sent. That is enough for the XT2 to reproduce the same route.
I have not investigated whether or not synchronisation then results in shaping points and routes being relocated - but the route does retain the adventure levels sent in the gpx file.
