OM 12.0.7 contains some clever new features that improve 'direct' navigation (also called 'straight-line', 'point-to point', or {in OM} 'waypoint' navigation) of routes imported in GPX files, but unfortunately it still falls short.
There are a few strange behaviors:
1. After 'Route > Track/route tools > Load GPX file > Waypoint navigation > Accept', OM pops up "There's a track that accompanies the waypoints. Do you want to reorder the waypoints to match the track's route, or keep them as they are?"
Good, but this is problematic when the loaded GPX file contains no track <trk>, just a route <rte> with route points <rtept>s, some of which are also listed under <wpt>. It is as if OM does not understand the difference in the GPX specification between <wpt>, <rte>, and <trk>; an impression reinforced by subsequent behaviors of OM.
2. If we then accept 'Reorder', OM shows the distance and bearing not to the route start (the first <rtept>, where of course we want to start navigation) but to whichever <wpt> was listed first (commonly the first one in alpha-numeric sequence, which might be anywhere along the route). OM previous/next waypoint functions do work correctly from here, but it is not where we planned to start navigation.
3. If we then use 'Route > Navigation options > Stop waypoint navigation', followed by 'Route > Navigation options > Follow route', OM does start at the first <rtept>, complete with pink arrows along the direct route towards the second <rtept>. Great, but why not do this in 2 (above)?
4. If the GPX route contains <rtept>s that are used uniquely to determine route geometry (and not saved for other uses as user waypoints, thus GPX <wpt>s), these are not included by OM in the route. OM seems not to understand (or not to respect) the GPX concept of a route.
I am sure that problem 2, can be overcome by more fancy coding, but why not just respect the GPX specification (https://www.topografix.com/GPX/1/1/)? After all, the GPX specification was created explicitly to facilitate sharing of GPS information between GPS (or GNSS) programs and users. In other words, for route navigation, why not use the GPX <rtept> list that was created in the correct order for this purpose, instead of attempting to work around the (explicitly unordered) <wpt> list that was created for other purposes?
In traditional (and GPX) (https://scithings.id.au/GPS_Terminology.pdf) usage, 'routes' are sparse collections of waypoints indicating a path to be followed. Typically, only key locations such as turning points are included, so routes tend to contain few data points (route points or via points). The human brain fills in the details, depending on topography, weather and other conditions in effect at the time of navigation. Some developers distinguish between (i) shaping points used only to help define the route and (ii) {user} waypoints kept for additional purposes. In GPX files, any <rte> is generally named, as is any <rtept>. But those distinguished as 'shaping points' generally are not listed as <wpt>s. This is also variable in other file formats or in GPX files from format converters. Waypoints may be sorted or listed under <wpt> in various orders (eg alpha-numeric). In the GPX specification, the <wpt> list explicitly is unordered (ie there is no specified order or means of sorting). In contrast, route points should always be listed (under GPX <rtept>) in their sequence in the corresponding route.
In traditional (and GPX) usage, a 'track' started as a collection of waypoints defining a path that had been followed. Because such paths were often recorded at short intervals for accuracy, tracks typically contained many data points (track points). Thus <trk> may be distinguished (from <rte>) as a complex series of points that define the detailed geometry of a path. In GPX files, any <trk> is generally named and includes one or more segments <trkseg>; but <trkpt>s (always listed in sequence along their path) are generally not named, and they need not appear in the <wpt> list. As software was developed to follow a path on a (digital) map, and to plan a journey given a complex set of alternative paths, the concepts of track and route became less distinct. With such software, any path (even a track with complex geometry) could fairly easily be navigated. But navigating (or planning to navigate) a track does not make it a route. Both concepts are useful (especially for off-track hikers), and they should be kept different. For example, it would rarely make sense to distinguish 'direct' navigation of a track.
I understand that OM uses its own 'twist' on the wpt-trk-rte paradigm (which does create challenges for GPX export, but that is another issue). And some programs do export so-called GPX files that do not follow the GPX specification. Nevertheless, if any program imports GPX files for the purpose of navigation, it behoves that program to respect the GPX specification in the interpretation of those GPX files for the purpose of navigation. For example, OM may not create <rtept>s that are not listed (and sorted) as <wpt>s; but it should respect such points in a GPX file imported for navigation. Perhaps this would be easier if OM used a term other than 'waypoint navigation' for 'direct navigation'.
Hello!
Over the last 20 years, I've received thousands of GPX files with all sorts of variations—believe me.
I've tried to align with the most common practices, setting aside the official standard—which even Garmin doesn't always follow. This approach has saved me from having to answer countless emails asking for explanations.
For instance, regarding routes: the `rtept` element holds the same content as the `wpt` element. Consequently, it's common to see GPX files where routes contain `rtept` entries—listing waypoint data in the intended sequence—without duplicating that same information in a separate, unordered `wpt` list. I hadn't encountered that before.
It's also very common to find lists of `wpt` elements without any `trk` or `rte` data, implying that the order of appearance was significant.
Since the order of waypoints in the GPX file has always mattered (at least throughout the app's 17-year history), I didn't want to disrupt established user habits by adding a prompt asking whether to reorder them.
That version has a bug where it keeps the original first item in the list as the starting waypoint, but this will be fixed in the next release. In the meantime, you have to manually switch to your desired starting point.
orux
Thank you Jose. The history of OM is important, and can be built upon to get even better.
I can see that OM 12.1.0 correctly starts at the beginning of the route. I hope that you will think more about the GPX specification for later improvements.
OM can make a file for export of a route, and another program can make a file with a very different <wpt> list for export of the same route; and both may be GPX compliant. The GPX specification does not specify which (if any) waypoints must be included in the <wpt> list; it is up to the file creators, who have different ideas. Therefore the <wpt> list in imported GPX files should not be relied on for route navigation.
But the GPX specification does specify that all waypoints used in a route must be listed (in route order) in the <rtept> list. Therefore the <rtept> list in imported GPX files can safely be relied on for route navigation.
Take the example of a GPX-compliant route exported from Garmin BaseCamp. The <wpt> list includes "user waypoints" saved for other uses, but not "shaping points" created only for use in that route. All are included, in route order, in the <rtept> list. OM will import the route from the GPX file and display the path correctly on screen (passing through all <rtept>s including the "shaping points"). But if OM is used for direct navigation of the route, the "shaping points" will be skipped (without warning). This is incorrect and potentially dangerous. It can easily be corrected to improve OM. Just use the <rtept> list for direct navigation of imported GPX routes, as already used for route display.