Zumo 595 Problems transferring routes from Google Maps

[SilverCycle]

Hi,

New user here, struggling with our particular variation in this shared minefield... Actually 2 users, pair of us, which explains some apparent odd memory lapses, as we're not telepathic, just married. Although the non-Zumo using half of this couple is XML aware, we would like to end up with a method that can by used by the other half!

Scenario:

• Plan a ride on Google MyMaps, typically 4 hours or less. UK based, so 4 hours can still be quite tangly.

• Export from Google as KML.

• Import into BaseCamp, where it appears as a Track,

• In BC, convert to Route,

• In BC, copy/export (can't remember the term) to the connected Zumo 595's Internal Memory.

• On disconnection and re-powering up, Zumo says it's found things to import and off it goes.

Jolly good. This procedure was learnt from some YouTube video.

A variation of this process is:

• take the KML from Google My Maps,

• convert it online (https://kml2gpx.com/),

• and use Windows File Explorer to drop the GPX onto the Zumo's Garmin\GPX folder,

• disconnect, power up the Zumo,

• Trip Planner -> Tools -> Import -> The named file/thingy

In both cases, the route becomes available in Zumo's Trip Planner.

But Only Sometimes!

Maddening.

When it doesn't work, it's a completely silent failure. No import is attempted or offered. I reckon it succeeds more than 50% of the time, but failures are far from rare.

It seems to be something somehow relating to the content of the GPX file. Likely it's not affected by the import method, but it's interesting that in the first method, it goes through Garmin's Basecamp program just fine.

I have in the past gone through the XML of a failing GPX file and removed from text fields and filenames anything that's not really basic ANSII, as the OH can be a bit punctuation happy (ex English Teacher). No joy. I did once hack out virtually all the navigational points from the middle of the file (probably left a few at the beginning and end, in case they're special), radically reducing the file size, and that worked, although, obviously, not very useful.

I've trawled loads of stuff online, and haven't seen anything suggesting definitive limits that we're falling foul of.

Does anyone have any suggestions how to make use of Google My Maps as a route composition tool, to download the results reliably to Zumo.

One of the failed route files is attached. Irritatingly, this was the return leg, the slightly different outbound trip transferred fine.

For completeness, yes the Zumo 595 is completely up to date as of today. I think I recall the firmware version as 4.60, which Garmin's website says was released in 2019, quite possibly the year it was bought, certainly that won't have been before 2018.

[SilverCycle]

I'm going to add a minor addition, linking other threads as touching on the same subject, tho not this specific issue.

viewtopic.php?t=1138 (oddly, in "Forum Help and Feedback")
viewtopic.php?t=1841&sid=9235ae8ab520fc ... 8&start=20
viewtopic.php?p=11495&hilit=595+import#p11495

In particular, there are suggestions that there are limits such as:

• 29 waypoints max. But Waypoints are particular, named, flagged, points in the map or route, we used none AFAIK.

• Problems if the device has loaded and enabled two maps and your route goes thro areas where they overlap. This includes cases like having a national road map and a more detailed national park map. But we have only the default map and ?default? addition for I think speed cameras.

• Different choices of options between Basecamp and the device.

• Routes where the first part of the name is the same as another - it only looks at the first N characters. Then did even more inconsistent things.

• Apparently we can put an SD card in the Garmin, and it will behave differently, but not necessarily better.

Although reading those has aided my understanding, and I tried something or other, nothing has really been directly relevant yet.

[sussamb]

Routes from 3rd parties often fail on a device. It's always best therefore to import them into BaseCamp, make any adjustments you want and then send them to your device.

[FrankB]

One of the failed route files is attached. Irritatingly, this was the return leg, the slightly different outbound trip transferred fine.

I have checked the attached GPX for correctness. It fails to load in Basecamp/Mapsource because it has a LAT value specified in scientific notation. this is the line in error.
<trkpt lat="51.07507" lon="-6e-05">

If I remove that <trkpt> from the GPX it loads in Basecamp, and maybe in your device.

Difference.jpg (101.01 KiB) Viewed 4622 times

I have attached the corrected GPX.

What to do next? I would say the KML2GPX is causing the error. Maybe you can report the error to them?
alternatively you can try another tool. I suggest you try JaVaWa RtwTool. https://www.javawa.nl/rtwtool_en.html

@SilverCycle If you post your KML file also, I will have a look. Maybe the error is already present in the Google KML file.

[SilverCycle]

Routes from 3rd parties often fail on a device. It's always best therefore to import them into BaseCamp, make any adjustments you want and then send them to your device.

Hi thanks, but I think you missed that we also did do downloads via BaseCamp, and plenty of these fail too.

To be fair, we didn’t try downloading problem routes with both methods, to see if only one failed.

[SilverCycle]

@FrankB, thanks.

The point about scientific notation makes sense. However, it’s interesting to note that you say it fails to load in Basecamp - I only tried this route via the third party convertor.

I’ll have a look at the KML preceding that GPX.

I guess I can manually edit that e notation value to zero. As we are Sussex, many routes will transition longitude zero. I guess Garmin’s test cases don’t include long or lat near zero. Is there a published standard for GPX? However, for family use, systems with such stages aren’t any use.

Workaround is not to shape route near longitude zero.

More usefully, the development team at KNL2GPX might be able to help, I imagine at present they don’t alter XML data content…

[SilverCycle]

Routes from 3rd parties often fail on a device. It's always best therefore to import them into BaseCamp, make any adjustments you want and then send them to your device.

Hi thanks, but I think you missed that we also did do downloads via BaseCamp, and plenty of these fail too.

To be fair, we didn’t try downloading problem routes with both methods, to see if only one failed.

Stop Press: She tells me no, it is Basecamp that barfs in that workflow. So your point is valid, and elaborated by FrankB’s

[FrankB]

I guess I can manually edit that e notation value to zero. As we are Sussex, many routes will transition longitude zero. I guess Garmin’s test cases don’t include long or lat near zero. Is there a published standard for GPX? However, for family use, systems with such stages aren’t any use.

I dont know if Garmin includes test cases near zero for long or lat. But I do know that it's incorrect to specify a Latitude in scientific notation.
Latitude is specified as xsd:decimal. See:

https://www.topografix.com/GPX/1/1/#type_latitudeType

Latitude.jpg (70.71 KiB) Viewed 4508 times

And decimals are specified as:
https://www.oreilly.com/library/view/xm ... /re62.html

Decimal type.jpg (99.63 KiB) Viewed 4508 times

Meanwhile I did a little test with a manually edited KML file. I deliberately changed a few Lat values to scientific notation. The JaVaWa RTWtool mentioned earlier correctly outputs them in a GPX. That is not in scientific notation. So, should KML2GPX not be willing to change, JaVaWa RTWtool is a working alternative.

(And no, I'm not affiliated in anyway with, just a happy user of, JaVaWa)

[SilverCycle]

Thanks all.

Yes, I found some stuff similarly, the GPX standard doesn't support scientific notation, on the reasonable grounds that ordinary decimals number range to six or whatever digits work perfectly well for all earth-bound navigational purposes. I also found a number of other GPX-input-accepting programs having to deal with Google's non-compliant output, which apparently, also affects elevation. Thus Google routes very very close to sea level are also sometimes rejected.

KML2GPX website doesn't appear to offer any way to contact the project, and searching for them on FB leads into an unattractive quagmire of very-similarly-named accounts. Javawa appears to be a still downloadable tool, although no longer supported or maintained (March 2023, I'm writing).

TBH, neither offers an attractive workflow for the not-ex-software-engineer parts of the family, who already struggle with BaseCamp. BaseCamp feels to me more like an in-house-test-tool than a consumer product.

[jfheath]

In my experience and from observations and comments on here and on other forums, people seem to be prepared to put up with a lot simply to avoid using Basecamp. Yet it doesn't take that long to become familiar with how it works.

There are no other tools that I know of that can include Via Points, Shaping Points, Waypoints, Points of Interest in the way that they are expected to be used as well as work with the identical maps that the Zumo uses so that the route doesn't need to be calculated on transfer.

MyRouteApp comes close, but it hasn't got there yet - not for the way that I want to use it - although I have a lifetime subscription.

It's big advantage of MRA is that it is available on portable devices.
The big negative for me is that it needs an internet connection to use it.

----

Basecamp will also import and export many different file formats including KML and GPX

----

The 'standard' for GPX has a common standard core, but it leaves open the option for developers to use their own proprietry tags. These have to be written in a specific way so that any software that doesn't know about them can simply ignore them and load in the rest of the file without it failing.
Most developers use such GPX extensions. Basecamp is pretty good at stripping out any such extension commands in order to produces a file that the Zumo can read.

If you are talking about standard GPX format, that can be found by a simple Google search. If you are talking about the non standard formats, that Garmin uses for soem features. You are on your own - but @FrankB has got further with this than anyone else that have seen.

The scientific notation will typically sacrifice precision in order to extend its range of numbers that can be represented within a fixed number of digits.

Range is not important for lat/lon - the biggest number required is only 180 - but the precision is essential. Typically if you want precision, you wouldn't use scientific notation. That only gives accuracy to n significant figures. Satnavs need accuracy to at at least 6dp. (0.11 metre at the equator). It doesn't need that degree of accuracy, but it needs to retain that degree of accuracy after it has been through the complex caclulations that the satnav has to perform. Typically, in order to retain that degree of precision, a greater degree of precision is required during calcluation. It makes sense to have the price value stored in the first place. This is because multiplying or dividing very large and very small numbers can produce 'interesting' results.
Interestingly, MRA used 6dp for its lat/long coordinates, Basecamp uses 15 !