GPX Versions 1.1 vs 1.2 for Garmin Visually Explained

[Guzzist]

@Mzokk ...I know about this text file to define colours and width of tracks and routes.
That's what I would love to have it in MyRouteApp too

[Mzokk]

@John-S-Parry

Hi John you just keep doing what works for you, but for the potential benefit of others, let me outline a real worked scenario, such that if you used OSM for planning and Here for navigation on a Garmin device you would get unexpected results.

I was making some routes for trip to Spain a few years ago when I happened upon a wonky piece of Garmin "Here" mapping on Basecamp.

This is the offending bit of road. Tried to route past it and the route was doing a massive detour to get to the other side of the (non existent) gap!

Road looks absolutely fine on google street view.

To make the route run as intended you need to put a section of direct navigation in the route to cover the mapping defect.

If you were using MRA for route creation you'd achieve the same effect by using the little Skip Icon.

This allowed the route to be completed.

If you had used OSM to plan the route in this scenario then tried to run it on a Garmin Zumo you'd wonder why the massive detour. This isn't an isolated case I've found (and reported) several such breaks usually on minor roads, in Ireland, central Scotland and rural France.

With regards to the RUT behaviour. I've used Garmin GPS devices since buying a Streetpilot 2610 in 2004 and still run a Zumo 390 and 340 on my venerable BMW R1150GS. I never joined any navigation forums until my wife bought me a ZumoXT as a retirement present. I could not understand how routes I had run on previous devices were now doing very odd things including trying to take me back to previously passed or missed shaping or skipped, via points RUT behaviour. Why was this? Well Ireland is covered in lots of very narrow meandering single track roads, which are the sort I prefer to ride on. Because of this routes have to have lots of shaping points as with the more recent Garmin navigators you are constantly fighting the internal routing algorithm to get the Zumo's to navigate minor roads. In addition, many of my routes contain optional loops to allow for slower than intended progress, for whatever reason, which means that via points and shaping points are often skipped. If you navigate this way on a Zumo XT, without using saved routes and allowing route recalculation, you'd be surprised at how often RUT behaviour can be observed. The only cure for this is to stop and restart the route. This behaviour was never present in any of my previous Garmin GPS units. The XT also led me here and I don't use it for navigation anymore, only to display a track of the route to enable me to use custom proximity alerted POI's during "Free Rides" and as a backup should anything go wrong with the phone I use for navigation on my Honda's built in AA/CP screen. I use the navigation app.

I do like Open Street maps and have used them in Garmin devices in the past and if I'm using those I also use them for route planning. I also subscribe to OSMand+ and use it occasionally for motorcycling but mostly for hillwalking and cycling. What I do like about it for motorcycle navigation is that you can set a proximity value (I use 150ft) within which the track you are navigating will snap to the road. This makes it more fault tolerant of the mapping used to create the track in the first place. I don't like its handling of via points and map markers for motorcycling however.

With regard to navigation I didn't get my first GPS until I was 43, 22 years ago and that was a revelation having toured most of Europe with maps. I also acted as a Co-Driver/navigator for several years in my 20's doing mostly night time regularity rallies. But that was all analogue, maps, road books and stopwatches.

[Carl Lee]

OSM Maps - well I'm a little surprised. Not being happy without a test, I planned a roue on MRA with OSM as the base map. The shaping points were placed on the OSM roads and did differ from the HERE overlay and base map on several occasions. Nevertheless, I went with it. And surprise, it calculated in Tread almost instantly in both 1.1 & 1.2, likewise on the XT2.

My XT2 also has OSM as well as HERE maps in 'detailed maps' so perhaps not such a surprise. Live and learn but what to do now? MRA does state OSM is the default base map and I believe that is all you get on the free version.

@mzokk, I'm wondering if in your above example, the OSM maps would not have had the break in the road in the first place?

Road Closures GPX1.1 v GPX1.2

Another little simulation (Traffic enabled):

GPX1.1 with multiple shaping points navigates round the shown road closure and back onto the original track/route - not just to the next via point. Nice.

GPX1.2 - the mapping shows the closure and there is no route recalculation but then the XT2 totally ignores it and rides through it. To some, this may be preferable as you can then navigate your own way round. I've had to do this many times anyway, usually in parts of Europe where the closure wasn't notified and you're just left to figure your own way around with no diversion signs. So not a showstopper but not as good.

Once again I'm left to ponder which way to go on this.

[John S Parry]

@mzokk Interesting scenario that you outlined. I've experienced some really strange HERE routing behavior (on both Routeplanner and BC) but a gap like you showed has never been one of them.

To your point, if using MRA Routeplanner (OSM map), I would not have seen this HERE map gap, and I would have been surprised with a messed-up route calculation with a direct transfer to the Garmin GPS side.

Except that I've adopted a very specific process to avoid these kinds of inevitable surprises. When creating MRA 1.1 routes, my first step is to always import into Basecamp for HERE verification. It's much easier to analyze/diagnose strange situations in BC than to do the same in the XT. I know that the XT doesn't have the exact same Garmin calculation algorithms as BC, but they're close enough to catch many HERE errors.

