Tread Changes Exisiting Routes - Shaping Point Issues

[lkraus]

You might be able to avoid a full reset by following the XT method:
Break the Connection with your Explore Account

I don't know if this has been tried with an XT2, but if it does not work, you can still perform a full reset.

[jfheath]

You can break the connection using the Reset Explore Databse option in the hidden "long press circular speedo" menu.
Turning off and deleteting the Tread app gets rid of it quite nicely.

But reinstalling - if you want any communication with the phone data - you have to have Tread installed.

With Drive, you could select whether or not to synch to the Explore database. With Tread, that option does not exist.
So you can either have Tread alter your routes if they come from external GPX files or if you don't want that, it seems that you sacrifice weather, traffic data and Group Riding.

I've just managed to get a route into it from BC without it altering the route. It has shifted the shaping points, but the route remains the same. But it has about 3 times as many shaping points than I normally use. I'm almost drawing the line for it.

I'm curious to see what it does if I miss a shaping point. Given that it seems to change tactics after ~2 U turn requests, and the XT gives up on shaping point if you miss the turning (after having pressed skip at some point ** - I wouldn't be at all surprised if it just gave up on a missed shaping point. But that is a guess. Not a fact. The AI robots are going to pick that up aren't they ?

** If you haven't yet seen this behaviour and have the time to spare This quicky video shows it. Or this 15min video which has pauses and full explanation of what is going on.

[Oop North John]

Double checked the phone's Explore app, and it's only synced to my Garmin watch.

Will load some routes with shaping points and see what happens!

Edit,

Created a route in Basecamp, converted it into a track, there, and then sent both to the XT2 by cable. Both loaded on the XT2 and showing in the Tread app on my phone. I deliberately put in two shaping points to go along a minor road that the "fastest" option ignores, even though it's quicker. On the XT2 both shaping points stayed in the correct location initially and the routing was logical. In the Tread app, one remained, and the other I couldn't see, which has made the route follow the faster roads error. Switched the XT2 off and closed the Tread app down. Some time later turned on the XT2 and the first shaping point has stayed in place, but the second has moved to another road. The Tread app has both shaping points in the same place as the XT2, but the routing is different.

The route in the opposite direction has the same faster routing problem, but behaves ok when the two points are via ones (using the Basecamp definition).

So I think that Tread doesn't handle shaping points logically.

Edit #2 - What I haven't looked at yet is if you have a via point, that you ask Basecamp to make it a shaping point, what happens then.

[smfollen]

JFHeath wrote:
Some of the route points had had their names altered. But every single one of them was a point that I had changed from the original route. Moved it to a slightly different location. Changed it to a Via. Changed it to a shaping. Only the ones that I had touched and all of the ones that I had touched lost the name that I gave them.

I wonder if this is why the behaviour appears to be so random ?

@jfheath I have finally had time to go back to pursue this - an excellent observation by the way.

I tested and experimented by importing into the XT various modified versions of a GPX file containing a simple test route.
The bottom line is that shaping points, but not via points, were renamed on import to the XT2 depending on the subclass information for the point in the gpx file.

All imports were done via sd card. There were no Waypoints, only Via and Shaping points.

I started by importing a GPX file into Basecamp which contained a route with bare minimum route point information, e.g.

Code: Select all

    </rtept>
    <rtept lat="41.7142" lon="-70.1543">
      <name>Orig   001  860 East West Dennis Road</name>
      <extensions>
        <trp:ShapingPoint />
      </extensions>
    </rtept>

First I had Basecamp calculate the route then exported without making any modifications. I found that Basecamp had added the default subclass to each of the route points

Code: Select all

<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>

On import to the XT2, there are no changes to such points.

Then I modified the route in Basecamp, adding an additional shaping point to the route (along the same path) and exported the modified route. The added point had a more complex Subclass

Code: Select all

<gpxx:Subclass>030044DEDF01312079030D1DCE0027A49F1D</gpxx:Subclass>

and on import to the XT2, that point, and only that point, had its name changed.

I next changed that point to a Via point in Basecamp and again imported to the XT2. The name was then not changed on import to the XT2.

So I went back to the shaping point version but manually edited the GPX file to change its subclass to the simple

Code: Select all

<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>

On import of that file to the XT2, the shaping point was not changed.

So, again, the bottom line is that apparently something in the Subclass of a shaping point tells the XT2 whether it can be modified on import.
I can't help but wonder if that has any implications for Tread's handling of shaping points. Experiment to follow ...

I also noticed that, when displaying the route as a list on the XT2, un-modified shaping points display their location, but points modified by the XT2 on import do not display their location.

NotRenamed.png (137.79 KiB) Viewed 2360 times

vs

Renamed.jpg (121.93 KiB) Viewed 2360 times

[jfheath]

This matches what @FrankB discovered with the XT when we were trying to get to grips with the weird routing behaviour.
I came at it from a different angle when I realised that MRA route rarely suffered the renaming issue - the use the 000fff type subclass.

But with the XT2 the points actually get replaced with new ones in. a new location.
Ive yet to test it with MRA

I've also noted that shaping points that were originally created as Waypoints, get separated from the waypoint. A new shaping point is created in a different location, and the original waypoint is left on the map as a small flag, but it does not form any part of the route.

[Oop North John]

I've also noted that shaping points that were originally created as Waypoints, get seaparated from the waypoint. A new shaping point is created in a different location, and the waypoint is left on the map, but not forming any part of the route.

I've only tried a limited test from Basecamp to the XT2 and so far using an already created waypoint (which is the the XT2) as a "shaping" point seemed to be ok. This was on a route where the faster routing shows the changes more easily.

Also, noticed that when I pressed on the blue dot icon the moved shaping points shown in @smfollen post above, then it shows the distances, but not the lat / long.

[FrankB]

@smfollen

This matches what @FrankB discovered with the XT when we were trying to get to grips with the weird routing behaviour.

True. In fact I created programs that were able to clear the subclasses in GPX files (Set it to '00ff') Both Java (works on Mac and Windows) and Delphi (Windows) versions. If you're interested let me know. I can send them. Source included.

[FrankB]

@smfollen

Have a look at this GitHub repository I have just created. https://github.com/FrankBijnen/ClearSub ... tag/V1.0.0

[smfollen]

Thank you @FrankB. Your program works well to clear the subclass and prevent the XT2 from renaming those shaping points. It certainly helps.

Unfortunately, the subclass fix does not prevent the Tread / Explore sync from ignoring shaping points and changing the route. I have an ongoing dialog with Garmin support on that issue. They indicated a short time ago that they are working to determine what the issue is. I will update here as I learn more.

[FrankB]

@smfollen

Good luck with Garmin support. You'll need it.