when importing route prepared with Basecamp, XT recalculates

[Peobody]

Thank you for that exposition and for the diagnostic efforts. Identifying the cause of a rogue waypoint may be the key. Do you have any thought about whether moving a waypoint to position it on the road could make it 'rogue'? I do that a lot. @chris7444, do you?

[danham]

Random thought from out in the cheap seats: does putting a waypoint too close to an intersection cause this (and other troubles) on the XT? I know it did on earlier Garmin models.

-dan

[jfheath]

Chris had a few points in his route that were placed exactly on a junction. I moved them, but it made no difference at all.

I tried changing the Vias to Shaping, moving the waypoints, moving all of the points. Nothing like that fixed it.

I made a track and duplicated the route with my own routepoints. That worked, and it worked on Chris's XT too.

To answer Dan's question - putting it on a junction doesn't create a problem for the Zumos that I know of, but the idea of putting a route point is to get it to navigate along the road that you want. It is for me anyway. The XT will go for the faster roads (it seems), rather than the faster route times. So if you want to take the scenic road and you mark the junction, most of the time, it will go straight on, rather than turn left.

To get it to turn left you would need a shaping point somehwere in the middle of that road. Or two (or more) shaping points one a third of the way along, one 2/3 of the way along. This to stop it turning left and then doublingback.

Shaping points because they are easier to ignore - if you rejoing the magenta route.

The only problem with this method is if there is a narrow road that takes a short cut and misses out the junction. These are usually roads less travelled littered with rubbish, kids, parked cars, mud, grass in the middle, metal spikey things that have been waiting far to long to mate with a bike tyre...you get the picture. You just have to be aware that this might happen, zoom out, and carry on ahead to the junction. Vhances are that the Zumo will recalculate instantly.

I don't know about moving a library waypoint to the road would make any difference. I can't think how it would. Its the same data in a different position.

With Chris's dilemma - I have just proved that it is the library waypoints that he used. Remove one the start point, it makes no difference. Remove the first point, and it goes instantly to 40% and then takes a minute for the remainder. Remove the third point (which is about midway), it takes just under a minute to get to 43% and then calculates the last instantly. These were waypoints that had some additional info stored - including some (from the gpx file) that was not recognised by Basecamp.

Replace all of the waypoints with new flag waypoints placed by me. And the 'calculation' was instant (ie it didn't calculate the route - it just imported what it got from Basecamp.). Forcing a recalc of that route on the XT took just 14 seconds.

I have yet to try to find my own library waypoints to see if the problem returns.

I am pretty sure that I have used library waypoints in Basecamp in the past. Even if they were inaccurately placed, they still had the phone numbers and addresses, and having that coupled witht he XT that allows you to tap on the point and make a phonecalls withouth having to get out of your soaked gloves and let the rain in through the zips is well worth having. But previously I have used the 550, 660, 590 and 595 and it has not been a problem.

It remains to be seen whether all waypoints from the database have this issue, or whether Chris has unluckily landed on 3 that have rogue data.

But now we know that if somone is having problems with slow transfer times and all of the usual culprits have been eliminated, then it may be to do with where the Waypoints have come from.

John

I have yet to find out from Chris where his waypoints came from. I have assumed that they came from Basecamp, but that might be an incorrect assumption. They could have come from a friend and they were then loaded into Basecamp.

[chris7444]

I found at least one reason why the GPS calculates a route when importing it in the trip planner. This happens when the route contains points coming from the search tool (first picture, search for "col de la chambotte")

search chambotte.png (20.77 KiB) Viewed 2640 times

A "searched point" inserted in the route will cause the Trip Planner to calculate the route even if you think this point is properly positioned on the route (2nd picture), the point within the orange circle was inserted in the route using the search tool, the point inside the green circle was inserted manually)

search point added to the route.png (63.15 KiB) Viewed 2640 times

I did the following experiment (You can use the attached GPX to double check)

1- take a route that "works" (meaning the GPS does not calculate when the route is imported using the Trip Planner)

