Google Maps engine KML schema validation error

Former Member over 11 years ago

Hi, I'm new to the GPS world and am on a multi year bike trip. I have a Garmin 62s that I am using to route our bike path every day. I have been plotting a course via the google maps engine software (as GM shows dedicated bike paths as well as route elevation (recent update)). I then export this KML and import into Base Camp. Some of my routes import fine and I can make a track and upload to the GPS however 1 out of every three KML files states it's not valid on import and I cannot use it (it wont import). I have compared a base camp acceptable and non acceptable file in a KML validator online and both files give the same warning about tag names, but one works and the other doesn't. I have tried reducing the length of the invalid files but this does not help unless I reduce it to a much smaller distance (than a valid KML file) and then I have 4-5 routes per days cycling which is a bit annoying. I have resorted to letting the 62s route me by setting an address with the device on 'tour cycling' mode, however I want to actually plot my own course along canals etc and this does not seem possible/easy on the device itself and I don't want to have to plot an entire days course manually in base camp. Google maps appears to be an infinitely better way to plot courses.

Has anyone else had any kml validation errors when importing into basecamp and if so is there a way to resolve?

Thanks
Joe

http://www.thelonglongtrip.com

0 Former Member over 11 years ago

I tried this with a very very simple 2 point route and it just worked. (This on a mid-2007, 21.5 inch iMac using OSX 10.9.3 and BaseCamp version 4.3.1)

Perhaps if you posted up a KML that worked and one that didn't someone might be able to assist you.

0 Former Member over 11 years ago

Interesting. I looked at my KML file and the coordinates never had more than 15 decimal places and usually were much less. This looks like a Google coding error to me; they have failed to round properly or bound check their result.

If I have done my sums correctly one degree of distance at the equator is about 416,666 feet. So, with a precision of 6 decimal places we are determining a location within 0.4 feet or about 5 inches. Most of the locations in my KML are only given to 7 decimal places or less. Those longer than that are invariably a string of zeros ending in an integer other than zero.

0 Former Member over 10 years ago

Hi Joe,

I am not familiar with the Base Camp at all, but I am familiar with KML and programming. So let me help you

and google maps engine seems to be spitting out KML coords with letters in them... Im not sure if this is correct KML or not?

Coordinates with letter are coordinates recorded in the exponent number format, and 1.2000000000000002E-4 means 0.00012000000000000002.

The KML is correct. Actually,

The current KML standards say very little about coordinate validation. In particular, there is nothing about count of decimal digits or number format there. So, the KML is formally correct.
Applications usually process coordinates in exponent format correctly. For example, Google Earth does and, moreover, saves coordinates with absolute value below 0.00001 (i.e. 1E-5) in the exponent form.

Most probably, your Base Camp is unable to recognize coordinates given in the exponent form. If so, this is a software bug, and the only thing you can do is to wait until this bug is fixed in a newer version. Another way is to use tracks, waypoints and routes in GPX format that is brilliantly supported by your 62s.

Hope this will help. Best wishes from Moscow to northern London! :)

0 JaVaWa over 10 years ago

0.00012000000000000002

At that latitude 5 decimals give you a location within about a metre, so Google Maps is using a precision of 1 femtometre; that's about the radius of a proton.
Does not make sense...
Yes, I know the cause, but they really should round the value to 6 or 7 decimals, instead of putting bogus values into the kml file.

0 Former Member over 10 years ago

You are right, getting this trailing digit of "2" depends on the number format (4, 8, 10 bits etc.) used to read a number from a file.

However, as it seems to me, the problem described by Joe is caused by the BaseCamp app that is unable to read a correct number given in the exponent form.