So back to your scenario...... In BC, I'd quickly see what you outlined and conclude a HERE mapping error. I'd go back to Routeplanner, use the "Skip" function as you described, and perform the BC verification step again. When satisfied with the fix, I'd import the MRA GPX 1.1 file into my XT and verify after recalculation. All would be good, and life would continue.

Using a 1.2 GPX file would have avoided much of this drama, and it's one of the reasons I'm going to adopt 1.2 until something happens to convince me otherwise.

As a final note regarding RUT. Again, I don't dispute that the phenomena exists. But it's not something I've personally experienced. I've always thought that it must have something to do with geography/terrain differences across the planet. The US has a much different road infrastructure than Europe, so maybe that accounts for our respective different experiences.

[Mzokk]

@Carl-Lee said:

@mzokk, I'm wondering if in your above example, the OSM maps would not have had the break in the road in the first place?

Hi Carl, that's exactly my point, the fault would not have been evident in OSM, BUT the Here maps were on the device so the route would have recalculated as the device would have seen the gap in the mapping and screwed up the route.

@John-S-Parry said:

Using a 1.2 GPX file would have avoided much of this drama, and it's one of the reasons I'm going to adopt 1.2 until something happens to convince me otherwise.

Unfortunately the XT units do not play nicely with GPX 1.2 unless you switch recalculation off. Its good that the XT2 and 3 handle this much better but as I said I just plan most of my Routes on MRA route planner (the USP for me is that it's easy to use on the road) and just use the navigation app now. That means its WYSIWYG and there is no requirement to account for the vagaries of the Zumo XT. By the way I still love my Zumo 390 and 340 as their routing algorithm matches Basecamp when the settings are aligned and they also work well with the MRA Route planner. Truth be told, if I'd kept using the old simple units I'd never been tempted to move to phone based navigation.

@John-S-Parry said:

@mzokk Interesting scenario that you outlined. I've experienced some really strange HERE routing behaviour (on both Routeplanner and BC) but a gap like you showed has never been one of them.

I reported this one and its now gone. I also had to report a similar one while planning a route in Scotland's central belt using minor roads to thread a route between Glasgow and Edinburgh, one in the Massif Central on the D62 in France and a couple local to me in Ireland. It appears that these faults occur at the edge of map tiles particularly where a road passes near to a river or railway line. I presume the process of linking the tiles is automated and the computing algorithm can get a bit confused. In Ireland, the most accurate maps are those produced by the Ordinance Survey and Google (I'd say they were on a par). OSM is next with Here maps the least accurate. That said, they are all very usable its just that you find anomalies and out of date bits from time to time as you do on paper maps.

[John S Parry]

@mzokk On the XT/XT3, I have recalculation set to prompted and almost always select NO at decision time. Like with @steve-jarrell, I prefer to manually manage my own off-route scenarios. In experimenting with XT off-route recalculation ON, I haven't encountered anything fatal other that it tries to get you back to the exact point where the off-route began to start with. Where 1.2 does become a problem is where you modify your route with adding another Via Point using either the Search function or Up Ahead. That's easily remedied by instead starting a new route through Seach/Up-Ahead and then restarting your main route with "Closest Entry Point" after reaching the Seach/Up-Ahead destination. I've experimented with this probably a dozen times under slightly different scenarios, and it consistently works.

I understand that you have a different view of things with your route planning to accommodate optional loops and other anomalies. That's cool. But off-route recalculation with 1.2 does work if you understand how it works and the specific scenarios to avoid.

[Mzokk]

@John-S-Parry I've no issue with GPX 1.2 or switching off recalculation. But I can't get it to work with recalculation on, as demonstrated earlier in this thread when I ran a test. It could be user error and if it is I'd gladly hear a remedy as it would be a handier format to use in some scenarios.

[John S Parry]

@mzokk All of my 1.2 testing has been on the XT3. With recalculation ON, it consistently tries to route me back to the point where off-route started. That's what it's designed to do. If your XT isn't behaving the same, please explain what it's doing. I tried to figure that out from your earlier post but couldn't get what was going on.

My XT has been collecting dust for the past 2-months, and it was dead when I brought it out this morning. It's charging now, and I'll do an XT 1.2 off-route test tomorrow and share what happens.

[Mzokk]

That would be brilliant. In my case it was trying to route me half way round the world to get back to the next via point when I didn't take the first turn.

[Carl Lee]

@mzokk but I was wondering if, despite the break in the HERE mapping on MRA, the Zumo would have routed through it anyway. Can you remember if the break was also on the Zumo map? And maybe not such a stupid idea as OSM mapping is one of the detailed maps in the unit. How and why they are used, I do not know.

@john-s-parry during my testing and actually using a GPX1.2 route on the XT2 with auto-recalculation left on, sometimes it requested a U-turn or two if I carried on my diversion before changing its mind and calculating a way to get me back on the route ahead. And sometimes it would just go straight for the up-ahead re-join. It may go for the quickest option and also take into account one-way streets etc.

