Scenario found where recalc modifies original route

[Peobody]

In this discussion I express concern that my XT was recalculating every route when I transferred a large number of them (viewtopic.php?t=1841&start=20. In that discussion @jfheath described a test to see if the XT was recalculating on import. The test included 4 points, with the 2 interim ones as shaping points, and transferring them with device transfer options set to strip shaping points. I have just now gotten around to doing that test. When the was imported and loaded, the XT shows the route correctly but without the shaping points. This is as he surmised it would. The second part of the test was to do a recalc to see the affect of the missing shaping points. My recalc ,done by changing Usage Mode to Automobile, resulted in a route that ignored the shaping points, as expected. The surprise was that now, when you load this route, it shows up as the recalc'ed route. Obviously all of the ghost points of the original route are gone.

Some recent discussions have included talk about whether the XT changes the imported route (the internal storage version) when it does a recalc during a ride. Several of us have confirmed that when a unacceptable recalc occurs we have been able to recover by stopping/restarting the route. My assumption has been that a recalc changes the active route in working memory but not the version on internal storage. This is obviously not always the case as per the above experience. I don't think we can assume that a recalc ALWAYS strips the ghost points since this would be contrary to the experiences of being able to recover by reloading.

So, what the heck is happening (polite for WTF!). Perhaps the XT treats a recalc done by changing Usage Mode differently than one it makes to an active route. If so, I wonder what other conditions result in a recalc that modifies the version on internal storage.

[Rofor]

This was already a fact on the 'old' Zumo 59x series - and the reason, i always(!!) stored/send routes from Basecamp to the sdcard and not the internal memory...

And on the Zumo XT there is another reason it 'destroys' the original route in memory - when the recalc is triggered because of a road closure! Even if you cut out the connection to traffic alerts a restart of the original route doesn't help! You also have to start the Zumo XT completely new and than start the original route again - it seems that the Zumo XT stores and uses the latest traffic alerts in internal memory until the next shutdown, even there's no more connection to Garmin Drive app...

But you're seem to be right: recalc while using a route because of leaving it seems to be done to the next shaping-, way- or via-point - recalc a route because of changing the mode seems to be a complete recalc with only start- and endpoint counting!

BUT - why the heck should someone force such a recalc while riding a motorbike?

[Peobody]

This was already a fact on the 'old' Zumo 59x series - and the reason, i always(!!) stored/send routes from Basecamp to the sdcard and not the internal memory..

I do both so that I have the SD card copy as a backup while not having to bother with the process of importing them from the SD card using the XT.

But you're seem to be right: recalc while using a route because of leaving it seems to be done to the next shaping-, way- or via-point

I am not sure what you mean by "recalc while using a route because of leaving it". The recalcs I experience are because I told the XT to skip the next point or because it did a recalc because of a perceived road closure. In all cases, the recalc has been for the entire route but that recalc did not modify the route in internal storage.

recalc a route because of changing the mode seems to be a complete recalc with only start- and endpoint counting!

Agreed, but in my test case it was because the interim shaping points had been stripped on transfer. That behavior makes sense. The piece that doesn't make sense is that this recalc modifies the original route in internal storage. If you store routes in the XT internal storage and move it between motorcycle and car I guess you best not change the mode if you want that route kept as originally created.

[Rofor]

I am not sure what you mean by "recalc while using a route because of leaving it".

Sorry - should have written 'automatic recalc when leaving the planned route'...

[jfheath]

But you're seem to be right: recalc while using a route because of leaving it seems to be done to the next shaping-, way- or via-point -

That is true for the 590, 595 and the XT (although whether the point is a stored waypoint or not, doesn't make a difference)

recalc a route because of changing the mode seems to be a complete recalc with only start- and endpoint counting!

That is also correct - changing vehicle mode, changing routing preferences both recacluate the entire route.
Skipping a route point also recaclulates the entire route.
Deviating from the route recalcs to the next route point (via/shaping) on the 590/595. The XT also does this sometimes, but sometimes it take you back the way that you have come. I don't think that it recalculates beyond the next route point (but have yet to verify this).

Whichever section(s) of a route are recalculated, the original route (held in place by the ghost points) are lost for the route currently in memory. If you delete the route currently in memory and then re-import it, then the original route will be restored. edit - by that I mean delete the route from trip planner, then reimport it into trip planner.

There are some operations on the XT eg when editing the active route, when it also changed the route in internal storage. I haven't been able to reproduce this result recently, so that seems to be no longer the case.

[Peobody]

Whichever section(s) of a route are recalculated, the original route (held in place by the ghost points) are lost for the route currently in memory. If you delete the route currently in memory and then re-import it, then the original route will be restored.

By "re-import it" do you mean deleting if from Trip Planner and importing it from the SD card or re-transferring it to internal storage from Basecamp or do you mean stopping it and the restarting it from Trip Planner? If the latter, which works after a recalc resulting from skipping a point, then this is what did not happen in my test. The route in internal storage was modified by the recalc triggered by changing the mode to car (from motorcycle).

[jfheath]

Thanks for the question. I forgot to explain the terminology.

Garmin use the word transfer when sending data from Basecamp to the Zumo.

They use the word Import to describe the process of getting the transferred route into the trip planner app.

So in fact it was neither of the situations you described. There should be no need to transfer the route again - which requires some connection to Basecamp.

Stopping the route and restarting it didn't always work previously. **

But deleting the trip from the trip planner app and re-importing it into trip planner will get you back to the original.

This applies to routes transferred to either the SD card or to internal storage from Basecamp. If transferring to internal storage, then you must remember to transfer everything that you want on the XT if you have just reconnected the usb cable, otherwise data from previous transfers is lost.


** If you have an example of this still not working, I'd like to know. It used to become altered, but in a few tests recently, it always loaded an original. Or is the example in post #1 a very recent example ?

[jfheath]

Ok. Another check

If you load a route that has had its shaping points stripped from it, it retains its original shape when it is loaded into the XT.

If you change the properties of the route - eg by changing the vehicle, or changing avoidances, the entire route gets recalculated, so the original route that went through all of the original shaping points is lost.

If you load the same route again from trip planner, that route has noew changed. The same happens if you edit a route in trip planner, you do get the option to save it and that overwrites the imported version of the route that is in trip planner.

But if you delete the route from trip planner, and then reimport it, then you have the original back.

SKipping a point when navigating does recalculate the entire route, but now this does not affect the imported version that is in trip planner. Stop the trip from navigating, reload it in trip planner and it loads the original.

nb - with the XT I don't see any useful purpose of the strip shaping points, because we know that the XT is going to recalculate the route. The purpose of doing it from my point of view is using it as a technique to find out whether the XT has recalculated your entire route or not.

nb - you don't need to change the settings in Option - Device Transfer to strip shaping points. The danger is forgetting to put it back.
There is an option to strip shaping points from a route in the drop down menu which pops up when you right click a route (PC).

[Peobody]

SKipping a point when navigating does recalculate the entire route, but now this does not affect the imported version that is in trip planner. Stop the trip from navigating, reload it in trip planner and it loads the original.

This reinforces my annoyance that a recalc triggered by changing the driving mode WILL modify the version in internal storage whereas a recalc triggered by skipping a point will not. This is another behavior in Garmin programming that is inconsistent and/or illogical. It will never affect me with my usage of the XT but it may affect someone else who has the mindset that a recalc doesn't change the internal storage version.

An unknown is any other conditions that will result in the modification of the internal storage version by a recalc.

[jfheath]

SKipping a point when navigating does recalculate the entire route, but now this does not affect the imported version that is in trip planner. Stop the trip from navigating, reload it in trip planner and it loads the original.

This reinforces my annoyance that a recalc triggered by changing the driving mode WILL modify the version in internal storage whereas a recalc triggered by skipping a point will not. This is another behavior in Garmin programming that is inconsistent and/or illogical. It will never affect me with my usage of the XT but it may affect someone else who has the mindset that a recalc doesn't change the internal storage version.

An unknown is any other conditions that will result in the modification of the internal storage version by a recalc.

Now this is one thing that I am happy about, and it is consistent with the way that a route behaves when it is transferred and imported from Basecamp.

The driving mode is one of the things that is transferred to the Zumo. (The other is Faster Time, Shorter Distance), The Zumo recognises three driving modes from Basecamp: Motorcycling, Driving and Direct. As soon as a route containing any of these parameters is loaded and run, the XT immediatley switches the behaviour of the XT to Motorcycle, Car and Off Road respectively. If it receives anything other than those three terms (Motorcycling / Driving / Direct), the XT switches the route to use Motorcycle.

Whatever it switches to, it then uses the avoidances that are stored for that vehicle in the XT. So if it switches to the car Usage Mode, it uses whatever avoidances are set in the Zumo for Car.

I have a theory that when people say that the XT routes differently for car and motorcycle, that this behaviour may be part of the reason for it.

If you then load a trip that was intended for Motorcycle and decide to change it to be a trip for Car - logically the Zumo will have to recalculate it. You have changed the nature of the entire route, and the XT now has to calculate the route using the Zumo car avoidances.

I think that if you load motorcycle route into the XT when it is set to Car mode, the XT will warn you that it is about to change. It used to happen silently on the 590 and 595. Once loaded in, you can then change the navigation method and that includes curvy roads. The 595 used to recognise the Curvy road selection from Basecamp. The XT does not, and instead sets it to faster time. On the XT you can then set the routing preference to adopt the degree of curviness that you require.

But Motorcycling / Driving / Direct and Faster Time / Shorter Distance are all parameters that are part of the route itself, and which are recognised by the XT. If you change any one of those, then yes - it makes sense to me that it should recalculate the route.

Note that it doesn't change the vehicle mode that the XT shows in the little icon on the main screen - but nevertheless, it is using the preferences that are set for the vehicle that is specified in the route, not the one that is shown on the XT screen.

So if you create a custom profile and call it 'Car Shorter' with and set it to use Shorter Distance with all sorts of avoidances. When the XT gets it, because it doesn't recognise 'Car Shorter' it will use the Motorcycle profile and its avoidances, but it will use the Shorter Distance that is specified in the route, becasue it recognises that.

I spent days testing this pinning it down to discover exaclty what it does. Some of the tests are reproduced in the Everything you Need to Know article on this site.

The other thing that may catch people out is that when you have run a trip for a car in the motorcycle cradle. The next time that the XT is used in the motorcycle cradle, it will automatically switch itself to use the car settings. (The XT prompts about this). This is largely irrlevant when using routes, because when you load your route, that has all the information that it needs to ensure that it uses the vehicle that was intended, and then calculates it accordingly. In this instance, you wouldn't want it to recalculate, because it will do so using car preferences. You want it left as using bike preferences.