On Thu, Feb 23, 2012 at 6:50 PM, Glynn Clements <gl...@gclements.plus.com> wrote: > > Markus Neteler wrote: > >> The existing implementation has been reverted last year, but how to >> do that now? I have to find out at which DOY in a pixel a certain value >> has been reached. Input are all single daily GDD maps of the year. So >> far I used r.series with threshold and count. >> >> Another usage scenario: count all days over a certain temperature >> pixelwise... >> ? > > At present, the only solution is to pre-process the maps with > r.mapcalc then run r.series on the processed maps.
Since I am commonly working with > 10k maps this would generate a lot of overhead (time, disk space, effort). > Alternatively, you could re-implement the threshold= option, but > without breaking the quantile= option (which is the reason why the > original version was reverted). If I knew how... > Also, you might consider changing the c_thresh() method to be more > generally useful; I can't imagine that the current implementation > would be of use for anything other than the exact case for which it > was originally written; e.g. it won't help with your second example > because it's triggered by an in-range test (with a hard-coded range of > threshold +/- 10) rather than a greater-than test. I would be happy to see an improved version there. > Another option would be to just use r.mapcalc (using a script to > generate the expression). AFAIK, r.mapcalc doesn't have any hard-coded > limits on the number of input maps or the complexity of the > expression; the memory consumption will be worse than r.series (each > intermediate result will get its own row buffer), but only by a > constant factor. I have already to tune /etc/security/limits.conf in order to open more than 1024 maps in one step. So any overhead may become critical. Markus _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
