ogr2ogr doesn't import whole attribute table from KMLs

[flc]

The bug is about ogrinfo and ogr2ogr when getting info and importing KML files respectively.

In latest GDAL version (2.2.3)

ogrinfo -q -ro centrales.de.generacion.electrica-point.kml 
1: sql_statement (Point)

which is fine, gives me layer name and geometry type.

But then:

ogrinfo -al  centrales.de.generacion.electrica-point.kml

Doesn't read all attributes from KML, it just shows Name and Description.

Using GDAL version 2.1.3 through docker, I got:

docker run --rm --net=host -v $(pwd):/data geodata/gdal:2.1.3 ogrinfo -q -ro centrales.de.generacion.electrica-point.kml
1: sql_statement

Which is WRONG, since it doesn't give me the geometry type. But this version can import perfectly all KML attributes.

Problem is latest GDAL doesn't use libkml from Google and 2.1.3 does.

I also tried other versions: 2.1.1, 2.2.0, 2.2.1 and 2.2.2 and all show the problem when trying to import KMLs.

[Jukka Rahkonen]

GDAL can be compiled with or without LIBKML, it is not tied to version. For example the Windows binaries from gisinternals.com have bot drivers:

  ogrinfo --formats |find "KML"
  LIBKML -vector- (rw+v): Keyhole Markup Language (LIBKML)
  KML -vector- (rw+v): Keyhole Markup Language (KML)

Could you add test data into the ticket or a link for downloading some?

[flc]

Problem is that when it's not compiled with LIBKML, ogr2ogr doesn't see whole attributes table. This not only affects ogr2ogr, but applications that use it to interpret a KML, for example ​http://qgis.org/.

End-users don't care about compilation or stuff, they receive a KML file from another party and they want to see the data they're supposed to see.

I took this issue first to the people from Archlinux, which is the Linux distribution I use, and their answer was that since upstream (meaning GDAL) doesn't require it, then they won't include it either. They don't even offer it as an optional dependency, installing the libkml package doesn't add anything to GDAL.

So the only option is to compile myself a tuned version.

I think that not having access to the data that's supposed to come with a KML file is a major issue, if the integrated KML library from GDAL doesn't handle attribute table, then LIBKML should become a required library.

[Jukka Rahkonen]

So do you have some test data that could be used for analyzing the issue?

[flc]

Layer with many attributes (around 65)

[flc]

Sure! :) I just attached centrales.de.generacion.electrica-point.kml which has many attributes.

