Introducing TripManager

[FrankB]

First of all, a big thank you for the Tripmanager.

You're welcome. Hope you enjoy TripManager and keep on using it.

If GPX routes are sent to the XT2 as a trip via "Transfer to device", why do the individual shaping points have the attribute "Shaping point" instead of "Shaping point XT2"

Suppose you import a GPX "the normal way", via Basecamp for example that is what Shaping point are called. "Shaping point XT(2)" are typically points when a trip is modified on the XT(2) by the Tread app, or as we recently discovered via the "Shape route" function of the XT

You can "clean up" the route with "Post process"

That function does not use map information at all. In stead it compares the Coordinates of the shaping point and the next point of the route. It turns out that with a correctly placed shaping point they are always the same. Regardless of the map used. But the route needs to be calculated by Basecamp, or Mapsource, but that is rarely used nowadays.
TripManager has margin of 0.5 meters. That means any shaping point further away will get relocated.

I would like to transfer routes to the Garmin as trips so that the XT2 no longer calculates them, even when importing them. It simply takes too many minutes.

There are 2 reasons why TripManager does not work that way.
1) Simply. I can't. The trip format has not been decoded enough, there are a lot of unknown fields, it would require in depth knowledge of the maps, AND calculation of routes.
2) Even if we/I could, it would not be desired. Suppose the route/trip would have to be recalculated, the XT(2) would do it with it's own calculation method. And you would get a different route at the first deviation. Better to have to route calculated on import and check the result. (Of course anyone may have a different view)

Frank

[Peobody]

Better to have to route calculated on import and check the result. (Of course anyone may have a different view)

I am an anyone who has a "different view", sort of. I struggle with creating a route in Basecamp that, when calculated by my XT, does not result in route deviations from what Basecamp produced. It is good to know that will happen, which TripManager provides, but in doing so you end up with a trip file that contains the deviations. To fix them you must then go back to Basecamp to try to fix the route, transfer it with TripManager perhaps still resulting in deviations, rinse, repeat. It can be a frustrating and time consuming endeavor. The conundrum then is whether to use TripManager and fix the route until there are no deviations, or not use TripManager and just place the route on the device and let it use the Basecamp ghost points to create the route, and then fix RUT. This is with the knowledge that a recalculation may change the route, which may then warrant a route restart to get the original one back. All of that said, it is irrelevant if you are adept at producing a route in Basecamp that won't be modified by a recalculation. If I could do it, I would be all-in on TripManager.

Based on what I have read about the XT2 with Tread, what I have just described does not apply. My understanding is that Tread does not maintain the Basecamp ghost points.

[FrankB]

@Peobody
I couldn't agree more. Unfortunately I haven't found that all in one solution. For me the "recalculate after transfer" works best, or should I say "has the least problems".

if you are adept at producing a route in Basecamp that won't be modified by a recalculation.

Actually you can. Transfer a track to the XT, convert to a trip. That trip will give you directions and will not change. The downside is that you loose all your Via and Shaping points, AND the XT will not calculate a new route if you have to deviate, because of a road block. I think the phrase "Choose your poison" applies here.

[Peobody]

I think the phrase "Choose your poison" applies here.

That is my point. Different approaches have different benefits and drawbacks. How the route will be used can also affect which approach is best. For instance, the next time I create a route for myself I likely won't use TripManager in such a way that it creates the trip file. However, the next time I create a route for a group ride I will definitely utilize TripManager so that it creates the trip file, correcting the route in Basecamp as often as needed to get a transfer without deviations. Only then will I share it. I think that is the best option for minimizing route differences on different devices.

Actually you can. Transfer a track to the XT, convert to a trip. That trip will give you directions and will not change.

I am aware of this but have never done it. I should though. It could be suitable for local ride routes that don't include a lunch destination, but not for my touring trip routes and group ride routes. Via points are important in those.

[jfheath]

Actually you can. Transfer a track to the XT, convert to a trip. That trip will give you directions and will not change. The downside is that you loose all your Via and Shaping points, AND the XT will not calculate a new route if you have to deviate, because of a road block. I think the phrase "Choose your poison" applies here.

Just point of info. Tracks that have been converted to trips (track-trips) on the XT1 or converted to Routes on the XT2 WILL recalculate if you wander away from the magenta line. Eg if you have to avoid a road closure or you need to find a different route for other reasons.

What it does in these circumstances is to calculate a new section of route from where you are now to the closest point on the untraveled original route

