On Thursday 19 February 2009, G. Allegri wrote: > Hi Dylan. > I didn't let it finish because 15 minutes were too many for my task. > Ok, less then 5 hours and more of v.rast.stats, but too much respect > to ArcGIS and the rasterization solution in GRASS. > I've built the 1.2.03 version, downloaded from [1]. > Anyway I suspect the same about GRASS driver inefficiencies in GDAL/OGR > > [1] > http://projects.atlas.ca.gov/frs/download.php/667/starspan-1.2.03.tar.gz
OK. This is the old stable branch (I think). If you can get 2.0 to compile I would suggest trying that. Starspan really needs to make it into OSGeo so that more eyes can get in on the development + bug tracking. At one point it was considerably faster than zonal stats in ArcGIS. I am planning on spending more time on Starspan from May. Cheers, Dylan > 2009/2/19 Dylan Beaudette <[email protected]>: > > On Thu, Feb 19, 2009 at 5:20 AM, G. Allegri <[email protected]> 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 <[email protected]>: > >>> 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 > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/grass-user -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
