[GRASS-dev] r.series counting maps over certain threshold?

[Markus Neteler]

On Thu, Feb 23, 2012 at 6:50 PM, Glynn Clements
<glynn at 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