Problem with gzipped KML files (GDAL 2.4.2 and 3.0.1)

[simoneves]

Raleigh_Stops.kml.gz
I have a couple of KML files which were received in gzipped form, with a .kml.gz extension. These files are not read correctly by OGR using the /vsigzip virtual path. No error is thrown, and the geo (POLYGON) data comes in correctly, but all the other metadata for each feature is lost, and the other virtual data (name, description etc.) is presented differently.

Using the attached file, the results of...
ogrinfo Raleigh_Stops.kml OGRGeoJSON
...and...
ogrinfo /vsigzip/Raleigh_Stops.kml.gz OGRGeoJSON
...are very different.

This is with GDAL 2.4.2 built on Ubuntu 19.04. I am in the process of testing with 3.0.1.

[simoneves]

Also confirmed with 3.0.1.

For both versions, we are building GDAL --with-libkml pointing at libkml from a local build of https://github.com/google/libkml (the most recent, which isn't very recent), which itself references a local build of libexpat 2.2.5.

[simoneves]

OK, there's a difference I hadn't noticed before. ogrinfo on the unzipped file invokes the LIBKML driver. With the gzipped file, it invokes the KML driver. This would explain the different metadata presentation!

Is there a way to force it to use the LIBKML driver in the VSI case? ...as that's the one which correctly extracts the other columns?

[simoneves]

Checking options of GDALOpenEx...

[simoneves]

OK, so I tried passing...
const char* minimal_drivers[] = {"ESRI Shapefile", "GeoJSON", "LIBKML", nullptr};
...to GDALOpenEx (as those are the only geo files our system officially supports) but while it still happily loads Shapefiles, GeoJSONs, and uncompressed KMLs, it now won't load a gzipped KML at all. We are detecting the type and adding the /vsigzip/ prefix correctly. Do I have to add anything else to that list to allow VSI to work too?

[simoneves]

@rouault will the change allow the LIBKML driver to load the file without having to restrict the driver set? In other words, does it normally try LIBKML before KML?

[rouault]

does it normally try LIBKML before KML?

yes

[simoneves]

OK, thanks for fixing. Will wait for 3.0.2.