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

G. Allegri giohappy at gmail.com
Sat Feb 21 15:08:41 EST 2009


I'm out of office. When I'll be back I shall summerize the various
proposals and try to make some benchmark on my dataset. The first
thing is to make a cleaner distinction between the various stats
commands. Thanks for all the contributions!

2009/2/21, Nikos Alexandris <nikos.alexandris at felis.uni-freiburg.de>:
> On Sat, 2009-02-21 at 09:20 +0100, Markus Metz wrote:
>> Hamish wrote:
>> > Jose Gómez-Dans wrote:
>> >
>> >> My take on this is to rasterize my vector data with gdal_rasterize (you
>> >> can have a look at the rasterisation code and see how it works, in case
>> >> you need to eg buffer your vector data), load it up in python, load my
>> >> dataset in python, and calculate whatever stats with scipy+numpy. If
>> >> you look at this thread, you'll find it is very fast:
>> >> <http://article.gmane.org/gmane.comp.python.scientific.user/19412>.
>> >>
>> >
>> > numpy is already requested by the new wxGUI*, so with numpy around
>> > anyway,
>> > maybe some python module could be written for grass7, where python is a
>> > full dependency?
>> >
>> > * see gui/wxpython/gui_modules/profile.py
>> >
>> >
>> I think too that grass should provide a reasonably fast way to get this
>> kind of stats. You can still devise your own solution if you want, but
>> IMHO grass must be able to do this job reasonably fast and user-friendly.
>> Taking the risk of becoming annoying: with r.univar.zonal, everything
>> could be done in one pass: rasterize vector, no need for mapcalc, run
>> r.univar.zonal once (which itself needs only one pass), load stats to
>> attribute table, done. With the example that started this thread,
>> everything should be completed in very few minutes. Rasterizing the
>> vector might take the longest.
>>
>> Anyway, when it comes to processing time, I'm a speed junky, and >5
>> hours is simply unacceptable if it can also be done in minutes or even
>> seconds, and grass should do that, not forcing users to come up with
>> their own workarounds for something that grass is supposed to do.
>>
>> Markus M
>
> +1 (from an end-user :: I had to do "my" workaround once)
>
>

-- 
Inviato dal mio dispositivo mobile


More information about the grass-user mailing list