Trip Planner Routes

[Peobody]

I am currently in the evening of day 1 of my trip for which I have created 5 routes, one per day. All of them have a departure time/date except the one for day 2 (tomorrow). I have 20 routes in Trip Planner. Fifteen are local rides, the other 5 are this trip. The ones with departure dates are at the bottom of the list, sequentially by departure date, most recent first. The route without the departure day (day 2) is listed at number 12. My guess on the order is that the are listed by the date they were last saved in Basecamp except for the ones with a departure date. They are put at the end in departure date order.

In the past, before leaving on a trip, I would clean out my XT, loading only the routes for the trip, all of which had departure dates. When I did that, all routes were listed in sequential order, day 1 to day x. I intentionally did not do that this time just to test whether proximity appeared to have any affect on the sort order. It does not appear to based on what I see right now.

@FrankB, is there any chance the mimport fix could affect this? I am guessing not, but I ask because I did not expect the routes for this trip that have departure dates are at the bottom of the trip planner list.

[jfheath]

I've used date / time frequently when planning trips. The XT has no way of setting the departure date, only the time - but it still takes notice of the date that has been set in Basecamp. This is the date & time that is assigned to the first point in the route.

It's a long time since I tested this, but I believe that it sorts in date order first and any trips with the same date or with no departure date are sorted in order of proximity.

[FrankB]

@Peobody
Very unlikely that changing the mimported byte has an effect.
But to change it, you have to 'save' the trip file on the XT, thereby changing the file date. Maybe that has a side effct?

[jfheath]

@Peobody
Very unlikely that changing the mimported byte has an effect.
But to change it, you have to 'save' the trip file on the XT, thereby changing the file date. Maybe that has a side effct?

I did wonder about that - not so much when changing the .trip file directly, because the date in question is obtained from the time set for the first route point. Whether or not the info is reproduced in the .trip field and then used from there, I don't know.


No, my concern was when using the alternative method of resaving the active route, because that method adds a new start point -set to be the location when you saved the active route. So how the XT deals with that, I don't know. But if you set a time for reaching a via mid route, BC will work the timing back to the start. Maybe the XT does the same ??

I'll get an answer for that eventually. Its not top priority though. Its rarely an issue for me - I start each tour with a Zumo empty of routes, tracks, history, saved waypoints.

[jfheath]

@Peobody
Very unlikely that changing the mimported byte has an effect.
But to change it, you have to 'save' the trip file on the XT, thereby changing the file date. Maybe that has a side effct?

I did wonder about that - not so much when changing the .trip file directly, because the date in question is obtained from the time set for the first route point. Whether or not the info is reproduced in the .trip field and then used from there, I don't know.


No, my concern was when using the alternative method of resaving the active route, because that method adds a new start point -set to be the location when you saved the active route. So how the XT deals with that, I don't know. But if you set a time for reaching a via mid route, BC will work the timing back to the start. Maybe the XT does the same ??

I'll get an answer for that eventually. It's not top priority though, and is rarely an issue for me - I start each tour with a Zumo empty of routes, tracks, history, saved waypoints.

[Peobody]

I've used date / time frequently when planning trips. The XT has no way of setting the departure date, only the time - but it still takes notice of the date that has been set in Basecamp. This is the date & time that is assigned to the first point in the route.

It's a long time since I tested this, but I believe that it sorts in date order first and any trips with the same date or with no departure date are sorted in order of proximity.

When you did this, did your XT contain only the routes associated with the trip? As I said, my experience with it had always been that it sorted by departure date as set in Basecamp but in those cases, only routes associated with the trip were on the XT. The two differences for this trip are:
1. The mimport fix was made to these routes. I used Frank's utility for doing this. This is the first multi-day trip for which I have 'fixed' all of the routes.
2. There are numerous other routes on the XT besides the 5 associated with this trip. They would be in departure date order If I deleted all that did not have a departure.

[jfheath]

Sorry. I was talking about my 'trip' ie my holiday. My holiday consisted of a number of individual routes - one per day, usually with a couple of bad weather or fatigue alternatives. Sorry, I slipped into my own terminology, forgetting that 'Trip' had implications to Garmin devices.

The start of each route would be a point after setting off from the hotel or campsite. The end would be at the hotel/campsite for that particular day.

I investigated Basecamp mulit-day trips and discarded them as being a good way of making everything unmanageable.
I hate Garmin's use of the term Trip. Even more so since they now use it to mean something without route ponts.
I always used to use the phrase 'route planner' and blanked out the fact the screen called it 'trip planner'. For a while I tried to analyse what garmin actually meant by the terms 'trip' and 'route' - thinking that 'trip' must be the sequence of points and 'route' must be what is produced as a result of calculating the best way to join the dots. Then I thought it must be the other way round when the talked about converting a track to a trip. Then on the XT2, the thing that used to be called 'trip planner' is now a 'route planner'.

Then I decided exactly what I thought about how Garmin seem develop its products.




Hmm. Im rambling. What was your question ?...


I tested it just using the routes that were listed in the XT trip planner app, that I created using BC.
I haven't experimented yet with the mimport byte, nor with the resave technique. I'm thinking the latter may affect the date.

Previously - I think the 595 (but it may have been the 590) sorted the routes in date order, putting past routes at the bottom and todays at the top - all divided into headed sections with a day icon.

[Peobody]

I tested it just using the routes that were listed in the XT trip planner app, that I created using BC.

This is what I am keyed on. My question is whether the routes you has listed in XT trip planner were only routes associated with the one trip? If so, the expected sort by departure works for me under that condition. It doesn't when there are other routes in trip planner though. That is the scenario where I can not determine what it is using to determine the order.

[jfheath]

I think if other routes are involved, and these do not have a time/date then proximity of the first point to the current position is used to decide upon the order. This method is used for sorting Waypoints/Favourites - so the order is forever changing if you look at the list of favourites on different days during a tour.

I'll see if I can find some test data (or make some) and get screen shots of the XT, 595 and 590 - which all display slightly differently.

[Peobody]

I think if other routes are involved, and these do not have a time/date then proximity of the first point to the current position is used to decide upon the order.

Not for me. My trip is made up of 5 routes. All were assigned a departure date/time in BC except Day 2. On the eave of day 1, the day 2 start point was just down the street but that route showed up 13th in Trip Planner (total of 20 routes). All of the ones above it were local routes which were hundreds of miles away, without departure data. Today is day 3. This morning, its route was #18 in the Trip Planner list. This isn't a problem so much as an oddity that defies logic so far.