Java program to fix the routing behaviour of the XT.

[Peobody]

It always recalculates the whole route when you choose closest Entry and Skip.

But I haven't tested any of these behaviours with nobbled mImport bytes. Or recently, so I'm happy to be told that I need to check again.

I spent time this afternoon trying to create a test route in BaseCamp that would change upon recalc following a Skip during simulation. I was hoping to use it to test again after modifying its .trip file. Unfortunately I was unsuccessful at creating such a route so I hope you have one in your test kit that you can easily test.

[jfheath]

There are two ways that I have used to test which sections get recalculated.

One is to put Via points along a main road and then put a single shaping point in such a way that the route leaves the main road and returns to it later, but before the next via point. The route then zigzags along the main road to visit each shaping point.

Make sure map versions match and the use Basecamp to strip the shaping points and send the route to the Zumo. The Zumo should show the original zig-zag shape, even without the shaping points in place. If it doesn't then it has already recalculated and there is no point continuing the test.

So if it is still showing the zig zag, go out and ride. Pass the first Via point, on the magenta line, but stay on the main road when the magenta line turns off to visit the place where the first shaping point was positioned.

So the route recalculates to the next Via Point. So stop and look at the map. If it only calculates to the next Via, the rest if the route will still zigzag. If it recalculates the whole route it will be on the main road.

Actually writing this test out I have remembered the result ! I think what I said earlier was wrong.

This is a very quick test. As soon as you do not leave the main road for the first time, you get to know the answer.


The other method is similar but do not strip shaping points.

For this you plot routes in a similar zig zag way, but rather than using main roads, you use the fact that the Xt will head for main roads if it recalculates. So you want a route that Basecamp chooses as the fastest time, but which chops of a corner formed by main roads

So if you have a triangle of roads a b c. A to C is faster and the route that Basecamp will take. But A to B and B to C are main roads so that is the way that the XT will recalculate. Dont put route points at A B C . Put one before A and one after C . Check that ABC is the route that the. XT calculates but AC is the basecamp route.

Build a route ahead of that where you can deviate so that the XT recalculates. When you test, deviate from the route ahead of your route point before A. then see what happens to the map between A and C

Got to go.

[Peobody]

I just completed a zigzag test. It was made up of duplicate routes, except for name, with one have its .trip file modified.

The route was comprised of a four via points including start and end. In between the mid via points were non-alerting shaping points. Shaping points were stripped during transfer from BC to the XT. So... Via - Shaping - Via - Shaping - Via - Shaping - End

Both routes displayed the zigzag route when viewed on the map of the XT.

Both routes displayed the zigzag route once started with the first Via as the entry point.

Both routes lost the zigzag following a skip of the first point. This was the important result for me. It indicates that the bit mod of the .trip file does not prevent a recalc from recalculating to the end of the route.

I saw an anomaly that I had not seen before. In all tests, the XT never detected that I had reached the first Via point. This is a waypoint that I use as a starting point for most of my routes. Once I passed it, the XT maintained a dotted line from my position back to the closest point in the route, even after going off-route. There was never a prompt to recalculate. The banner stayed fixed displaying 'Arrive via point 1'. I don't know whether this behavior caused by the stripping of shaping points. Note that I was on foot during these tests so I was able to walk up, down, back, and forth around the area of that first Via without ever being able to get the XT to detect that I had visited it. I am clueless about what was going on here. Regardless, my concern about recalcs applying to the remainder of the route has been validated.

[Stu]

Stripping of shaping points always results in a route being destroyed when it recalculates no matter your start or entry point!

This is the same as using gpx 1.2 for export in Myrouteapp

There is nothing there to keep the route when it recalculates

I had the same happen to me on a route a few years ago when I came off route for fuel and it just recalculated me straight to the end point and with it being a round trip it just took me straight back to my hotel well tried to!

[jfheath]

Ah no. I don't think that it does prove your case @Peobody


If you skip a route point the XT always calculates the whole route 100% sure of that. Ditto if you select closest entry point but only 75% sure on that one. Every time I have checked it. Which isn't a proof.

The test I was talking about was for you to visit the start point and travel the main road and then do not follow the route to where the shaping point was before it was stripped out. The XT should recalculate to the next Via Point (because there are only via points left in the route). The question is, what then happens to other zig zags in the route ?

The dotted line yes I have seen that, and it didn't recognise the start. I have that event documented, but not reported.

What I think was that I started the route when in my Mum's drive. Its a big drive, so I was not on a navigable road. Perhaps that was the reason for the dotted line to the start.


Not recognising the start, I am not sure of, but it coincided with the dotted line.

Something that has been put to one side awaiting a little more enthusiasm to come my way. I haven't seen it since. My routes have always started with me right next to the road.

