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 2009/2/19 Dylan Beaudette <dylan.beaude...@gmail.com>: > On Thu, Feb 19, 2009 at 5:20 AM, G. Allegri <gioha...@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.gisw...@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@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user