LIBKML: numerical <name>s trigger <SimpleData>

[jidanni]

What is the bug?

LIBKML_USE_SIMPLEFIELD=YES/NO needs a third choice to prevent any
hijacking of <name> fields.

Steps to reproduce the issue

Currently the only workaround is to make strings out of numbers:

$ ogr2ogr workaround.kml :memory: -f LIBKML -sql \
"SELECT ST_Point(121,24), 41 || '' AS name"
$ grep 41 workaround.kml
    <name>41</name>

Without || '' the <name> tag gets gobbled up into <SimpleData>.

https://gis.stackexchange.com/questions/500530/how-to-stop-ogr2ogr-f-libkml-simpledata

Versions and provenance

GDAL 3.10.3, released 2025/04/01

[jratike80]

With SQL, if you do select 41 you will get a number. If you want to have a string you will do select '41'.

Try

ogr2ogr no_workaround_needed_with_proper_sql.kml :memory: -f LIBKML -sql "SELECT ST_Point(121,24),'41' AS name"

You can check from the KML schema https://developers.google.com/kml/documentation/kmlreference but I suppose that "name" in that place of the KML needs to be a string. At least in some place of the specification I can see
<name>...</name> <!-- string -->

[jidanni]

Well OK, then... ogrmerge should't change it back then. https://gis.stackexchange.com/a/500533/77230

And -f KML will need to be 'fixed' too,

$ ogr2ogr /vsistdout/ :memory: -f KML -sql \
"SELECT ST_Point(121,24), 41 AS name"

makes <name>.

Also https://gdal.org/en/latest/drivers/vector/libkml.html etc. need to document this.

[jidanni]

https://schemas.opengis.net/kml/2.3/ogckml23.xsd :

<element name="name" type="string"/>
<element name="coordinates" type="kml:coordinatesType"/>
<simpleType name="coordinatesType">
<list itemType="string"/>

Anyway coordinates are a string with commas in it, and they go right
into the <Point><coordinates>121,24</coordinates></Point>
So I'm not sure hijacking <name> is justified.

[jratike80]

If KML and LIBKML would have identical behaviours, why would we need them both? Do we need them both at the moment? The one to drop would be KML, or what @rouault

[rouault]

The one to drop would be KML, or what @rouault

if only LIBKML would be properly maintained. I've been aware of efforts made recently to try to revive it, but not sure where thy are. But if they don't succeed, there will be a point where building libkml itself or building against it won't be possible. Anyway isn't KML itself a deprecated tech... ?

[jidanni]

Every <Placemark> on https://developers.google.com/kml/documentation/kmlreference has a <name>. I'd say it's OK to copy <name> for <SimpleData>, but leave it in place unless you get the user's consent via some config option.

[jidanni]

Regarding Simpledata, we read

This is the standard way for KML to handle non-standard fields that are not part of the core KML definition (like <name> or <description>).

Therefore OGR should cease and desist from tampering with standard items the user has SELECTed.