Zumo User Forums

jfheath wrote: Fri Jan 12, 2024 3:03 pm Explore (and I assume Tread, since it uses the same database), does not have shaping points or Via Points as part of its route. It doesn't even have Waypoints as a part of the route.

I don' fully agree with that. If you look to my first screen copy above, it shows that the route in Tread (explore) has the 3 shaping points (small bluepoints) at the right place at the POI as on the original MRA route and that the road in Tread goes through them.
After recalculation on the XT2, 3 shaping points are still there (bluepoints shown in the second screen copy) and the road still goes through them in fact...BUT the position of the 3 shaping points on the map is altered during the recalc process! That is what I call "corrupted data". I can fully understand and accept that lots of points of the route which are not via or shaping points get wiped out in a recalc process but not that shaping points are moved...

jfheath wrote: Fri Jan 12, 2024 3:03 pm The same happens on a normal route - except on a normal route, it still has to pass through the Via and Shhaping points.

This provides at least a mean to have a certain control on the recalculated route and on the shape of the initial route, right? But, if the shaping points are moved in the recalc process, what control can we keep on the route? For me that is a fault in the software that corrupts the initial data.

jfheath wrote: Fri Jan 12, 2024 3:03 pm A route on the Explore / Tread database has lots of points to keep it in place, but they can get wiped out in so many different situations. Its up to you to find out how to prevent it from doing this.

I can understand and accept that. We know that it is the rule of the game and , as you said, it up to us to find out how to prevent it from doing this. But, as we also know, to be sure that the route will never be recalculated is difficult. Provided some control can remain if the route has always to pass through via and shaping points and if the integrity of those points is preserved, it is possible to play...

I have never seen shaping points be moved when placed in a live route. I have seen them be deleted from a live route, and have seen odd new route points appear. Also when editing a route on the XT screen - changing a via to a shaping - the point is renamed and moved so that it is located on the faster route between the two adjacent points. ( That sounds less like moving and more like deleting one and adding the other on the recalculated route)

Let me suggest a couple of possibilities. Remember - I don't have an XT2, just my own observations of how the software seems to have been modified. Changes - that I first saw in the 595, also appear in the XT. It seems possible that they will also be present in the XT2.

1. Create a route where this has previously happened - but this time use genuine Garmin saved Waypoints. Use Basecamp for this and create the points with the waypoint flag tool. Give them a name with a sequence number - eg 01 Here, 02 There, 03 Somewhere - These have to be created first, and the route can then be built using them. In basecamp, you select all of the waypoints right click and select create a route using selected waypoints. You cannot do this with Explore, probably not with Tread. Although it will create Waypoints, they cannot be built into a route (not in Explore). Waypoints should appear in the 'Favourites' App, (or 'Saved' App in USA). The Wayponts can then be set as Via or Shaping in Basecamp. See what happens then when you navigate that route.

2. Using the same Favourites, build the same route just using the XT screen. Keep them all as Via Points. (The XT moves the point (even Waypoints) when it changes them to shaping.) Try that route. The Zumo will not alter the name of points created as Waypoints)

3. Load one of the offending routes and say Go. Back out, load Route Planner, select active route and save it with a new name. Stop the original route. Load the newly saved route into the Zumo and say Go. There will be a new start point - where you were when you did this. Select the original start point as the Next Destination. Try that route.

There are some aspects of what you describe which are similar to things that I have observed when testing for RUT behaviour. It is triggered when the zumo is forced to recalculate the route eg by pressing skip. But it has never happened with 'Saved' routes.

What you describe is not RUT behaviour, but there are other things that I have noticed when the Zumo has recalculated an imported route, which are not inconsistent with what you describe. Two of the above suggestions are ways where RUT behaviour does not occur.

Thanks for your time and your suggestions.
Good suggestion indeed: since my shaping points were created by « a non Garmin » software it could well be that they don’t have all the necessary identification characteristics.
I will further investigate on this in a few days…

jfheath wrote: Fri Jan 12, 2024 3:03 pm
Can I make a disk drive look like an XT2, so that I can load up the Tread App. ? Is it Possible ?

A bluetooth pairing must be done between the Tread app and the zumo XT2 for them to synchronise. I don't know how that could be achieved trough a virtual GPS and what would be the GUI for a virtual GPS... It's seems difficult for me but i'm not an IT guy... I suppose that when you say "I can load up the Tread App", you mean in connection with the XT2?

