[GRASS-dev] Passed: GRASS-GIS/grass-ci#3146 (master - 3010c0a)
Build Update for GRASS-GIS/grass-ci - Build: #3146 Status: Passed Duration: 8 mins and 56 secs Commit: 3010c0a (master) Author: Markus Metz Message: v.distance: speed improvement for small dmax git-svn-id: https://svn.osgeo.org/grass/grass/trunk@73820 15284696-431f-4ddb-bdfa-cd5b030d7da7 View the changeset: https://github.com/GRASS-GIS/grass-ci/compare/6f14c38e9563...3010c0a1e0ef View the full build log and details: https://travis-ci.org/GRASS-GIS/grass-ci/builds/471170001?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the GRASS-GIS/grass-ci repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=5458449&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS + Python3 + QGIS (vs Python2)
Hi, I am trying to sort out support of GRASS for QGIS in Mac package https://lutraconsulting.github.io/qgis-mac-packager/. The package is self-standing and bundles its own Python 3, GRASS 7.4.3 (taken from homebrew) and QGIS 3.4.x Due to some issues ( https://github.com/OSGeo/homebrew-osgeo4mac/issues/452#issuecomment-413650370), homebrew forces python2 interpreter to run, which is incompatible with bundled Python3 in the package. I would like to ask if GRASS fully supports Python 3 (and from which version) Thanks, Peter ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to increase performance of v.out.ogr to geopackage ?
Hi Ken, On 20/12/18 16:08, Ken Mankoff wrote: On Thu, Nov 29, 2018 at 3:43 PM Moritz Lennert wrote: I have large amount of vector maps (~ 400) which each has hundreds of thousands of areas and over 150 attribute columns. I'm looking for the most efficient way to export these to a format I can share with non-GRASS GIS users. Do you need to combine them? If not, my preferred solution to speed things up is to use GNU parallel. Parallelization is obviously part of a solution, but I would guess that one hits I/O limits at one point if you try to export too many maps in parallel to the same disk. I realize your message was to GRASS dev and not users though, so you may be looking for a method to speed GRASS up, not necessarily your specific workflow. The specific question was about the use of the OGR variables for speeding up the process of writing to SQLite DBs, but parallelization is always a path to look at as well. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] how to increase performance of v.out.ogr to geopackage ?
On 20/12/18 20:10, Markus Metz wrote: On Thu, Dec 20, 2018 at 10:34 AM Markus Metz mailto:markus.metz.gisw...@gmail.com>> wrote: > > > > On Thu, Nov 29, 2018 at 3:43 PM Moritz Lennert mailto:mlenn...@club.worldonline.be>> wrote: > > > > Hi, > > > > I have large amount of vector maps (~ 400) which each has hundreds of > > thousands of areas and over 150 attribute columns. I'm looking for the > > most efficient way to export these to a format I can share with > > non-GRASS GIS users. My favourite would probably be Geopackage, amongst > > others because the attribute column names are sometimes fairly long, > > thus making export to a DBF based format not easily feasible. > > > > I've seen several sources of information about possible performance > > increases, either in the SQLite world (as a Geopackage is based on > > SQLite) or in the OGR SQLite driver page. > > > > For OGR [1], there is the -gt option to ogr2ogr which allows increasing > > the number of features per transaction (or even running the entire > > conversion in one single transaction). [...] > > How about the > > transaction option ? > > 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. v.out.ogr already uses the OGR interface to start and commit transactions when possible. Another reason for slow export can be a buggy NFS implementation if you export to a NFS mount: check if v.out.ogr is running at 100%. If not you could export to a local temp dir and then copy the GeoPackages to the final destination. Thanks for all the hints. Using OGR_SQLITE_CACHE=1024 OGR_SQLITE_SYNCHRONOUS=OFF v.out.ogr ... should already help. In this particular case export was happening to local disk, so NFS was not an issue. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
