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

Dylan Beaudette dylan.beaudette at gmail.com
Thu Feb 19 11:11:50 EST 2009


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

Hi,

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.


Dylan


>
> 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
> http://lists.osgeo.org/mailman/listinfo/grass-user
>


More information about the grass-user mailing list