ogrmerge doesn't support layer or dataset style tables

[jidanni]

What is the bug?

We trust ogrmerge to just merge the KML that has been handed to it.
Alas, it wipes out the entire

   <Style id="randomColorIcon">
      <IconStyle>
         <color>ff00ff00</color>
         <colorMode>random</colorMode>
         <scale>3</scale>
         <Icon>
            <href>http://maps.google.com/mapfiles/kml/pal3/icon21.png</href>
         </Icon>
      </IconStyle>
   </Style>

section.

What's even more nefarious is that other styles aside from IconStyle survive. And of course it all depends on -f LIBKML. If one uses -f KML even more damage is done.

Steps to reproduce the issue

Here's your sample file,
https://developers.google.com/kml/documentation/kmlreference#example_7
Run ogrmerge on it.

Versions and provenance

ogrmerge --version
GDAL 3.9.3, released 2024/10/07

Additional context

Yes, this will have to wait until LIBKML supports Iconstyle I suppose.

But in the meantime promenet warnings that something has been wiped out should be emitted and documented.

I mean it currently makes plenty of

Warning 1: The output driver does not natively support DateTime type for field timestamp. Misconversion can happen. -mapFieldType can be used to control field type conversion.

but not a peep about it running off with that style declaration.

What's worse, during testing I thought I could trust it, as my LineStyles sailed through unscathed. Little did I know that it had a special diet...

Oh well, looks like I'll have to merge my KML by hand from now on.

I mean some people want to merge some KMLs that were made by other programs.
Perhaps it could just close its eyes and just merge it without censoring it.

https://gis.stackexchange.com/a/37221/77230 I suppose is not safe either.

OK, I made a workaround:
mr.gz

[rouault]

What's worse, during testing I thought I could trust it, as my LineStyles sailed through unscathed.

I highly doubt you got better luck with LineStyle. Trying with https://developers.google.com/kml/documentation/kmlreference?hl=fr#example_12 that doesn't work either. ogrmerge, and more fundamentally the OGR VRT format that is used underneath, have currently no support for storing style tables.

[jidanni]

Actually these commands will never be safe if they (silently) throw away things they don't understand.

Because newer versions of KML (coming out of Google headquarters) will always have new features they don't understand.

But there is hope on the horizon: these commands need to have an attitude change: pass things they don't understand through, unscathed.

Oh, and the <LineStyle> stuff it seems I managed to smuggle through,
hidden in the <Placemark>s themselves.

      <Placemark id="SELECT.1">
        <name>tai8to4corners</name>
        <Style>
          <LineStyle>
            <color>ff0000ff</color>
            <width>8</width>
          </LineStyle>
        </Style>

[jratike80]

Because newer versions of KML (coming out of Google headquarters) will always have new features they don't understand.

From https://developers.google.com/kml/

KML is an international standard maintained by the Open Geospatial Consortium, Inc. (OGC).

The latests standard version is 2.3, 2015-08-04, but the latest OGC test suite is still for version 2.2. I feel that it is unlikely that KML will get much new features any more from Google or elsewhere.

[jidanni]

Well that website says

Future versions may be harmonized with relevant OGC standards that comprise the OGC standards baseline.

So therefore there will be future versions!

[rouault]

there will be future versions!

I won't hold my breath for too long on this.... especially since Google dropped maintenance of libkml and no one is maintaining it anymore