This behaviour is dynamic. If you ignore another instruction - because its new suggestion hasn't got past the obstruction that you are trying to avoid , it tries again with a different suggestion. But it never tries to calculate a route to the end. It always calculates a route to intersect the current route up ahead. (Note 1).

It is an extremely useful tool, but it is not foolproof. If you deviate from the route in such a way that the route ahead is behind you eg by leaving the route at right angles - so it cannot see the route ahead, it will want you to turn around. As soon as you ignore that instruction, it plots a new section of route to go back and hey presto, you have RUT behaviour.

In my notes on RUT, you may have noticed that I have said that if the route is recalculated eg by pressing skip, it changes its behaviour. My belief is that it recalculates the route using the track-trip algorithm rather than the 'find a new way to get me to the next route point' algorithm. This is supported by the fact that subsequently, it doesn't care about missed route points and doesn't remove them from the route list. It is just following the magenta line and behaving as if it is a track trip. But it never does this with saved routes - only imported.

So I believe that RUT behaviour is a feature of navigating tracks that have been converted to trips. And using the track-trip algorithm which causes RUT behaviour is a feature of the Zumo recalculating an imported route. It's possible that someone, somewhere came up with a brilliant idea about how to deal with all of the issues caused by owners using different routing programs and different maps, and that it hasn't been thought through or tested properly. And maybe it is this that has resulted in the unintended consequences. The solution should be easy to solve - give the option when the route is recalculated: a) point to point, like saved routes; or b) closest point ahead, like track-trip. Set the mImported byte according to that answer. Easy. No more problems.



Note 1. An example of a track trip attempting to navigate back to an ever changing point on the original route is described in this link.
app.php/ZXT-P53

Note 2. It is worth looking at Navigating using a track. Just load a track and select Go. No instructions or directions, but if you stray away from a track, the map screen shows a dotted straight line to the closest point to the track up ahead. You can't get to it in a straight line, but that is the point to aim for. The reason this is worth looking at (apart from the fact it is a surprisingly relaxing way to navigate), but watching what it is doing and how it chooses the point gives you a lot of info about how the track-trip route is behaving when you deviate. And that gives you a lot of info to recognise whether you have got RUT behaviour.

app.php/ZXT-P51

But I have never been able to make the RUT behaviour appear on saved routes, nor on routes created with TripManager, nor on imported routes that have been copied or re-saved on the Zumo screen. And I have tried hard to provoke it using the same route and carrying out the same detours on the same day of the week on a completely restored XT2 and XT - (to prevent riding history from having an effect). I have XT1 and XT2 bothe mounted on the bike - one running the saved route, one the imported. And then done the same with the roles reveresed. Resulting RUT behaviour - Saved routes never, imported routes always.

[FrankB]

Tracks that have been converted to trips (track-trips) on the XT1 or converted to Routes on the XT2 WILL recalculate if you wander away from the magenta line.

Yes, that's true, it will recalculate. And indeed it resembles very much CEP.

I just wanted to emphasize that it will not come up with something completely different from what was calculated by BC.

[proofresistant]

Jfheath, thanks for the effort of the complex answer!

I can take a stab at each of these. Otheres may chime in with additional information.

1st question:
mLocations.LCTN (xyz).mAttr = "Shaping point"
vs
mLocations.LCTN (xyz).mAttr = "Shaping point XT2"
And, does this have any effect at all?

Try using a tread app to create a route a start, end and 2 via points. Then change the Via points to shaping. Both of these will be called 'Shaping Point'. That is what the XT2 expects, so I guess that is why Trip Manager does the same.

But this is exactly what I have tested and observed, when in my tests the shaping points of the trips come from the XT2 or Tread app, the attributes (mAttr) have the value “Shaping point XT2”

Then at the moment my last 3rd question or better said, search for a possibility.
I would like to transfer routes to the Garmin as trips

Ok - you've got me. What exactly do you mean by a 'Trip'. Garmin XT2 does not use that term.

Editing the "Trips" is exactly the “mission” of the trip manager.
Garmin uses this term in its folder .System\Trips and there in the file extensions 1234567890.Trip. So they are probably also called trips for Garmin.

It is then coded in a completely different way in the .trip file. I can get a glimpse of what it is actually storing - but getting into the detail so that this section of the .trip file is created accurately enough for the XT2 not to crash
[...]
is worth the time and effort.

To get all of that code into Trip Manager is mammoth task and made even harder without an XT2. The XT1 has a similar file format, but it is not identical.

I can now better imagine that it is a big challenge to implement this and to rebuild the code accordingly.
And also in my opinion it is not worth the expected effort.