The only avoid option I have in the Zumo is unpaved roads. Everything else allowed. I hope the XT result is the same but I'm a little dubious.

[Mzokk]

@Carl-Lee said:

@mzokk but I was wondering if, despite the break in the HERE mapping on MRA, the Zumo would have routed through it anyway. Can you remember if the break was also on the Zumo map? And maybe not such a stupid idea as OSM mapping is one of the detailed maps in the unit. How and why they are used, I do not know.

No the Zumo would not have routed through the gap. I was using Basecamp. The map on the unit and the computer were identical. The only way to get the Zumo to route past that section was to put the "Direct" section in.

[smfollen 0]

Being a new guy here, I’ve been mostly quietly following this discussion. I’m going to dare to share a little perspective and some tidbits in the hope that it’s helpful.

With the current state of navigation, we can debate Here vs OSM, tracks vs routes, gpx 1.1 vs 1.2, etc.

There was a time when the world was flat and was lighted each day by Helios who drove a golden chariot across the sky from east to west. Later, the earth began to become round, although it wasn’t circumnavigated until Magellan sailed around it in the early 1500’s. Around the same time, Copernicus proposed that the sun was the center of the universe. Galileo Galilei advocated for Copernicus’ theory in the early 1600’s. That heresy caused him to spend his later years under house arrest. Back then, latitude could be determined from the stars if the night sky was clear but longitude was elusive until clockmaker John Harrison produced the marine chronometer in the mid 1700’s.

GPS didn't become operational until 1993 but wasn't available for civilian use in 1998.

Many of us, at least the older ones like me, used to find our way around with sometimes out of date paper maps.

Today we look at lines on a digital screen and think of them as physical roads. We look at a motorcycle icon on a SatNav and think of it as our current position. We have high expectations for modern electronics. In reality, none of it is exact, although most of it is close most of the time.

Below is a section of road according to a Here map (magenta line), and an OSM map (green line). I traveled that road tracking my position with a zumo XT2 (yellow line) and another GPS tracking device (blue line). Depending on tolerance, we might say that all four lines are “right”. We might also conclude that it is unclear whether any of them are “right”.

A SatNav calculates it position on a periodic (not continuous) basis from time signals sent by satellites. The number of dots on those lines depends on how frequently position is determined and recorded. More dots imply more precision, but that does not assure any greater accuracy. Under the best conditions, those positions are accurate within several feet (a few meters).

In some locations, these four lines might vary more significantly. The vast majority of the time, they are close enough to be useful. On the occasions when they vary enough to be confusing, I try to remind myself, if Magellan managed to figure it out, I probably can too.

Planning and then navigating with the same map, route preference and avoidance settings, and with software / devices using the same routing algorithms is, of course, most likely produce the most consistent results for us, but it’s not always that simple. For various reasons, one might want, for example, to plan with the MRA route planner and navigate with the Garmin zumo.

In the end, we each do what works best for us and adjust as we learn from our experience. There is no perfect answer that works for everyone every time.

A map is an attempt to project, onto a flat surface, the location of physical roads or paths that exist on a portion of the round earth. Modern maps are much better than the ones Magellan had, but they rarely perfect. They are often generated from multiple sources. A given source which is most accurate in one particular area might not be the most accurate in a different area. Here maps are based on multiple, licensed, professionally produced, and government maps. Garmin’s are supplemented with OSM map data [thus the inclusion of both copyright notices on the device info page of a zumo].

Zooming in on a digital map reveals that roads and paths are represented by straight lines.

Each end of each straight line is a point, although the points are typically not visible. It requires more points to represent a curved road and fewer points to represent a straight road. There are also points at intersections.

Separate from those, when we click on a map to specify our desired stops (via points) and and other points we’d like to pass thorough (shaping points) we create “route points". Routing algorithms use the map’s points at intersections to find the best path(s) between our specified route points. Once the route is determined, all of the map’s points along the route can be used to draw the route along the road or path.

If a track is generated from the route, all of the map’s points along the route become track points. If a gpx 1.2 route is generated, those same points become route point extensions (aka hidden or ghost points). Track points and route point extensions are the exact same points. They are formatted and treated differently however. Once generated, a track will never change. If a route is fully recalculated, its route point extensions are discarded – the route is re-calculated using only the available route points (via and, if available, shaping points).

As a result, after import to another device, an MRA exported:

• track, with its many track points, will provide a very accurate representation of the MRA generated route, but it is fixed in place.
• gpx 1.2 route with the user specified via points and the route point extensions matching the track points, will provide the same very accurate representation of the MRA generated route as long as it is not fully recalculated. Unlike a track, it can be amended, to some degree, to support a Closest Entry Point navigation [re]start or an off-route calculation to get back onto the route without triggering a full recalculation.
• gpx 1.1 route with the user specified via and [relatively few] shaping points, but without the benefit of the [many] route point extensions, contains a less accurate representation of the MRA generated route. It will always be subject to route calculation and variation wherever it is imported.
• gpx 1.2 route will be the least accurate if it is fully recalculated since only via points will be available to the routing calculation.