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

[Nikos Alexandris]

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)