[GRASS-user] improve v.rast.stats speed?

[G. Allegri]

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...

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.
>
>