GPX Versions 1.1 vs 1.2 for Garmin Visually Explained

[John S Parry]

@Marinus-van-Deudekom said:

This whole topic is about getting routes into Garmin devices. Garmin uses Here as road map. Its a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices.
Im certainly not stating that the Here map is perfect. Far from that BUT it's the map Garmin uses.
If you want to use OSM be my guest.
By the way my Garmin devices are all sold
Im a MRA RouteXpert so yes I'm promoting MRA. Is it perfect no but pretty damn near close and as far as I'm concerned the number 1 app to navigate with.

If "it's a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices", where is the documentation? Proven facts are usually outlined somewhere for public consumption. This is the second time you've made this assertion, but again provide no context to what "causes problems" means. We all want to learn, but simply throwing out assertions that fly in the face of what others have actually experienced is not helpful.

But I'll take a stab at what you're trying to communicate. If in Routeplanner you create a route using OSM or TomTom, and in that route you minimize the use of shaping points and instead allow OSM/TomTom to make route calculation decisions for you, problems may in fact occur on a Garmin. You're then allowing Garmin, which has different route calculation algorithms, to possibly choose different paths between Via Points. I'd argue that the problem is more with the route creator than with OSM/TomTom. If you're actually talking about something else, please bring some substance that would be helpful.

[John S Parry]

@steve-jarrell I want to take this opportunity to again thank you for what's essentially been a tutorial on the GPX 1.2 format. I feel like a kid at Christmas. I'll never go back to 1.1 format routes again.

With all the dismissive talk about using OSM as the base map, I created a quick route riding the bad HERE cartography road section I outlined earlier. The route I created was with OSM and saved in the 1.2 format.

I imported the route manually into my XT3 without issue. The link to the route is below:

https://www.myrouteapp.com/route/open/14129162

I proceed to ride the XT3 route for educational purposes. It ran without ever triggering the off-route recalculation dialog box, which it did running under 1.1 HERE. The XT3 clearly showed me riding the track of the real path alongside the HERE mapped road that was in the wrong location. It was fun to watch and spoke to the sophistication of the 1.2 format.

Thanks again!

[Steve Jarrell]

@John-S-Parry You're very welcome. Hopefully I have helped others here just a little just like many others have helped me!

We're all learning constantly (otherwise we wouldn't be here!) and the knowledge that we gain from our collective experience and viewpoints benefits all of us!

[Mzokk]

@John-S-Parry said:

@Marinus-van-Deudekom said:

This whole topic is about getting routes into Garmin devices. Garmin uses Here as road map. Its a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices.
Im certainly not stating that the Here map is perfect. Far from that BUT it's the map Garmin uses.
If you want to use OSM be my guest.
By the way my Garmin devices are all sold
Im a MRA RouteXpert so yes I'm promoting MRA. Is it perfect no but pretty damn near close and as far as I'm concerned the number 1 app to navigate with.

If "it's a known and multiple proved fact that routes created with OSM or TomTom cause problems on those Garmin devices", where is the documentation? Proven facts are usually outlined somewhere for public consumption. This is the second time you've made this assertion, but again provide no context to what "causes problems" means. We all want to learn, but simply throwing out assertions that fly in the face of what others have actually experienced is not helpful.

But I'll take a stab at what you're trying to communicate. If in Routeplanner you create a route using OSM or TomTom, and in that route you minimize the use of shaping points and instead allow OSM/TomTom to make route calculation decisions for you, problems may in fact occur on a Garmin. You're then allowing Garmin, which has different route calculation algorithms, to possibly choose different paths between Via Points. I'd argue that the problem is more with the route creator than with OSM/TomTom. If you're actually talking about something else, please bring some substance that would be helpful.

Interesting discussion so far. With regard to the point above I'd have to concur with @marinus-van-deudekom. If you use the OSM or Tom tom mapping on a Garmin Device using Here mapping you may get unexpected results. This is because the road lines are projected in slightly different ways depending on the map set.

.

