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

[Markus Metz]

G. Allegri wrote:
> 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...
>   
Shouldn't be too difficult. Who maintains r.statistics?

How about a new module, some r.univar derivate that uses "zonal 
statistics" and a base map like r.statistics? That could then also be 
used by v.rast.stats.

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