[GRASS-user] improve v.rast.stats speed?
giohappy at gmail.com
Thu Feb 19 11:43:45 EST 2009
I didn't let it finish because 15 minutes were too many for my task.
Ok, less then 5 hours and more of v.rast.stats, but too much respect
to ArcGIS and the rasterization solution in GRASS.
I've built the 1.2.03 version, downloaded from .
Anyway I suspect the same about GRASS driver inefficiencies in GDAL/OGR
2009/2/19 Dylan Beaudette <dylan.beaudette at gmail.com>:
> On Thu, Feb 19, 2009 at 5:20 AM, G. Allegri <giohappy at gmail.com> wrote:
>> Thanks for the ideas.
>> I've just tried Starspan but it's performance is still too slow. I've
>> let it run for 15 minutes...
> Did you ever let it finish? Can you post the version number? I have
> noticed that starspan tends to be slower when using GRASS vector and
> raster features-- probably a combination of inefficiencies in GDAL/OGR
> with the GRASS formats.
>> r.statistics is probably the best solution. I've investigated the
>> ArcGIS method and it actually seems to use a similar method
>> (ratserization of the features and various automations to join the
>> results). In fact they call the module "zonal statistics" that is
>> generally a set of raster basded methods.
>> the only limitation of the actual r.statistics is that it works only
>> with CELL and not float. Ok, I can multiply my values and convert to
>> CELL, but we could try to let r.statistics deal with floats too...
>> I will try to batch the process and let you know the results.
>> 2009/2/19 Markus Metz <markus.metz.giswork at googlemail.com>:
>>> Markus Metz wrote:
>>>> G. Allegri wrote:
>>>>> Hello list.
>>>>> Yesterday I needed to use v.rast.stats on a 1793 areas covering a
>>>>> 4415x6632 raster (with resolution 50m/pixel). I've used it without
>>>>> extended statistics but the processing time was, with an euphemism,
>>>>> very very long. After 5 hours it wasn't finished yet. As I needed it
>>>>> for today morning I've decided to reproduce it with ArcGIS: 40
>>>>> seconds. I've tried to investigate what was going wrong, the
>>>>> bottleneck, but at the end I suppose that it's a problem of the script
>>>>> itself (the looping chain of r.mapcalc and r.univar, the creation and
>>>>> deletion of the MASK in each loop).
>>>>> Is there any way to improve the performance of v.rast.stats? Should we
>>>>> rewrite it in C and avoid the use of MASKs?
>>>> I have two ideas.
>>>> 1) Use r.reclass instead of r.mapcalc to create new masks. That should
>>>> speed up at least the MASK creation and deletion
>>>> 2) Avoid the loop and MASK creation altogether. Run r.univar
>>>> map=tmpname,raster. Process the output of r.univar, separate stats for the
>>>> different vector areas and convert to sql statements. Proceed as before.
>>>> r.univar would be called only once. I'm not sure if this is possible. I also
>>>> don't know if the speed gain by avoiding the loop is annihilated by r.univar
>>>> having to process two rasters as input.
>>> Idea 2 is nonsense, I hoped for some behaviour like in r.statistics.
>> grass-user mailing list
>> grass-user at lists.osgeo.org
More information about the grass-user