Javelin16 wrote: Sat Jan 13, 2024 7:39 am Good suggestion indeed: since my shaping points were created by « a non Garmin » software it could well be that they don’t have all the necessary identification characteristics.
I will further investigate on this in a few days…

First results from this. The steps I followed were as recommended and described below:
1. I create 5 WPs in basecamp, corresponding to the previous one. I rename the WP with a numeric suffix corresponding to the order of the WPs in the projected roal. I create in BC a route through the five WPs.
2. I define the 3 intermediate WPs as shaping points using the "won't alert" option in BC. Copy of the screens in BC is given in the pdf file hereafter:
The corresponding gpx file with the route and the WPs:
3. This file is copied in the GPX folder of the internal memory of the XT2 (using Windows explorer).
4. The route is imported on the XT2. Corresponding route in the db explore of the XT2 is as follows immediately after import:
5. A sync is done automatically with the Tread app. The route from the explore db in Tread is then as follows:
6.After the sync the route on the XT2:
Similar results as for the route generated in MRA. Just after import on the XT2, perfect results (3 WPs, 3 shaping points at the correct location, good route). After sync in Tread, alteration of the basic data ( 1 WP lost,2 shaping points location changed, 1 lost and consequently, route modified). This sync alters also the data on the XT2 (3 WPs ok, 3 shaping points moved, route modified), all this without using the route in Tread and thus simply from the sync between the XT2 and Tread.

Data transferred to Garmin support. To be able to request an eventual investigation from their engineering team, Garmin requested only Garmin data, which I can understand.

This is all so disappointing from Garmin!

I would like to see this same route imported to an actual Tread device to see if the errors would reoccur.

Thanks for posting that. Interesting.

A coluple of Points of information. I can only comment from using the Explore App, but since they use the same data, I suspect that what I'm about to say is relevant.

1. when you create a route /track on the Explore site, it will be a series of straight lines. When it is received by the Zumo, it is converted into a route that follows roads. I noticed that the shape was broadly similar once converted, and it seemed to pass through the places where my straight lines route changed direction - the corners.

Pics and comments here P61 and P62
app.php/ZXT-P61

2. Waypoints are saved places on the map. We are used to Wapoints being included as part of a route in Basecamp. They are not, in Explore. They just sit there on the map, looking pretty.

This is because in Basecamp, when you create a waypoint, the definition is placed in the gpx file as a separate group of statements.
When the waypoint is put into a route in Basecamp, the coordinates name and other details are copied into the route instructions, and it is set as either a via or a shaping point So the identical point appears twice in the gpx file. Once to declare it as a Waypoint, one to declare it as a point in the route. In Explore it is not declared as a point in a route only as a Waypoint.

So I guess that in Tread, which from what I have read, accesses the Explore database, that the route is being processed as described in section 1 of this answer. Making the route plotted as straight lines, fit the roads on the map.
The waypoints are probably undergoing lookup checks to see what is near the coordinates. Maybe being moved 'Oh he meant Sainsbury's car park' sort of thing.

I think that you may be expecting the Waypoint to be part of the route. But the last time I checked, the Waypoints and the route / track are two completely separate items. That is consistent with Garmin's definition of a Waypoint.

Let me know if that makes sense - or if it doesn't. I have never set eyes on an XT 2 or tread. I may be talking boll-twoddle.


If I may be permitted to add another thought to this monologue.....

I have suspected that Garmin in being by market forces. People are using all kinds of Apps to create routes - partly perhaps because Basecamp is too clever by half for many of its users - designed to use with all kinds of navigation devices, and employ a proper relational database structure.

So instead of accurate point placement being key to a good route, users are turning to hand held devices for their route planning. Big fingers, small screen, sunlight glare, different map products are not consistent with placing points accurately on a map.
So perhaps a 'fuzzy logic' is being employed so that the zumo has a chance of getting a route that actually follows the road that it thinks would be the user' intention.

Perhaps Zumo thinks - "This isn't on a road, where is the nearest road consistent with being between the next and previous point ? Here. That will do. "

or

"This isn't a proper place, what is this doing here. Maybe he meant 'Sainsbury' thats just over there."

The first thought, I think that I have seen in action. Via point, via point, via point. All placed accurately in roads in the Zumo itself. The middle via is placed deliberately to keep the route off the main dual carriageway. Use the Zumo trip planner to change that to a shaping point, and the point is moved and renamed to correspond with its new position. In this case it moves to the start of the dual carriageway that I was wanting to avoid. From other observations, it seems to move it onto the faster route between the two adjacent via points.

