Shared routes BC to BC, different results

[Peobody]

Today a riding buddy and I came to the realization that activity profile options do not transfer when we share routes. I'm sure this is old news to most of you but it caught us by surprise. Apparently we've had similarly configured activity profiles until our last route exchange with his new PC and Basecamp installation. We now know that a calculation in Basecamp can produce deviations in the same way that a calculation by a satnav device can. This is logical and should not have been surprising, but it was; perhaps because we have shared routes for a number of years without issue, until now. We're now thinking that our emails should include a track, and a screenshot of the route options tab from the attached route. Anyone have any other tricks when sharing routes?

[danham]

Not so much a trick as further evidence of BC making changes. When I import a gpx route from another source, I always look at the miles and time before doing anything else and load a track as reference. A quick look tells me if the route is intact but the time almost always reads 0:00. So I do a recalc and again check visually against the track. Sometimes the mileage changes even if the route does not, as compared to the track.

In other words, BC has several opportunities to mess with a shared route.

-dan

[Peobody]

A quick look tells me if the route is intact but the time almost always reads 0:00.

Yup. A recalculation is required in order to generate that info. Unfortunately that can result in changes to the route. I have an XT and my buddy has a Nav VI. We have routinely experienced shared routes producing different results on the devices but I now wonder if the differences were first created by Basecamp. Usually one of us creates the route and the other looks at it in BC before loading it on the device. There is no way for the recipient to know that BC changed the route unless they have a track of the original. In this case, we planned to collaborate so he sent me his preliminary which I anticipated modifying with suggestions so created a duplicate to look at and play with. The initial recalc of the duplicate resulted in two routes showing on the map. That was the AHA moment for me. We then confirmed that we had very different avoidances enabled. A recalc after syncing avoidances eliminated the deviations. You know those moments when you feel like you should have known? I sure had one yesterday!

[smfollen]

I believe the only "activity profile" sort of information BC exports is Transportation Mode and Calculation Mode, e.g.:

Code: Select all

<trp:TransportationMode>Motorcycling</trp:TransportationMode>
<trp:CalculationMode>FasterTime</trp:CalculationMode>

Both of them are optional extensions to the gpx schema.

The gpx schema, including any extensions, defines the gpx file format and content. Unfortunately, it provides limited information regarding how that information is interpreted or used. This is the nature of the gpx standard. It is not specific to Garmin - although Garmin did publish several gpx schema extensions.

When Basecamp reads "<trp:TransportationMode>Motorcycling</trp:TransportationMode>", within the definition of a route, in an imported gpx file, it takes it to mean apply the Activity Profile named "Motorcycling", if there is one, to this route when [re]calculating it.
As you discovered, the Activity Profile does not come from the gpx file, it is specific to the BC installation and its configuration.
As a result, an imported route may initially look fine, but change when it is recalculated.

Another route planner or device may handle Transportation Mode differently ... or not at all. It may support Transportation Mode, but may not support "Motorcycling".

The same is true of any other optional parameter in any gpx file. For example, the zumo XT2 tends to prefer "faster roads" rather than fully calculating the "fastest time" when the Calculation Mode is "FasterTime".

Regardless of the gpx file source, a route in a gpx is made up of a relatively small number of "Route Points", which may optionally be specified as "via" or "Shaping" points. When a route is [re]calculated by any route planner of navigation device, the results depend on how that device / planner interprets the gpx file content as well as that device's / planner's map, routing algorithm, and user settings for routing preferences and avoidances, if any.

In other words, the gpx schema leaves a lot of room for route variation. This is not specific to Garmin - although it would be nice if things were more consistent across Garmin products at least !

Even when exporting from Basecamp and importing to a different Basecamp installation, only the routing algorithm is sure to be consistent. The rest is up to user configuration.

Note that Tracks are defined by a very large number of "Track Points". Once defined, they are never recalculated so they never change when imported to a different device or route planner.

(In case someone wonders about route point extensions, those are the result of routing calculations, never an input to the calculation. They are used to draw a route on a map, and to generate a track from a route, but they are not used to calculate a route. They are another reason why an imported route may initially look fine, but change significantly when the route is recalculated.)

[Peobody]

When Basecamp reads "<trp:TransportationMode>Motorcycling</trp:TransportationMode>", within the definition of a route, in an imported gpx file, it takes it to mean apply the Activity Profile named "Motorcycling", if there is one, to this route when [re]calculating it.

