Tread Changes Exisiting Routes - Shaping Point Issues

[proofresistant]

It's true that the roads are closed.
But neither the XT2 nor my Tyre Planning Tool nor BaseCamp have a problem with this.
This should not be a problem either, and if I want to be asked whether these should be bypassed. As I've written before, I have reasons for wanting to ride there and I don't want Garmin to tell me whether it makes sense or not.
Then both XT2 and the Tread app developers should know that you might want to plan for the future and allow temporary route closures.

Then to the other problems.
A turn at a cross roads was not a cross roads - it was one road passing over another.
I can't find that. But if that's the case, then it should be included in the calculation and a suitable curve should be found.
A turn onto a main road was not available. A turn off the main road was available, but not onto it, I can't find that either, but here, too, a suitable alternative route should be found.
Due to road works I should not be able to plan? Tread app, is your developer serious?

Attached are pictures that show that planning is not the problem.
I can also recalculate over all with other route algorithms without any problems.

Ergo, the route is not the problem,
If the Tread app is causing problems.

One more thing about the accuracy of the points.
As we already know, BC is no longer officially XT2 compatible.
But no matter, you have different map sources, that is the general standard. Because of different maps, the points are sometimes shifted by a few meters and that has to work.

I have now also driven through all the points again with Streetview, and I don't see the problems as serious as you have discovered.
I could live quite well with an alternative calculation of poorly placed points

[jfheath]

OK - now I am confused. And confounded.

What I 'discovered yesterday - some of it I can no longer reproduce. So somehow I have introduced some errors of my own.

I'll go back and correct my previous post. I wont cross out what I said, because they were genuine observations. Some mistaken.
Last night I installed 2025.2 maps - but I am using 2025.1 today. And I am not seeing the same things that I saw yesterday on 2025.1 maps.

Oh tish. I have just looked at my route preferences. I never bother becasue I never change them. Everything is always turned off. Except I have all of the avoidances except four turned on.
How did that happen. I didn't do it. I would have noticed because when your change the avoidances, every single route gets recalculated.

Doh. Idiot Heath. What a stupid error.

There will now be a half hour delay while all of my routes get altered.

OK - scrub everything that came before. The only point that I can see that is badly out of place is the end point - which needs to be moved to the right hand side of the road. to stop it from doubling back on itself. Others are still slightly off - but being shaping points it makes little difference. But it is the first thing that I look at with unknown routing issues.

I know that there is some adjustment made to every single route point when it comes into any Zumo from the 595. They get moved onto roads. One thought that I have is that this behaviour might be a little over-zealous with the XT2 - moving my shaping points onto a nearby motorway. So getting them spot on would eliminate that concern. That's all.

The coned off road might still be an issue for the XT2 routing if Traffic is turned on. That info is not stored in the maps, it is obtained via the phone and the Tread app - and it is not 100% reliable- eg around here I have seen roads shown as a full road closure on the zumos when in fact the road is only closed overnight.

There is nothing you can do about no access to motor vehicles. If the satnav believes that is the case, then it is regarded as not navigable and will route around it. That is what they do.
Having said that - BC is now happy to route down that road now I have the avoidances turned off !!

Sorry about that mess-up @proofresistant .

Back to the drawing board.

[jfheath]

New Attempt.

I Installed maps 2025.2 last night - Basecamp and XT2.

