ogr2ogr, shp > KML: schema validation fails

[peifer]

$ ogr2ogr --version
GDAL 1.6.0, released 2008/12/04

$ ogr2ogr -f KML -t_srs EPSG:4326 -fid 0 test0.kml RBD_F1v3.shp

$ iconv -f ISO-8859-1 -t UTF-8 test0.kml > t1 && mv t1 test0.kml

$ xmllint --noout --schema http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd test0.kml

test0.kml:4: element Schema: Schemas validity error : Element '{http://www.opengis.net/kml/2.2}Schema': This element is not expected. Expected is one of ( {http://www.opengis.net/kml/2.2}visibility, {http://www.opengis.net/kml/2.2}open, {http://www.w3.org/2005/Atom}author, {http://www.w3.org/2005/Atom}link, {http://www.opengis.net/kml/2.2}address, {urn:oasis:names:tc:ciq:xsdschema:xAL:2.0}AddressDetails, {http://www.opengis.net/kml/2.2}phoneNumber, {http://www.opengis.net/kml/2.2}Snippet, {http://www.opengis.net/kml/2.2}snippet, {http://www.opengis.net/kml/2.2}description ).

test0.kml fails to validate

OK. I fixed this one by putting the Folder element in the right place, see attached. But then I ended up with:

$ xmllint --noout --schema http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd test0.kml

test0.kml:67: element Style: Schemas validity error : Element '{http://www.opengis.net/kml/2.2}Style': This element is not expected.
test0.kml fails to validate

Am I doing something wrong here, or why does the KML file not validate against ogckml22.xsd ?

Hermann

[warmerdam]

Chris?

[condit]

Ahhhh I see the problem: the Style is out of order with the Geometry. In the original Keyhole schema this ordering didn't matter (as I recall). This problem is solvable with the current code base.

The other problem (with folders) is directly related to ticket #2772. Because we don't have access to the layers before we write them, I just put the schema inside the Folder element. As with #2772 the real solution is to switch to libkml, which I still haven't had time to finish up.

I should note that despite the lack of validation Google Earth will still display the file, but I agree that OGR output must validate...

[peifer]

Replying to condit:

I should note that despite the lack of validation Google Earth will still display the file, but I agree that OGR output must validate...

Indeed: Google Earth is somewhat more forgiving than xmllint's schema validation. Thanks for keeping an eye on this issue.

[peifer]

Replying to condit:

Ahhhh I see the problem: the Style is out of order with the Geometry. In the original Keyhole schema this ordering didn't matter (as I recall). This problem is solvable with the current code base.

Just a thought: Is the Style element needed at all?

I am currently fixing the Style-related validation error with a simple

grep -v Style non_valid.kml > valid.kml

[condit]

Replying to peifer:

Just a thought: Is the Style element needed at all?

The default look for a polygon in GE is an all white fill which doesn't look so nice. Technically we don't need the Style element and everyone should concoct their own styles but I think many people are rather lazy about that and just want something that will look a little better (in this case a red border). Just out of curiosity, what method would you like to use to style KML documents stemming from an OGR transform?

In any case I modified the trunk s.t. the Style element now comes out before the Schema elements. So that piece should be resolved. The other piece, however, will have to wait until I get the libkml in place...

[warmerdam]

Chris,

Is there any reason not to push r16454 into 1.6 branch as well?

[condit]

Replying to warmerdam:

Is there any reason not to push r16454 into 1.6 branch as well?

No. The change is minor (just adjusting the location of the Style element) and it improves the validity of the KML output.

[peifer]

Replying to condit:

The default look for a polygon in GE is an all white fill which doesn't look so nice. Technically we don't need the Style element and everyone should concoct their own styles but I think many people are rather lazy about that and just want something that will look a little better (in this case a red border). Just out of curiosity, what method would you like to use to style KML documents stemming from an OGR transform?

To be honest: what I expect from an OGR transform is well-formed, and ideally: valid XML. I wouldn't expect you to guess my style preferences. So no Style element would be pretty OK for me.

[condit]

Replying to peifer:

Replying to condit:

The default look for a polygon in GE is an all white fill which doesn't look so nice. Technically we don't need the Style element and everyone should concoct their own styles but I think many people are rather lazy about that and just want something that will look a little better (in this case a red border). Just out of curiosity, what method would you like to use to style KML documents stemming from an OGR transform?

To be honest: what I expect from an OGR transform is well-formed, and ideally: valid XML. I wouldn't expect you to guess my style preferences. So no Style element would be pretty OK for me.

Right. I put it in originally for people who wanted to get started quickly s.t. they didn't need to do any extra steps to consider their KML ready. The "correct" thing to do would be to put out a Style element honoring any OGR Feature Style information. I'd also like to get that done with the new libkml driver...

In the meantime, Frank, should we remove the Style element from the KML output? It means that the elements will come out as opaque white polygons and people will need to perform some styling of their own to make the output "pretty".

[warmerdam]

I have replicated the style ordering fix in 1.6 branch as well (r16459).

I think producing moderately useful default styles is helpful and I would prefer to make supressing <Style> an option with the default being to include something helpful.

[Jukka Rahkonen]

Perhaps these schema errors have been corrected later, GDAL having a badge: "OGC KML 2.2.0 (Official Reference Implementation)"

​http://www.opengeospatial.org/resource/products/details/?pid=1218

[Even Rouault]

With the provided output file used as an input of ogr2ogr, KML validation succeeds.

ogr2ogr -f kml out.kml test0.kml xmllint --noout --schema ogckml22.xsd out.kml