KML with space around tuples separator considered invalid

[strk]

I've been told ogr2ogr is unable to read this KML: ​http://firms.modaps.eosdis.nasa.gov/active_fire/kml/Europe_24h.kml

Full discussion about this from the PostGIS side (which was also bogus, and now fixed): ​http://trac.osgeo.org/postgis/ticket/2372

Note that according to the NASA data download site the KML is perfectly readable with google earth: ​http://earthdata.nasa.gov/data/near-real-time-data/firms/active-fire-data#tab-content-2

[Even Rouault]

The file is broken in many aspects.

It advertizes UTF-8 but has non UTF-8 characters, which cause the Expat parser to stop the parsing.

$ ogrinfo Europe_24h.kml 
ERROR 4: ERROR Parseing kml Europe_24h.kml :not well-formed (invalid token) on line 13 at offset 165
ERROR 4: ERROR Parseing kml Europe_24h.kml :not well-formed (invalid token) on line 13 at offset 165

$ xmllint Europe_24h.kml
Europe_24h.kml:13: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xA9 0x2B 0x2D 0x30
A[ Latitude :       48.532 <br> Longitude :       34.655<br>Date Acquired : 2013
                                                                               ^

And as far as spaces are concerned, according to ​https://developers.google.com/kml/documentation/kmlreference?hl=fr#point, "Do not include spaces between the three values that describe a coordinate."

One could expect NASA to be able to produce valid KML files...

So I would consider this as a "wontfix"

[strk]

One could expect Google software to be used as "reference implementation" for reading Google formats, don't you ? In other words, do you prefer GDAL to be unable to read a file that Google Earth can read ? As a user, I'd feel inclined to consider GDAL (and PostGIS) "bogus" (for right or wrong). How about just raising a WARNING ?

Be conservative in what you do, be liberal in what you accept from others ... ref: ​http://en.wikipedia.org/wiki/Robustness_principle

Maybe not to be called "defect" but "enhancement" ?

[Even Rouault]

The "old" KML driver is more or less in low maintenance mode, but if someone wants to take a crack at that, without breaking the parsing of <coordinates> with several tuples, but I'd be with Olivier that it is a slippery road...

The new LIBKML one based on libkml seems to be OK with spaces around the comma for a Point (the parsing of coordinates is done by libkml itself). As far as the UTF-8 issue is concerned, not much can be done unfortunatelly.

[Even Rouault]

Sandro, you may have a look at #4347 where it is stated that versions of Google Earth >= 6.1 no longer handle coordinates with spaces before/after commas. So I suspect the version of Google Earth that was used to read Europe_24h.kml is older than 6.1. In which case, we should really close this ticket as wontfix.

[Kyle Shannon]

Even, I just tried reading it with Google Earth 7.1 and 7.0, and it worked. I suspect that they broke a lot of kmls and went back to the lenient parsing. I don't have a 6.x to test on though.

[Jukka Rahkonen]

Google Earth 7.3.0 opens faulty KML files. Here is another reference which states that spaces are not allowed, the OGC KML 2.3 standard ​http://docs.opengeospatial.org/is/12-007r2/12-007r2.html

A singlespace separates the tuples and commas separate the ordinates.

Reading libraries could be lenient but based on the missing activity here and on a mailing list archive review this is probably not a big problem for the users.

[Even Rouault]

If someone wants to fix that, they could propose a patch to libkml ​https://github.com/libkml/libkml