I do not find such content in the .gpx files I received from my buddy nor in the ones I sent him. Testing revealed that this is because we are in the habit of assigning a "None" Activity Profile to our routes to prevent automatic recalculation in the event that an assigned Activity Profile got modified. No <trp:TransportationMode element in the .gpx resulted in Basecamp using the "Motorcycling" Activity Profile when it recalculated. Imagine someone who added then uses a custom activity profile to create routes so was never attentive to the configuration of their "Motorcycling" profile. That thought led me to looking in Basecamp for how a default Activity Profile was set. I can't find it, yet my Basecamp always defaults to "Motorcycling". Is that built-in? Am I missing something?

[smfollen]

Good question. I'm not aware of a way to set a default profile in Basecamp.

[danham]

Even worse, BC can sometimes arbitrarily pick a profile. I recently imported some NER routes and did the usual recalc compared to a track and the route went berserk, adding dozens of miles. I finally figured out that somehow BC decided the route should be recalculated using the "No Tolls" activity profile (which I have never used). The cause was in Settings/Routing where the toll road avoidance was mysteriously checked, not by me. I had been experiencing some computer issues prior to using BC that day and I guess its preferences file got corrupted.

But the weirdest aspect is that there were no toll roads in the route, so that avoidance should not have made any difference.

-dan

[Peobody]

@danham, I am curious what happened to the route when you did a recalc following the disable of the toll avoidance.

[jfheath]

None of the detailed information in the profile that you use in Basecamp is transferred to the Zumo. It never has been.


Simply put - Basecamp sends just two values to the Zumo

Transportation Mode (eg Motorcycling - from the Basecamp Profile Name)
Routing preferences (eg Faster Time) - from the routing preferences.

------------------------------

I did a detailed study of this for the Zumo 590, which could use any of three of its own profiles - and things could be affected depending upon which cradle - car or motorcycle - it was clipped into. Link if you are interested - but it makes tedious reading. Download the pdf. 3rd section.

Behaviour was slightly different with the 595, and different again for the XT1. LInk here for analaysis of XT1 behaviour - and subsequent pages.
(If images do not load, refresh your page a few times).



Not all Zumos recognise the same profiles names. If it doesn't receive a value, or if it receives a value that it doesn't recognise - then it uses the default Transportation Mode (eg Motorcyling) and/or it uses the default routing preferences (eg Faster time).

The XT2 may not recognise any profile / routing that BC sends it - so it uses the default ( zūmo Motorcycle / Faster) so that works out to be OK.
(The XT2 recognises a different profile name - eg "zūmo Motorcycle", not 'Motorcycling')

The XT2 added a new feature in that different segements of the route can be given different routing preferences. This is carried forward to the XT3
The XT3 adds a new facilty - you can create your own profiles on the XT3 screen. So different settings for different motorcycles.

Neither of those features can be used by Basecamp - but Basecamp routes will appear to work in the XTs - but they will be using the default profile and the default preferences - which have nothing to do with what you had set in Basecamp.

If you want to continue using Basecamp (I do) then set it to Faster Time. Use Motorcycling. Control the route using as few srategically placed shaping points as necessary. Some things can be set in both Basecmap and on the Zumo - eg Avoid Ferries. Providing both are set the same, then if the Zumo recalculates the route it will (try to) produce the same results that BC produced. (But we know that the XT1 and XT2 do not calculate a faster route. They calculate a route which uses faster roads. Which are two very different things.

Hint.
In Bascecamp, if you set your preferences for a custom setting, then the preferences are saved with your BC route. That means that if you change one of the values, the changes to the route are shown instantly on the map. This helps you to position shaping points and via points to make the route follow the same roads no matter what the settings are. You can then apply your normal Motorcycle profile if you like.

Note that The zumo will pick up the Faster Time / Shorter distance setting in the profile or in the custom settings, so make sure that is set as you want the Zumo to receive it. (Whether the XT2 or XT3 will respond in the same way was the XT1 and earlier - I don't know, I haven't tested the XT2 for that, and I don't have an XT3. They may just use the default of Faster time)

[Peobody]

None of the information in the profile that you use in Basecamp is transferred to the Zumo. It never has been.

@jfheath, this discussion was started by me due to being surprised that Basecamp produced a different route upon recalculation of one shared with me that was created by the same Basecamp version and map. Different route preferences and avoidance would logically produce variations but I hadn't given that any thought until it happened. It surprised me not only because I hadn't though about it, but also because this fellow and I have shared routes many times and this is the first time I detected deviations.

I'm not looking for an explanation or a fix. I started this thread to express my surprise, and to serve as a heads-up to others who share routes that a recalculation of a route immediately following import can result in changes. This lead to the realization that it is important to have an original, or a track of the original, to compare the recalc result to. As @danham pointed out, this is a concern for any imported route regardless of its source.