<div dir="ltr"><br><br>On Thu, Nov 29, 2018 at 3:43 PM Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> Hi,<br>><br>> I have large amount of vector maps (~ 400) which each has hundreds of<br>> thousands of areas and over 150 attribute columns. I'm looking for the<br>> most efficient way to export these to a format I can share with<br>> non-GRASS GIS users. My favourite would probably be Geopackage, amongst<br>> others because the attribute column names are sometimes fairly long,<br>> thus making export to a DBF based format not easily feasible.<br>><br>> I've seen several sources of information about possible performance<br>> increases, either in the SQLite world (as a Geopackage is based on<br>> SQLite) or in the OGR SQLite driver page.<br>><br>> For OGR [1], there is the -gt option to ogr2ogr which allows increasing<br>> the number of features per transaction (or even running the entire<br>> conversion in one single transaction). There is also mention of the<br>> OGR_SQLITE_CACHE and OGR_SQLITE_SYNCHRONOUS configuration options.<br>> However, I don't seem to understand if, and if yes, how I can set any of<br>> these when using v.out.ogr. In r73117, MarkusM added config and dataset<br>> open options to r.in.gdal and v.in.ogr. Would we need something like<br>> this to be able to set the above config options ? How about the<br>> transaction option ?<br><br>For GDAL/OGR, you can set configuration options in various ways [0], e.g.<br><br><div>OGR_SQLITE_CACHE=1024 OGR_SQLITE_SYNCHRONOUS=OFF v.out.ogr ...</div><div><br></div><div>I'm afraid the transaction option (equivalent to ogr2ogr -gt) is out of control of v.out.ogr because it is format-specific and v.out.ogr does not use the output format drivers directly, instead it uses the generic OGR interface. However, we could try GDALDatasetStartTransaction()/GDALDatasetCommitTransaction() in v.out.ogr.<br></div><div><br></div><div>Markus M<br></div><br><div>[0] <a href="https://trac.osgeo.org/gdal/wiki/ConfigOptions">https://trac.osgeo.org/gdal/wiki/ConfigOptions</a></div><br>><br>> On the SQLite side, there are some pragma statements that allow<br>> increasing performance (generally at the cost of less data security, but<br>> in some cases this might be acceptable), such as journal_mode [2] or<br>> synchronous [3] (which I suppose is what OGR_SQLITE_SYNCHRONOUS sets as<br>> well), or possibly locking_mode (I don't know how this is handled<br>> internally in OGR).<br>><br>> Again, my question would be how these could be set when exporting data<br>> with v.out.ogr.<br>><br>> Other interesting options (which would also influence performance)<br>> might be a flag in v.out.ogr allowing exporting without attribute data<br>> (although a simple v.db.connect -d before export would probably be<br>> enough) and allowing selecting a subset of columns to export. But that's<br>> something else.<br>><br>> Moritz<br>><br>><br>><br>><br>> [1] <a href="https://gdal.org/drv_sqlite.html">https://gdal.org/drv_sqlite.html</a><br>> [2] <a href="https://sqlite.org/pragma.html#pragma_journal_mode">https://sqlite.org/pragma.html#pragma_journal_mode</a><br>> [3] <a href="https://sqlite.org/pragma.html#pragma_synchronous">https://sqlite.org/pragma.html#pragma_synchronous</a><br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></div>