Opened 13 years ago

Closed 7 years ago

#2858 closed defect (fixed)

ogr2ogr, shp > KML: schema validation fails

Reported by: peifer Owned by: condit
Priority: normal Milestone:
Component: OGR_SF Version: 1.6.0
Severity: normal Keywords: KML
Cc: warmerdam

Description

$ 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

Attachments (1)

test0.kml (551.2 KB) - added by peifer 13 years ago.

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by peifer

Attachment: test0.kml added

comment:1 Changed 13 years ago by warmerdam

Cc: warmerdam added
Component: defaultOGR_SF
Keywords: KML added
Owner: changed from warmerdam to condit

Chris?

comment:2 Changed 13 years ago by condit

Status: newassigned

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...

comment:3 in reply to:  2 Changed 13 years ago by 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.

comment:4 in reply to:  2 ; Changed 13 years ago by 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

comment:5 in reply to:  4 ; Changed 13 years ago by 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...

comment:6 Changed 13 years ago by warmerdam

Chris,

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

comment:7 in reply to:  6 Changed 13 years ago by 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.

comment:8 in reply to:  5 ; Changed 13 years ago by 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.

comment:9 in reply to:  8 Changed 13 years ago by 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".

comment:10 Changed 13 years ago by 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.

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

comment:12 Changed 7 years ago by Even Rouault

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.