Re: [gdal-dev] Add a new performance hint for Spatialite

2014-03-28 Thread Even Rouault
Ah, got it. I read your message too fast. I've added your suggestions with a simplified version of your below example in http://trac.osgeo.org/gdal/changeset/27104 Another solution for your use case would be to make a OGR VRT with a OGRVRTUnionLayer that reference every GML file and convert the VR

Re: [gdal-dev] Add a new performance hint for Spatialite

2014-03-28 Thread Rahkonen Jukka (Tike)
Hi, Sorry, I must have not emphasized enough that hint is only valid for appending data with subsequent ogr2ogr commands ogr2ogr -f sqlite -dsco spatialite=yes mtk_tos.sqlite -dim 2 -lco spatial_index=no /vsizip/e:\mtk_tos\etrs89\gml\K32.zip tieviiva -gt 65536 ogr2ogr -f sqlite -append mtk_tos

Re: [gdal-dev] Add a new performance hint for Spatialite

2014-03-28 Thread Even Rouault
Jukka, I'm very surprised that you need to do that explicitely, since the driver should already do that by default. This is something we discovered last year or the year before when you were experimenting OSM -> Spatialite conversions. Since OGR 1.10, the spatial index is created when the datasour

[gdal-dev] Add a new performance hint for Spatialite

2014-03-28 Thread Jukka Rahkonen
Hi, I took timings about adding 115 GML files (548 MB together, 3.2 million linestrings) into a Spatialite table. With default settings the table gets initialized with spatial index which makes following inserts slower. Another alternative is to create the table without spatial index, append all t