Markus: > > > a friend told me that with the latest QGIS release candidate, > > > there is a winGRASS problem: > > > > > > $ v.rast.stats vector=CEA_riserve raster=CEA_slope > > > colprefix=delete c:/Programmi/Quantum: c:/Programmi/Quantum: No > > > such file or directory Paul: > > I notice there are loads of places in it that paths aren't quoted so > > that is probably the first problem Glynn: > That's certainly a fundamental problem; $TMP and $SQLTMP appear to be > the most likely candidates. > > Regardless of Windows-specific issues, failure to quote variables > which contain pathnames is a bug and needs to be fixed.
done in 6.3cvs. > AFAICT, $SQLTMP is unnecessary. You can just as easily use a subshell > with its output piped directly to db.execute; no need for a temporary > file. It is used in a loop- that would make it call db.execute nine times per vector cat instead of once. db.execute is slow to start/stop, so it is much faster to use a single call with $SQLTMP. r.univar is the longest step in the loop, in the version I wrote before there was a v.rast.stats, I did the loop like: r.mapcalc MASK=if(v_to_rast == $cat) g.region zoom=MASK r.univar v_to_rast g.region region=original g.remove MASK not sure how much that sped it up, IIRC if the entire row is NULL then raster ops should skip past it very quickly, and the only gain is from the fewer rast column cells to process. "g.region zoom=" is not so fast though and I never did any time trials to see. Actually when I think about it, my data was buffers around points and I calculated the tmp region from the central coord, not zoom=. In practice r.univar of the full MASKed region may take the same time-to-run as g.region zoom=, so no speedup for arbitrary polygon shapes. shrug. Hamish _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
