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 > _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
