I’m a little behind on this thread. I’m mostly going to try to respond to proofresistent’s 3 questions post, adding a little perspective.
First a quick clarification.
FrankB wrote:
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.
In the interest of giving credit where it is due, it is more like I gave Frank a couple of rough ideas and he turned it into more great features in his very useful Trip Manager.
@proofresistant regarding
“@Garmin: Thank you for the fact that so many people spend days and nights dealing with issues of poor or faulty functionality.”
And
“That's actually the only big thing I expect from the XT2. A nice display that allows me to follow my planned route”
I agree with you entirely. The reason I own an XT2 is to be able to plan and follow a route. Some of the other navigation related features are nice to have, IF they work properly and do not interfere with the primary route planning and following functions. For me additional features like phone calls and music are unnecessary complications. My phone does all that already. Other users may have differing priorities of course and Garmin wants to build what sells.
As I see it, some of the frustrations with XT[2} route planning and navigation should be owned by, and corrected by Garmin, but other frustrations are due to the nature of navigation and the state of the technology.
If there were only one road between points A and B, it would all very simple. Typically, there are several ways to get there. Before GPS and digital navigation, we might have asked 2 or 3 people how to get from A to B and receives 2 or 3 different sets of directions. We were never sure which, if any, of those were correct until we tried them.
In the digital world, 2 or 3 different devices or route planners might give us 2 or 3 different routes, due to differing maps, route preference setting, routing algorithms, and avoidance settings, but we can, at least, be confident they will all get us to point B.
However, I think It is reasonable to expect consistent results from a single vendor’s (e.g. Garmin's) related products when they are configured similarly and using the same map.
1st question:
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"
mLocations.LCTN (xyz).mAttr = "Shaping point"
vs
mLocations.LCTN (xyz).mAttr = "Shaping point XT2"
And, does this have any effect at all?
In the original gpx standard, which is publicly published, routes were made up of route points. Garmin subsequently publicly extended that standard to define two types of route points – via and shaping. The difference was important during navigation, but both types were identical in terms of route calculation. Route points were, and still are, user defined points which are inputs to route calculation.
Somewhere along the way (with the XTs maybe?) some of Garmin’s software began to make slight changes to shaping point names and locations – that is to make small changes user input - without the user’s knowledge or consent They also began to produce differing routes depending on whether a point was via or shaping. The Tread app took this much further, making dramatic changes to the user’s planned routes in some cases.
viewtopic.php?t=3007
That is one of the reasons I have eliminated Tread entirely from my devices and process.
As John and Frank have already responded, the second type of shaping point, which Garmin apparently did not add publicly and has not explained, is somehow related to this behavior. I specifically asked Garmin support about this. They told me that point type definitions have evolved but they declined to provide any definitions or describe the expected behavior. They did indicate that they hope to address the above linked Tread issue sometime in 2025.
2nd question:
You can "clean up" the route with "Post process"
This centers points, which is good.
But, the basis for the points is the OSM map, which differs from the Garmin City Navigator map and therefore it is not more accurate?
I would also be interested to know how far points can be away from the roads before Garmin can no longer calculate with them.
I'm asking because I still haven't found out when and why Garmin sometimes refuses to work…
I don’t know how to respond to the general “refuses to work”. I don’t think there is a single answer to how far points can be away from the roads. In my experience, route calculations just take you to the specified point. If specified points are not placed carefully, they may be just a short distance from the intended road but may be in a field or forest, on the wrong side of a highway, or on the wrong road. The software can only take what the user specified. It has no way to know what was intended.
For myself, I address this by keeping the map in sync between Basecamp and the XT2. I check each route point of each route in Basecamp at maximum zoom level and correct any misplaced points before sending the route to the device. Yes it takes a little time, but not that much. I find it to be much better than being surprised during a ride and trying to fix the route on the side of the road.
I think Frank’s intention with the optional post process route cleanup is an attempt to help those users who don’t check carefully. I would agree that the maps may be different and could be less accurate. It is the best Trip Manager can do.
@FrankB Please correct me if I’ve got this wrong.
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 so that the XT2 no longer calculates them, even when importing them. It simply takes too many minutes.
Is it conceivable that at some point in the future, calculated GPX routes, 1:1 of the existing calculation, can also be transferred to the XT2 as a trip?
It is a mystery to me, by the way, on the basis of which attributes the XT2 recognizes that the externally used maps or routing restrictions deviate from the device's internal map
I think of routes as being either calculated or uncalculated, which Trip Manager calls a stripped route. A gpx file containing either can be sent to the XT2. If uncalculated, the XT2 seems to always calculate immediately on import. If a calculated route is imported, it will not be recalculated if, I believe, it Is based on the same map, the same vehicle profile (motorcycle), and has not had avoidances changed.
I’m surprised it takes minutes to calculate. It is normally quick for me. Maybe the Tread app and syncing slows things down? Or you have a large number of route points?
There is danger in not re-calculating the route on the device. The imported route may look fine initially, but could change drastically if it is later recalculated for some reason – a detour, or route edit on the device for example. This can be frustrating if it happens while out on the road. Recalculation can be avoided by setting “Off-Route Recalculation” to Off and being sure to not make any route changes.
One might wonder why a route would change dramatically: In addition to Via and Shaping points, imported calculated routes include large numbers of route point extensions, which are the result of previous route calculations. On recalculation, the route point extensions are discarded. The route is recalculated based on only the Via and Shaping points.
As far as I know, Trip Manager currently builds only uncalculated routes into .trip files. I think it probably could build .trip files containing calculated routes from gpx files containing calculated routes. Given the risk of significant route changes if later recalculated on the device, I’m not sure that it is a good idea.
I take the approach of recalculating the route on the XT or XT2 immediately after import or transfer, comparing it to the original, and adding additional [shaping] points as needed to produce matching routes. Again, it takes a little time, but I think it is worth the time. Others may disagree of course. The automatic route compare feature in the upcoming V1.5 should help to speed up that process.
Again, much of this is the nature of digital routing in general. I don’t think Garmin can solve it all, but I do think they could do better. After all, a lone man called Frank is making things better for all of us with Trip Manager.
... and much of what we know about zumo behavior is thanks to the significant efforts of
@jfheath and others who post here.
