Opened 8 years ago

Closed 4 years ago

#5140 closed enhancement (wontfix)

KML with space around tuples separator considered invalid

Reported by: strk Owned by: warmerdam
Priority: low Milestone:
Component: OGR_SF Version: unspecified
Severity: normal Keywords:
Cc: Kyle Shannon


I've been told ogr2ogr is unable to read this KML:

Full discussion about this from the PostGIS side (which was also bogus, and now fixed):

Note that according to the NASA data download site the KML is perfectly readable with google earth:

Change History (8)

comment:1 Changed 8 years ago by Even Rouault

Resolution: wontfix
Status: newclosed

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, "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"

comment:2 Changed 8 years ago by 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:

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

comment:3 Changed 8 years ago by Even Rouault

Priority: normallow
Resolution: wontfix
Status: closedreopened
Type: defectenhancement

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.

comment:4 Changed 8 years ago by Kyle Shannon

Cc: Kyle Shannon added

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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.

comment:7 Changed 4 years ago by 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

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.

comment:8 Changed 4 years ago by Even Rouault

Resolution: wontfix
Status: reopenedclosed

If someone wants to fix that, they could propose a patch to libkml

Note: See TracTickets for help on using tickets.