Opened 6 years ago
Closed 6 years ago
#7179 closed defect (invalid)
ogr2ogr doesn't import whole attribute table from KMLs
Reported by: | flc | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 2.2.3 |
Severity: | normal | Keywords: | |
Cc: |
Description
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.
Attachments (1)
Change History (6)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
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.
comment:3 by , 6 years ago
So do you have some test data that could be used for analyzing the issue?
by , 6 years ago
Attachment: | centrales.de.generacion.electrica-point.kml added |
---|
Layer with many attributes (around 65)
comment:4 by , 6 years ago
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)
comment:5 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Closing as not a GDAL bug. This is an issue with the provider of the GDAL binary not shipping it with LIBKML
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:
Could you add test data into the ticket or a link for downloading some?