Loading that into QGIS v2.18.15 (Compiled and running against GDAL/OGR 2.2.3) shows a two-column table for Name and Description with empty cells (which is fine, original KML didn't have those fields, were added by GDAL), but doesn't show the rest of the columns with data.

In GDAL 2.2.3 we get:

$ ogrinfo -ro -al centrales.de.generacion.electrica-point.kml | head

Output:

INFO: Open of `centrales.de.generacion.electrica-point.kml'
      using driver `KML' successful.

Layer name: sql_statement
Geometry: Point
Feature Count: 316
Extent: (-74.045580, -52.952320) - (-67.979959, -18.449997)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
Name: String (0.0)
Description: String (0.0)
OGRFeature(sql_statement):0
  Name (String) = 
  Description (String) = 
  POINT (-72.255574601197 -37.9653021494536)

OGRFeature(sql_statement):1
  Name (String) = 
  Description (String) = 
  POINT (-72.524104090872 -39.018256009217)

Checking again the file with GDAL v2.1.3 (the only version I could find in geodata/gdal docker image with LIBKML) this time we get every field:

$ docker run -v $(pwd):/data geodata/gdal:2.1.3 ogrinfo -ro -al centrales.de.generacion.electrica-point.kml

Output:

INFO: Open of `centrales.de.generacion.electrica-point.kml'
      using driver `LIBKML' successful.

Layer name: sql_statement
Geometry: Unknown (any)
Feature Count: 316
Extent: (-74.045580, -52.952320) - (-67.979959, -18.449997)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
Name: String (0.0)
description: String (0.0)
timestamp: DateTime (0.0)
begin: DateTime (0.0)
end: DateTime (0.0)
altitudeMode: String (0.0)
tessellate: Integer (0.0)
extrude: Integer (0.0)
visibility: Integer (0.0)
drawOrder: Integer (0.0)
icon: String (0.0)
nombre: String (0.0)
tipo: String (0.0)
combustibl: String (0.0)
propiedad: String (0.0)
potenciamw: Real (0.0)
n_unidad: String (0.0)
fecha_ingr: String (0.0)
rca: String (0.0)
sist_elect: String (0.0)
estado: String (0.0)
tipo_seia: String (0.0)
coord_este: Real (0.0)
coor_norte: Real (0.0)
huso: Real (0.0)
datum: String (0.0)
region: String (0.0)
provincia: String (0.0)
comuna: String (0.0)
fuente_bas: String (0.0)
fech_crea: String (0.0)
fech_act: String (0.0)
OGRFeature(sql_statement):1
  Name (String) = (null)
  description (String) = (null)
  timestamp (DateTime) = (null)
  begin (DateTime) = (null)
  end (DateTime) = (null)
  altitudeMode (String) = (null)
  tessellate (Integer) = -1
  extrude (Integer) = 0
  visibility (Integer) = -1
  drawOrder (Integer) = (null)
  icon (String) = (null)
  nombre (String) = PARQUE EOLICO MALLECO
  tipo (String) = EOLICA
  combustibl (String) = EOLICA
  propiedad (String) = WPD MALLECO SPA
  potenciamw (Real) = 270
  n_unidad (String) = 90
  fecha_ingr (String) = 2013/12/23
  rca (String) = SIN RCA
  sist_elect (String) = SIC
  estado (String) = EN CALIFICACION
  tipo_seia (String) = C - DS 95
  coord_este (Real) = 741321
  coor_norte (Real) = 5794839
  huso (Real) = 19
  datum (String) = WGS-84
  region (String) = IX REGION DE LA ARAUCANIA
  provincia (String) = MALLECO
  comuna (String) = COLLIPULLI
  fuente_bas (String) = SEIA
  fech_crea (String) = 24-11-2014
  fech_act (String) = 26-01-2015
  POINT (-72.255574601197 -37.9653021494536)

OGRFeature(sql_statement):2
  Name (String) = (null)
  description (String) = (null)
  timestamp (DateTime) = (null)
  begin (DateTime) = (null)
  end (DateTime) = (null)
  altitudeMode (String) = (null)
  tessellate (Integer) = -1
  extrude (Integer) = 0
  visibility (Integer) = -1
  drawOrder (Integer) = (null)
  icon (String) = (null)
  nombre (String) = CENTRAL HIDROELECTRICA LOS AROMOS
  tipo (String) = HIDROELECTRICA MENOR A 20 MW
  combustibl (String) = NO APLICA
  propiedad (String) = MINICENTRAL HIDROELECTRICA SALTOS DE LOS ANDES SA
  potenciamw (Real) = 19.9
  n_unidad (String) = 3
  fecha_ingr (String) = 2013/12/23
  rca (String) = SIN RCA
  sist_elect (String) = SIC
  estado (String) = EN CALIFICACION
  tipo_seia (String) = C - DS 95
  coord_este (Real) = 714583
  coor_norte (Real) = 5678637
  huso (Real) = 19
  datum (String) = WGS-84
  region (String) = IX REGION DE LA ARAUCANIA
  provincia (String) = CAUTIN
  comuna (String) = PITRUFQUEN
  fuente_bas (String) = SEIA
  fech_crea (String) = 24-11-2014
  fech_act (String) = 26-01-2015
  POINT (-72.524104090872 -39.018256009217)

[Even Rouault]

Closing as not a GDAL bug. This is an issue with the provider of the GDAL binary not shipping it with LIBKML