The second thought maybe. The behaviour is more of a supposition based on the fact that route points set and named in Basecamp are altered when they appear in the Zumo. it is as if the coordinates are being used to fuzzy-match a known location. That location is then used in the route. This behaviour seemed to start when I got my 595, when the Foursquare database was introduced. Just an observation, which may or may not be related. Changed point names often have the county name added to the location - eg WYK for West Yorkshire. I didn't know that we had 3 letter county codes until I saw this!

jfheath wrote: Sat Jan 20, 2024 12:43 am So I guess that in Tread, which from what I have read, accesses the Explore database, that the route is being processed as described in section 1 of this answer. Making the route plotted as straight lines, fit the roads on the map.
The waypoints are probably undergoing lookup checks to see what is near the coordinates. Maybe being moved 'Oh he meant Sainsbury's car park' sort of thing.

In fact, the waypoints are in the explore DB of Tread and they are exactly the same as in Basecamp (same long and lat).
What is altered after the sync with tread are the shaping points of the route.

A closer look at the shaping points of the road reveals this:

1. Just after importing the route on the XT2, the shaping points are identical to the shaping points in BC (same name, same long and lat coordinates).
- shaping points in BC: - shaping points just after import on the XT2: 2. For the route in explore db of Tread, there are still 3 shaping points but they are altered: The name and the coordinates are changed. What is strange is that now shaping point 2 and 3 are at the exact same location. I think the suggestion of jfheat is close: it looks like the shaping points are relocated on the fastest road close to their original location! By the way, in the explore db of Tread, the waypoints are not altered (separated entities as always in the Garmin logic).

3. Now, here are the shaping points on the XT2 after the sync with Tread: Now, as in explore, the name of the shaping points are changed and the coordinates are no more associated with their name. What is strange is that the shaping points differ from the shaping points in the explore db of Tread (again 3 distinct shaping points with a new location for the first shaping point). As suggested, the logic seems very fuzzy. But, I don't like to follow "fuzzy" routes when riding. I was trying to give a chance for keeping Tread active but it seems hopeless. I'm afraid that your suggestion of a development of a marketing app, with no more rigorous logic and principles, like always keeping via points and shaping points, to please phone screens lovers is delivered by Garmin. Fine if other people like that. But having access to some new interesting properties like weather or traffic infos should not be at the price of "fuzzy" routes that a lot of drivers will hate.
Up to know, the link with BC is still effective, even if each time the XT2 is connected an error message is shown in BC telling that the XT2 is not officially supported in BC. Hopefully, the effectiveness of the link will be kept by Garmin in the future, which I doubt personnally.

It becomes a difficult game with the Garmin new logic: the content of the explore db in Tread is not consistent with the initial content of the db of the XT2 after the sync of the imported XT2 route. Then after the subsequent sync of the XT2 db with the explore db of Tread, the content of the synced db are also not the same! To complicate for me anyway. I will delete the tread app from my phone...

AugustFalcon wrote: Fri Jan 19, 2024 11:14 pm I would like to see this same route imported to an actual Tread device to see if the errors would reoccur.

Here it is. The same route, but first imported in Tread and subsequently, available on the XT2 after sync and recalculation of the route...
1. gpx file of the route imported in Tread. The waypoints are again ok (in explore; one waypoint missing on the map in Tread). The shaping points are less alterated but the name are lost, the coordinates are not the same as in BC (see above for BC). Again, it seems that the shaping points are relocated on fastest road nearby (to a lesser extend for the second shaping point). The route is modified by Tread since the shaping points are changed.
2. The route on the XT2. When the route in explore on the XT2 is open, error message as already shown in several posts on the forum: If the option recalculate is chosen, the route on the XT2 similar to the route in Tread but the shaping points are again modified (see the second shaping point hereafter): Again, for me very strange logic difficult to understand. I cannot rely on that.

Thanks @javelin16 but that appears to be an import from the Tread App to an XT2. I'm interested in seeing the results of the route being imported from the Tread App to one of the devices sold by Garmin under the Tread name. If I knew anyone who had such a device I would enlist them.

Is this a case of not quite making a square peg (XT2) fit into the round hole of the Tread App designed for the Tread devices? Or, if both the XT2 and the Tread devices fail in the same way then it is just massive incompetence of the Garmin software team and it's management. Maybe the result of siloing inside Garmin?