Reloaded a fresh copy of your route r_NL_Rat_BC_ShpPts Recalculated. All OK and followed your track perfectly.
Modified all route points that were off route - including the last point. (I didn't want that to be a niggle later on).

Created two GPX files - one of the route, one of the track. Put them on the SC card of the XT2.
Disabled Bluetooth on my phone - so synch was not possible. Route and Track imported without any problems.
Route did not recalculate - it took the route plotted with the gpxx route point extensions without any fuss.
Plotted perfectly - magenta route on top of the slightly wider blue track.
The shaping points were in their original position - comparing zoomed in section of the XT2 map with zoomed in section of the Basecamp map.

THe images below are good quality screen shots. Click them to get a larger view.

Before Synch - Perfect Route from Basecamp (rotated on screen to get a better view)
(This is two separate screen shots from my phone, spliced together.)

Proof XT2 Map.png (687.56 KiB) Viewed 1153 times

When I allowed it to Synch with the phone - the route was broadly similar, but there were places where for whatever reason, it had chosen a different route from the one plotted. THis route eventually snynched back to the XT2 - so that route was then altered to match the one on the phone (below).

After Synch - the route viewed on the phone (rotated screenshot to match previous image).

Synched Route to Phone.jpg (146.4 KiB) Viewed 1153 times

With the original unsynched route, I tried all 4 adventurous routing options, and although the route changed - especially where there were fewer shaping points, the shaping points themsleves never moved, and the route was calculated between the shaping points - passing through every one in their (fixed) position.

From this It seems that the only alteration to the shaping points takes place when the gpx route on the SD card is sent to the Tread app. This is not a Basecamp thing. It is what I noticed with my test routes and it happens with GPX file that are exported from the Tread App as well.

John

[jfheath]

Sending the GPX file to the Tread App

I made a duplicate track and route and anmed them slightly differently. The two gpx files were sent by email from my PC to my phone. These were then 'opened' on the phone's mail program which prompted a number of Apps which could cope with the GPX attachements. I selected Tread, and that opened up the Tread app, and invited me to cretae a new collection or choose an existing one.

The resulting route came through very quickly, but it seems to have stripped out all information about the roads to be followed. The shaping points are as planned in Basecamp - as far as I can tell - and tthe map shows each point joined to the next with a dotted straight line - which is what the Tread App does while it is working out a route. But nothing was happening to this route - it stayed like this for a long time.

Map showing the GPX file after import to the Tread App. Image is two screen shots pasted together. Click for a clearer view.
The blue line is a track cretaed in BAsecamp from the plotted route.

JFH Imported by Email.jpg (225.5 KiB) Viewed 1138 times

When this was allowed to synch with the XT2, the XT2 could not calculate the route.
When I tried to set the routing preference for the route on the Tread App It displays the message "Shaping Point must be palced close to a road or trail".


I know that I have seen this work before. I cannot work out what is happening in this example.

[proofresistant]

John , you have put a lot of effort into understanding what is happening with the XT2 and the Tread app.

As described at the beginning with the example, the XT2 works with the route (more or less) clearly; the Tread app does not; and using the Tread app to send this route wirelessly to the Garmin does not work either.

I deactivate all avoidances in the XT2. All topic points are always deactivated, I have just checked this in the Tread app and also in the XT2.
Here it is again the topic that the profiles are very much missed in XT2. In the past, you could quickly switch between different profiles with older devices.
And about the current traffic information. With the exception of me, I use the motorcycle as a normal means of transport or i need it for direct go to and from destinations.
Because when I'm touring, current traffic information makes little sense in my eyes anyway. In my experience, no system in the world knows whether or not I can ride my motorcycle when the roads are blocked. Very, very often roads are disturbed but I can still ride my motorcycle without any problems.
Then, as you mentioned, traffic information is often not up to date. Conclusion: when I'm touring, and even more so when I'm planning, these are always deactivated. And if I have a lot of time just before the trip, I check online beforehand to see whether sections should be bypassed due to the current situation.

Then to the destination. The point is not really important to me, it is already my neighborhood. But the point is not a mistake and what makes the route planning so questionable is actually almost correct. Explanation, right there is the entrance of a gas station and right there for the intersection a left turn lane is allowed. But it has an exception, you can also turn left to the gas station, but Garmin probably doesn't know that. So Garmin first turns right, then turns around and drives back, only to arrive on the right-hand side. I can live with that if at least the route is calculated

The fact that the side of the road will play such an important role in cities in the future will present us with major planning challenges, especially if routes are sometimes driven the other way round.
I had already seen something similar because I didn't want to go west but east around a city. So I set a point on an eastern road and wondered why the route was making such arcs/circles. The reason was that there was a small green strip separating the lanes.

I've had the message “Shaping Point must be palced close to a road or trail” a few times in the past without a solution, I couldn't explain it. What sometimes helped in the Tread app was to make it a VIA point, but I don't really want that.

Anyway, this test route confirms that the Tread app shifts the sharpening points and makes my planning unusable. The Tread app is also capable of ensuring that routes imported with the Tread app cannot be used/calculated at all in the XT2.

And one more hint.
The route is for testing.
I will never, ever use the XT2 routing as it is.
Even if all XT2 tread app workarounds are known. When it really comes to planning routes, I won't spend hours in advance trying to please the Garmin. No, I'm not going to put myself through that, the XT2 will end up as trash in the garbage can first.

I am currently thinking about a good workflow for the future:
First planning with a practical route planner (which can also include satellite or terrain views), then checking in BaseCamp if necessary, then checking in XT2, then checking in the Tread app, then checking again in XT2, then correcting, then the whole work process again [...].
Honestly? Find the mistake why i even think about such procedures


PS
I still don't appreciate Garmin being so stubborn with different maps / versions. GPXs simply come from different sources and Garmin should handle this by now and work with it in a more error-tolerant way.

[jfheath]

I have two possible solutions to the route / shaping point issue.

Both have been subjected to some basic testing. Both need more testing on the road.

Disable Tread

Put the route onto the SD card as a GPX file. Import it in the normal way. Do not let it synchronise with the Tread App.



Use Tread

Get the gpx file on your phone - eg by email. Open it with Tread. Let it synchronise.
Route may be calculated by the XT2, but it passes through the original route points. The result is RUT proof.

This works with any gpx route file, including from Basecamp. Route points must be accurately placed.

[proofresistant]

Hi jfheath,

I think the problem is confusing us more and more as time goes on

I have two possible solutions to the route / shaping point issue.

Both have been subjected to some basic testing. Both need more testing on the road.

Disable Tread

Put the route onto the SD card as a GPX file. Import it in the normal way. Do not let it synchronise with the Tread App.

That's exactly how it works best.
Unfortunately, this is no wireless transfer and the constant booting of the XT2 is also a pain.

Use Tread

Get the gpx file on your phone - eg by email. Open it with Tread. Let it synchronise.
Route may be calculated by the XT2, but it passes through the original route points. The result is RUT proof.

This works with any gpx route file, including from Basecamp. Route points must be accurately placed.

And exactly this workaround was my original problem, because my first routes created by BC could not be edited at all with the XT2 when I imported them via Tread App

[jfheath]

And exactly this workaround was my original problem, because my first routes created by BC could not be edited at all with the XT2 when I imported them via Tread App

Yes - I know. I spent a lot of time on your route - but there was something odd about the route and/or the maps. I got exactly the issue that you described, but when I used your route / track as a template and plotted it from scratch - those problems disappeared - but the route would not redraw on the tread app after synch. I never got to the bottom of that - but that was not the problem that I was trying to address. It's probably something to come back to when my understanding of what is going on is better. For example - I have come across that dotted straight line route a couple of times since and managed to get a proper route from it. I don't know how. I think it was an excessive time delay. I also feel that on some occasions, I am not looking at a live map which will change - but I am looking at a picture of the last time it was drawn - because quite frequently, when I back out to the menu and then go back in - the map has changed and the route has been drawn.

I have had a couple of other examples where the issues could be attributed to mapping differences or route point placement.

I still have to encounter any problems with this method when nothing else that is odd is going on. But the question marks in my post above are there for a reason. Just 'cos I can find other things to blame when it does go wrong and it goes right otherwise - that doesn't make it perfect. I've not tested enough for that.

I've just uploaded the new Tread App. When I first presented my evidence to Product support - I had the latest version of Tread. Odd - because that was the 22 Oct - the day the new version says that it was released ! I also checked a few days later. My version was still the current one. The PlayStore entry says it was released 22 Oct - but I know it wasn't available to download on that date.

I wonder why product support didn't ask me to try with the latest version.

[Oop North John]

Points in the route still move if you change them from a via to a shaping point in Tread 2.09.52. I'v fed this back by the in-app reporting tool, which came in the previous version.

[jfheath]

Points in the route still move if you change them from a via to a shaping point in Tread 2.09.52. I'v fed this back by the in-app reporting tool, which came in the previous version.

Thanks John. I've just installed 2.09.52 (6 Nov 2024). First thing I did was notice that now they have stopped using the term 'Favourites' when they mean 'Waypoints', they have now re-purposed it to mean what they had previously called 'List'.

So now what used to be called Favourites is now in what used to be called List but is now called Favourites.

Yeah, Ok. I can cope with that. I wonder if the programmers can.

The next thing I did was to clear out all of my old List of Routes, tracks, waypoints, collections. And imported my test route which uses shaping points to keep the route on the A6, but which after synch with the Tread App, moved it onto the M6.

So that particular issue has not been fixed. But the good news is that it gets it wrong much faster than it did before.