[GRASS-dev] v.rast.stats parallel process

Stefan Blumentrath Stefan.Blumentrath at nina.no
Thu Jun 14 04:20:01 PDT 2018

Yes, access to attributes would be a challenge / bottleneck for parallelisation, esp. if you have many areas in your vector map. Note that not only SQLite but also DBF is still supported (which puts some limitations)...

Please note also: https://trac.osgeo.org/grass/ticket/3523 for some suggestions for speeding up v.rast.stats (without parallelisation).
Once multiple raster map input is supported, statistics could be computed in parallel for each raster map and then finally uploaded to the attribute table in one single process...
Yet, the region adjustment performed by v.rast.stats would then have to be handled differently from current solution...

I would say it is worth a ticket...

If you want a text file, you could use r.univar directly, no? 


-----Original Message-----
From: grass-dev <grass-dev-bounces at lists.osgeo.org> On Behalf Of Moritz Lennert
Sent: torsdag 14. juni 2018 13:05
To: Lorenzo Bottaccioli <lorenzo.bottaccioli at gmail.com>; GRASS developers list <grass-dev at lists.osgeo.org>
Subject: Re: [GRASS-dev] v.rast.stats parallel process

On 14/06/18 12:24, Lorenzo Bottaccioli wrote:
> Hi all,
> There is any chance that the v.rast.stats will be paralellized?

You mean to treat several rasters at the same time ?

It shouldn't be too complicated to write a wrapper script for this. I would imagine the biggest problem to be the handling of the access to the attribute database file. Not sure that you can have concurrent access to this file by several parallel processes. If this is an issue, we would probably have to add the option to output v.rast.stats results to text files and then load content of these files into at the attribute table of the vector map at the end...

grass-dev mailing list
grass-dev at lists.osgeo.org

More information about the grass-dev mailing list