2- Add a waypoint in this route using the search tool, export to the GPS
=> The GPS will calculate the new route (even if the waypoint is positioned correctly on the "old" "working" route

adding a poi in the route.png (21 KiB) Viewed 2640 times

3- remove the waypoint you inserted before, export
= > Trip planner does not calculate the route when importing it

My conclusion is that one should not use the result of the search tool to add a point in a route (unless you don't mind the trip planner to calculate). Use it to locate what you are looking for on the map then zoom and insert a waypoint/shaping point manually

ps: Sorry for the screenshots in french but switching to english puts the mess in my Activity profiles
ps: I believe that when adding a point using the search tool, you are actually adding a reference to a POI and the GPS searches for the POI in its own database, hence the calculation (a POI comes with the information that comes with the database and you may want to find this information also on the GPS, hence the search)) That is a just a guess. True or not, that does not change the net result, the GPS calculates as soon as there is such a "point"in a route.

[chris7444]

I have yet to find out from Chris where his waypoints came from. I have assumed that they came from Basecamp, but that might be an incorrect assumption. They could have come from a friend and they were then loaded into Basecamp.

I did not load any specific POI database. They come from Basecamp (if basecamp comes with POIs) and the Zumo (maps. parkopedia etc) (I don't use the Yelp POIs). Actually before posting this question I completely uninstalled Basecamp, deleted the maps on the PC (but not my database) and reinitialized the Zumo

[Peobody]

Addition to routes of POIs from Basecamp Search would explain it for me. I am working on my summer trip so will focus on Day one, replacing POIs added via search with ones added manually and see what happens. Thanks @chris7444.

[FrankB]

@jfheath Hi John. This is yet another issue that can be explained (and maybe solved) from the subclass field. If I set the subclass fields from the <rtept> to the special value '00ff' calculating on the XT is instantaneous.

This is a filecompare. Left is the modified value, right is the original.

subclasses calculate.jpg (270.41 KiB) Viewed 2624 times

@chris7444
What you see here is the output of a small Java program I have written. If you feel confident executing commandline programs and are interested send me a PM.

[Peobody]

I found at least one reason why the GPS calculates a route when importing it in the trip planner. This happens when the route contains points coming from the search tool

Confirmed, although my test was not as dramatic as I expected.
Route:

• 277 miles

• 28 Waypoints (mixture of Via and Shaping)

• 3 of the Via Points were added via Search

Transferred to XT using Send To from BC. Import calculation time was 17 seconds (much less than I expected).

I then

• Deleted the route and the saved points from the XT

• Modified the route, replacing the search POIs with ones set using the waypoint tool

I again transferred the route to the XT using Send To. Import calculation finished in 2.5 seconds.

Finally, I modified the route leaving only one POI from the search tool. Its import calculation time was 6 seconds.

Conclusion from this test is that each POI from Search added 5 seconds to the import calculation time. My norm is to have a minimum of four POIs from search (coffee, lunch, fuel, hotel) plus any planned tourist stops along the way. I never have enough to account for a 2 minute import time but it appears to be a significant contributing factor.

The question for me now is whether shortening the import calculation time is worth the effort of manually adding those POI's rather than adding them from Search.

So here's a question... I normally confirm the location/existence of my stops on Google Maps so is there a way to locate them on Google Maps first and then add a waypoint in Basecamp using coordinates from Google Maps?

[chris7444]

The question for me now is whether shortening the import calculation time is worth the effort of manually adding those POI's rather than adding them from Search.

The problem is that when the GPS is running on the battery, the operation times out (or fails I don't know) and the trip is not imported.

The time it takes to process a searched waypoint (if this is the explanation which it seems it is) depends on the size of the maps enabled in the GPS and probably the POI databases. It is easy to verify by enabling/disabling the maps in mymaps. The bigger the maps, the longer it will take to process the waypoint.

Interestingly enough if I disable all maps in myapps, my example route (the one with one searched waypoint/shaping point) is loaded in a fraction of second. I re-enabled the maps and voilà. Not sure if this is a good idea though

[sussamb]

Do you keep all maps selected then? If they overlap this isn't a good idea and can cause numerous issues. Perhaps you've found the cause of your problem.