When my First XT arrived in April 2020 - it was supposed to arrive just before Easter, but it got lost, and instead went all the way up to Scotland before returning to Yorkshire. I wonder if that was the first warning sign ?
Anyway. Covid. Not allowed to go out, except for a walk. So I took it with me. It got the satellite fix, but it would not recognise me as walking on the route that it had plotted. I was on roads - country lanes, no footpath. But it just didn't work. There seems to be software inside that stops the current position from wandering around if it seems to be moving no more than a certain distance from the last reading. after a short delay. I wonder if it stops working at walking speeds because of this?

@Stu - the stripping of shaping points was used purely to be able to provide an easy test to determine whether or not the entire route is recalculated after going off route.

[Peobody]

the stripping of shaping points was used purely to be able to provide an easy test to determine whether or not the entire route is recalculated after going off route.

Worthy of note here is that the shaping points must be non-alerting.

Ah no. I don't think that it does prove your case @Peobody

I believe it does because the question I was looking to answer is whether modifying the .trip file stops a post-skip-recalc from affecting the remainder of the route. I now know that it does not.

If you skip a route point the XT always calculates the whole route 100% sure of that. Ditto if you select closest entry point but only 75% sure on that one. Every time I have checked it. Which isn't a proof.

One of my tests included using closest entry point. The route was not modified (ie: the zigzag remained). In this case, the start point was the closest point. The resulting route looked the same as when I selected the start point as the entry point.

What I think was that I started the route when in my Mum's drive. Its a big drive, so I was not on a navigable road. Perhaps that was the reason for the dotted line to the start.

My start point is about 50 yards down the road from the end of my driveway. It is a common start point for many of my routes. I believe that your suspicion about the XT not detecting a point when walking through it is spot on. That would explain my experience.

To be clear, my biggest issue with the XT is the recalc of the remainder of the route whenever a point is skipped. I have never had a problem with going off-route and then returning to the route as long as I didn't return at some point beyond an alerting point which then requires a skip of that point in order to be navigated forward.

[FrankB]

Now I'm going to say something that I don't think you will want to hear. @jfheath @Peobody

Consider the following procedure:

Create a route in Basecamp, with as many Via and Shaping points as you like.
Create a track from that route. Can be done in Basecamp.
Send them both to the XT, using whatever method you like. (Excluding Explore!)
Make the track visible on the map.
Force the route (Called a trip in the XT) to recalculate. Again there are a few options, but lets assume you set the trip first to 'Straight Lines' and then to 'Faster time'.

You then have 2 possibilities.
1) The recalculated route is the same as the track. Succes! You're all done. When you have to skip a point and the XT starts to recalculate you'll very likely get the result you wanted.
2) The recalculated route is not the same and it bothers you. Solution: Add more shaping points (in Basecamp) to force the recalculation to take the roads you want. And start all over again.

I agree it's a lot of work, and you end up with more shaping point than you like. It's something I do seldom, only if I want to be absolutely sure that my route works.

Of course there is also the option to create a trip from a track. That trip will remain the same. But then you will lose all the Via/Shaping points, AND it will certainly get you into a RUT once you deviate.

(You didn't want to hear that? right?)

[Peobody]

Now I'm going to say something that I don't think you will want to hear. @jfheath @Peobody
.
.
.
I agree it's a lot of work, and you end up with more shaping point than you like. It's something I do seldom, only if I want to be absolutely sure that my route works

You're right @FrankB, not about saying somethin they you don't think you want us to hear, but in explaining a way to insure that a recalc doesn't change the route. Doing so is indeed a big ask, an unreasonable one when routes are being distributed for a group ride. We know that different devices produce different results upon recalc, whether due to map differences or settings. Showing the track on the map is invaluable in showing any recalc change. When that happens, relying on a restart of the route to recover seems much easier the exerting a crazy amount of effort trying to prevent it.

===Rant on===
I don't believe that any imported route should ever be changed by the device. It should be treated like a read-only file. The best the device should offer is to guide us back to the route, whether to the closest entry point, or to a point selected from the remaining points in the route. It should then continue navigating along any remaining part the route.
===Rant off===

Back to reality.

[FrankB]

I totally agree.

Doing so is indeed a big ask, an unreasonable one when routes are being distributed for a group ride.

For a group ride with different types of satnav's, you could consider the trip from a track option.

whether to the closest entry point, or to a point selected from the remaining points in the route.

That's also my solution if I have to deviate from a route.

[danham]

I have been using the Frank B method to ensure what I create in BC is what I ride in the XT. It is a lot of work, but pays off. It also works most of the time. One recent exception: a route (and therefore its track) that contained two loops. Obviously the route "knows" which direction I should be traveling in any given segment, but the track does not, at least in terms of what I can see on the screen. Making the wrong guess, and therefore following that portion of the track "backwards" to get back on the route, creates complete chaos. Oh well, at least the scenery was nice.

-dan