This is not a good example, but you can see that the map road lines don't quite line up. This is a google maps underlay with Here (black), TomTom red, and OSM blue road lines. The divergence is not bad in this example but I have encountered bits of road where the divergence is 10-15M. This can cause a problem particularly if a waypoint is inadvertently placed on the opposite carriageway because of map differences, or occasionally the route might direct you down a track you don't want to be on as OSM and Here categorise what constitutes a "Road" slightly differently :D. or you might have the occasional turn up a sideroad that is unintended. These issues are not serious but could be irritating. Long story short you will get better results if you use the map set that matches the maps on your device.
When I used my Garmin devices for navigation I often used OSM maps to keep old discontinued units for which Garmin no longer produce mapping up to date, and to make maps for places like Canada and the US, for which I had no mapping.

A write up I did explaining this can be found here.

https://www.ukgser.com/community/threads/using-open-street-maps-on-old-and-new-garmin-devices.439311/

Finally I notices a post on FrankB's excellent trip planner tool. This is indeed good but its use is dependant on having access to a computer to turn the routes on a Zumo XT to saved routes. There is another way to do this on the device itself. I take no credit for this Oop North John on the Zumo website discovered this. Basically if you have an imported route and you want to make it into a saved route to avoid potential RUT issues do this.

1. Send the calculated route to the XT

   2. Open it up in the Trip Planner

   3. Select Go!

   4. Select the next via / way point, then Start

   5. Then go back into Trip Planner

   6. Select Saved trips

   7. Select My Active Route and Save it. Unfortunately the original name is lost, but c'est la vie

   8. Then select the trip you just saved in the Saved Trips area

Again interesting thread which hopefully we will all learn from. That said if MyRoute app POI track handling was more functional I'd have no use for my Garmin devices at all.

[John S Parry]

@mzokk Thanks for your comprehensive response. You clearly have a grasp of "in the weeds internals" that I don't possess. I'm more of a "test and observe" kind of route planner. I look for instances of repeated routing behavior (both success and failures) across different terrain scenarios. I have multiple IBA (Iron Butt Association) awards where routing precision and mapping accuracy couldn't be compromised. I also lead multi-day rides across technical terrain in the US with very experienced riders who will not tolerate following "bad" routing. I bring this up not to beat my chest, but to indicate my required standards for building routes.

With respect, your response is filled with a lot of "ifs, and buts". I'm not challenging what you presented as anything other than real possibilities. What I am saying is that in my years of creating hundreds of routes using OSM for export to Garmin devices (XT, XT3) I have never encountered any of the behaviors you outlined. I wish I had so that I could pick your brain for further understanding.

I'm glad that you brought up the Zumo XT Forum. It's probably the best resource for learning everything XT out there. The main characters in the forum are incredibly knowledgeable. "jfheath" in particular has been very helpful in my XT learning journey. But even there, I sometimes scratch my head with some of the XT behaviors discussed. I have personally never experienced the infamous RUT behavior. That's over a 5-years period of continuous XT/XT3 route planning. Ironically, if you read through the forum, a couple of the regulars have sheepishly admitted they haven't experienced the behavior either. Again, this isn't questioning that it can happen, but it's clearly not a global pervasive problem.

Going back to HERE, I agree that in a perfect world that you would use the same maps for development that are used in execution. So within MRA, why not just use HERE?

If you didn't see my discussion on HERE map inaccuracies, start with the route below:

https://www.myrouteapp.com/route/open/14129162

Open this OSM route up, and compare with HERE. You'll quickly see that the HERE cartography has the road deviating in a completely wrong location. I can't imagine a more serious vendor map sin than not getting a road location right. Beyond this specific HERE snafu, there are several other MRA HERE flaws that I find unacceptable:

1. Too much of a lag time in recognizing closed roads that are now open.
2. Showing roads open that have been closed sometimes for years.
3. Calculating random route off/on deviations where the Freeway/Interstate continues straight, sometimes for hours.
4. I can go on, but I'll spare you.....

Given all this, for me, it's a matter of picking your poison. I can use HERE for development and know I'll get randomly tripped up, probably at the most inopportune time. Or instead use OSM, which has proven through extensive actual use to be reliable.

Just my thoughts on the matter.......

[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.