ogr2ogr kml a conversión shp creado 184 shapefiles ?! ¿Qué me estoy perdiendo?

Question

Estoy tratando de convertir este archivo KML conjunto de datos de hielo arenas a un shapefile utilizando ogr2ogr (GDAL 1.8). Después de algunas inicial de solución de problemas para obtener el script que se ejecuta, es la creación de 184 diferentes shapefiles (736 únicos archivos como hermanos)!

Mi ogr2ogr script es esencialmente este, con algunas banderas. El -append y -skipfailures indicadores son necesarios (no estoy seguro si la precisión o la geometría están haciendo nada, pero estoy bastante seguro de que no hacen daño). Prefiero no usar -skipfailures, como claramente lo que significa la pérdida de datos, pero sin que el script no se acabado:

ogr2ogr -f "ESRI Shapefile" "E:\4_GIS\HockeyArenas\shp\ice_rinks.shp" "E:\4_GIS\HockeyArenas\doc.kml" -lco PRECISION=false -nlt "geometry" -append -skipfailures

Finalmente quiero mover estos datos en PostgreSQL/PostGIS, pero si se trata de hacer 184 shapefiles, no quiero ensuciar mi PostGIS db con 184 tablas..

Alguien sabe cómo conseguir un shapefile, preferiblemente sin usar -skipfailures?

Gracias, de la comunidad.

Answer 1

Por desgracia, OGR ve el archivo KML como tener 247 capas (ogrinfo doc.kml), que es la razón por la que ver el lío.

Me gustaría hacer un directo en KML> PostGIS conversión. Usted puede mantener limpio el PostGIS DB mediante el uso de un esquema para contener el desorden temporal. A partir de SQL:

CREATE SCHEMA import;

Ahora en la consola (yo estoy usando OSGeo4W Shell):

$ ogr2ogr -append -f PostgreSQL PG:"dbname='your_db' user='postgres' password='secret'" \
    doc.kml -lco SCHEMA=import -lco EXTRACT_SCHEMA_FROM_LAYER_NAME=NO \
            -lco OVERWRITE=YES -lco LAUNDER=NO

(No hay errores!)

Después, usted necesita pila de sus tablas en una tabla en el esquema público (asumiendo que usted tiene al menos PostgreSQL 9.0 para el HACER):

-- Create new table for all features
CREATE TABLE ice_rinks (gid serial PRIMARY KEY);
SELECT AddGeometryColumn('public', 'ice_rinks', 'geom', 4326, 'POINT', 3);
ALTER TABLE ice_rinks ADD COLUMN division text NOT NULL;
ALTER TABLE ice_rinks ADD COLUMN name text;
ALTER TABLE ice_rinks ADD COLUMN description text;

-- Combine them
DO $$DECLARE r record;
BEGIN
    FOR r IN (SELECT relname, trim(relname) AS division
              FROM pg_class c
              JOIN pg_namespace n ON n.oid=c.relnamespace
              WHERE n.nspname='import' AND relkind='r'
              ORDER BY trim(relname))
    LOOP
        EXECUTE 'INSERT INTO ice_rinks(geom, division, "name", description) ' ||
            'SELECT wkb_geometry, ' || quote_literal(r.division) || ', "Name", "Description" ' ||
            'FROM import.' || quote_ident(r.relname) || ' ORDER BY ogc_fid';
    END LOOP;
END$$;

He 1265 características .. espero que todas estén ahí.

Por último, la limpieza. Usted puede eliminar su esquema de importación si los datos se ve bien:

DROP SCHEMA import CASCADE;

Y si usted está usando PostGIS 1.5 o anterior:

DELETE FROM geometry_columns WHERE f_table_schema='import';

Answer 2

Usted puede dar salida a un shapefile con ogr2ogr (1.8) pero consigue trunca contenido del campo o la falta de información.

Para gdal <2.0 uso:

ogr2ogr --config SHAPE_ENCODING UTF-8 -update -append output.shp /vsizip/vsicurl/http://www.hockeyarenas.net/hockeyarenas/downloads/kmz/World_Hockey_Arenas.zip/doc.kml -nln output -nlt GEOMETRY

Para gdal >2.0 uso:

ogr2ogr --config SHAPE_ENCODING UTF-8 -update -append output.shp -sql "RESIZE output" /vsizip/vsicurl/http://www.hockeyarenas.net/hockeyarenas/downloads/kmz/World_Hockey_Arenas.zip/doc.kml -nln output -nlt GEOMETRY

o

ogr2ogr --config SHAPE_ENCODING UTF-8 -update -append output.shp /vsizip/vsicurl/http://www.hockeyarenas.net/hockeyarenas/downloads/kmz/World_Hockey_Arenas.zip/doc.kml -nln output -nlt GEOMETRY -lco RESIZE=yes

El "--config SHAPE_ENCODING UTF-8" parámetro se utiliza para asegurarse de que este conjunto específico de datos conserva su DBF codificación de modo que ninguno de los personajes se traducen a su idioma de sistemas de codificación, como la ISO-8891-1, etc... Otras palabras, impide a los personajes con cosas como la diéresis se pierde durante la conversión.

Las dos opciones:

• -sql "cambiar el tamaño de tablehere"
• -lco cambiar el tamaño=sí
  
  Hacer la misma cosa! Que permite evitar que el contenido del campo se trunque/acortado (pérdida de información). En GDAL >2.0, este defecto truncar es supuestamente ya no existe, pero se han incluido los parámetros de referencia. Por lo que yo entiendo en GDAL <=1.9, no hay manera real de todo esto a menos que el acceso GDAL de C/C++, ya que hay algunas opciones de configuración disponibles que no están en las utilidades de línea de comandos como ogr2ogr.