@smfollen ,
@Oop North John ,
@SEllis ,
@lkraus ,
@proofresistant ,
@Regain
And anyone else looking in that has personal experience of this behaviour...
I've just about got through the initial Triage section of product support where a number of different people have been looking at my initial contact and have been making sure that they have all of the correct information. I must say that response has been pretty fast and helpful after the initial slow response.
The first congratulated me on the quality and clarity of the evidence that I sent to describe the problem. Follow ups wanted more information and asked various questions and comments.
Like - cannot comment on use of third party software to create GPX files.
- To which I was able to respond that I appreciated that, but the issue also exists with gpx files exported from the Tread App itself - which is why I included it in my first email.
Had I tried it with any different phone ?
- I got the same results on my Samsung Galaxy / Android as I obtained on my Apple Ipad.
Is there any reason I was using GPX files, rather than synching from the tread app ?
- Yes - because I ride with other Zumo owners who don't have the Tread app.
- I have helped motorcycle tour operators who send their files to customers as GPX files.
- The Tread app is so difficult to use on the XT2 itself and on the small screen of the phone.
- I like to have a track of the route to display as well as the route itself, so that if/when the Zumo does something odd, I still have a line on the map that I can trust.
And they wanted a video and a log file created by the Tread app to send them.
A follow up email from them asked for the details - the phone models and iOS versions of all of the phones that I have tested.
So eg Samsung Galaxy A41 / Android 12 . Ipad Air v 3 / iOS 18.0.1
So If you have observed this issue for yourself, I wonder if you would mind sharing the phone make/model and software version please. I'll forward it on to the product support - with no name attached. PM me if you prefer. If not, its OK. Just trying to add a bit of - It's not just me - to the evidence.
--------------------------------------------------
So far I have discovered that as long as the Tread app is swiped off the screen, it does not seem to be able to synch with the XT2. Tread can still be installed. In the case of the Android, it will continue to pass on data info regarding weather, traffic, road closures, messages and alerts from your phone. It doesn't seem to be able to synch. The XT2 says that it is synching, and it will say that it last synched at (2 minutes ago) - but it fails to do so - the route doesn't change.
In other words your routes from Basecamp, MRA etc are safe from modification until you load the Tread App onto the active Window on your phone.
The same is True of the iPad - but if I swipe that off the screen, Tread is not connected at all - so Traffic, weather, phone alerts do not come through. But the ipad is not an iPhone. The iphone may work more like the Android - I don't know. But either way - making sure that Tread is swiped up off the screen seems to prevent the Tread App from changing the route.
----------------------------------------------
In writing back to Tech Support - I made a final comment of a behaviour which is possibly related:
You can see similar behaviour just using the Tread App itself. Eg It is easier to make a route consisting of only Stops/Vias. and then change most of them to Shaping Points. When you change the Vias to Shaping, the route will often jump onto the nearest fast road and take the location of the Shaping Point with it.
Oddly, when you do this, you get a different result if you make the changes :
a) working against the direction of travel of the route
b) working in the direction of travel.
It seems as though when the Tread App receives a new or changed route it is at liberty to ignore the shaping points and plot its own route between the stops or vias. Then create new shaping points to suit.
Almost as if the algorithm is treating shaping points with no more importance than the <gpxx:rpt > route point extensions when a route has to be recalculated.
I've considered that last thought before on a number of occasions. And as I wrote it another thought struck me...
In the early days of Zumo route planning, we had only Via Points. The term shaping point seemed (to me) to be used to refer to the points that the Zumo used to plot the route. What I now think of as ghost points. Its hard to go back and remember how it was with (say) the Zumo 550 and Mapsource. Mapsource never mentions shaping points - yet I had heard the term. Maybe I applied it to the wrong thing.
What if all of those <gpxx:rpt > and the Shaping Points are being treated all the same. Eg if the algorithm is designed to spot the Via Points and plot a route between those, and then replace the shaping point in the same position in the gpx file as the original ? So if there was a shaping point on the 100th line of the original segment in the gpx file, the 100th line of the new route is then made into a shaping point ?
I could imaging one of my student programmers doing something like that in order to make the coding easier. Especially if the name didn't matter and all that had to happen was that the name Shaping Point was used. Focusing on a solution to the task set rather than on whether it solves the original problem. As I understand it, programmers are given specific tasks to complete writing procedures, objects or whatever terms they use these days. They rarely get the whole picture.
I feel a test coming on. I do love a puzzle !!
No - that last check of the relative positions of shaping points in the original and the changed route did not bear any fruit.