It's just too ambitious an idea to simply create a route externally (start destination via PTs sharpening pts and the track (ghost track) for each segment) and simply play it on the Garmin so that the XT2 "just" drives it and doesn't recalculate it.
That's actually the only big thing I expect from the XT2. A nice display that allows me to follow my planned route, no more and no less.

[proofresistant]

Frank thanks for the effort of the complex answer!

If GPX routes are sent to the XT2 as a trip via "Transfer to device", why do the individual shaping points have the attribute "Shaping point" instead of "Shaping point XT2"

Suppose you import a GPX "the normal way", via Basecamp for example that is what Shaping point are called. "Shaping point XT(2)" are typically points when a trip is modified on the XT(2) by the Tread app, or as we recently discovered via the "Shape route" function of the XT

Yes, that's how I observed it too, the attribute has the value “Shaping point XT2” when creating shaping points on the XT2 or in the Tread app or even if they were part of a route imported with theTread app.
The attribute has the value “Shaping point” if they were part of a route imported with XT2.
I really don't know if it has any effect, but I thought we want to do it as if the routes were not imported.

You can "clean up" the route with "Post process"

That function does not use map information at all. In stead it compares the Coordinates of the shaping point and the next point of the route. [...]

Using the next point on the route is a good idea.
Thanks for the info, I didn't realize it could work

I would like to transfer routes to the Garmin as trips so that the XT2 no longer calculates them, even when importing them. It simply takes too many minutes.

There are 2 reasons why TripManager does not work that way.
1) Simply. I can't. The trip format has not been decoded enough [...]
2) Even if we/I could, it would not be desired. [...]

to 1) Would have been nice, but I could have guessed that it was too complex a task with too many unknowns.
You've already put so lot of effort into it.

to 2)
Well, you can really argue about that.
How nice it would be if the XT2 would simply guide me as planned, with out recalculation and so on



But how ever, TripManager is great.
I like more and more
- compare the trips “converted” by the XT2 with the original GPX routes
- Also, exporting the routes as HTML, so you can quickly see what kind of route it is
- and also avoiding the RUT problem, although I still need to gain more experience there

[FrankB]

But how ever, TripManager is great.

I agree, but I am biased.

- compare the trips “converted” by the XT2 with the original GPX routes

You may find it interesting to know that we (@smfollen and I) are working on version V1.5 that will have the option to do the compare automatically.
You can read more here: https://github.com/FrankBijnen/TripManager/issues/12
For anyone who would like to test that version, send me a PM, and I will give you a download link.

Here is a screenshot of the work in progress:

NewCompare.jpg (491.85 KiB) Viewed 1289 times

[jfheath]

Then at the moment my last 3rd question or better said, search for a possibility.
I would like to transfer routes to the Garmin as trips

Ok - you've got me. What exactly do you mean by a 'Trip'. Garmin XT2 does not use that term.

Editing the "Trips" is exactly the “mission” of the trip manager.
Garmin uses this term in its folder .System\Trips and there in the file extensions 1234567890.Trip. So they are probably also called trips for Garmin.

Ah. Some people refer to the Tracks that are converted to trips as 'trips'. And that is how I read your comment.

The XT2 has now abandoned the term 'Trip' - as in 'Trip Planner' and convert 'Track to a Trip' which was in use for the XT1 - and started using the word 'Route' instead.
I'm well aware of the Trip files in the .System folder - and the .trip files exist for the both XT1 and XT2, albeit in slightly different formats.

Trip Manager takes your route in gpx format and it builds the .trip file. But it has to rely on the Zumo to actually build the complete .trip file with all of the ghost points and routing preferences. The XTs have many situations where the route is recalculated anyway - something that I am learning to live with. With TM creating the .trip file, the calculation on the XT2 has been rapid, and not really an issue.

We hit a very big snag in creating the .trip file. And Frank and I had a few video chats about it. Without an XT2 himself all Frank could do was provide TM updates which included some tools that I could use to help with the systematic trial-and-error process of identifying fields and/or values that were causing the problem.

I eventually found one that made the difference that enabled the XT2 to load the route. And we were able to progress from there. these numbers were identifiers - unique. Something that presumably linked two things together - like a key and a foreign key in a database. We didn't know where the other part was - presumably in Tread. That could have been an issue - except once the route had been calculated, I noted the this value had been altered - and presumably paired with its mate at the Tread side of things.

Possibly something that identifies that the route on the XT2 has changed, so Tread needs updating. Or vice versa. But that first calculation of the route seems to be important in making Trip Manager routes work.