[GRASS-dev] Re: r.series: threshold/count method?
Markus Neteler
neteler at osgeo.org
Sat Sep 5 14:11:21 EDT 2009
On Sat, Sep 5, 2009 at 8:02 PM, Glynn Clements<glynn at gclements.plus.com> wrote:
> Markus Neteler wrote:
>
>> >> In 7.0, the prototype for aggregates has recently been changed to
>> >> accept an additional parameter of type "const void *". r.series uses
>> >> this to implement the quantile= option for method=quantile.
>> >>
>> >
>> > Ah, thanks - I didn't realize the difference. This will help.
>>
>> It does.
>>
>> Since I eventually need it in (locally) 6.4, I have backported
>> "arbitrary quantiles" from trunk.
>>
>> I have now added the new threshold method (locally):
>>
>> quantile Quantile to calculate for method=quantile
>> options: 0.0-1.0
>> threshold Threshold to calculate for method=threshold
>>
>> but need to pass the value to the function. This happens for quantile here
>> in main.c from r.series:
>>
>> 240 if (null && flag.nulls->answer)
>> 241 G_set_d_null_value(&out->buf[col], 1);
>> 242 else {
>> 243 memcpy(values_tmp, values, num_inputs * sizeof(DCELL));
>> 244 (*out->method_fn)(&out->buf[col], values_tmp, num_inputs, &out->quantile);
>> 245 }
>>
>> Since I am getting lost in the pointers, how to pass '&out->threshold'
>> instead of
>> &out->quantile when I use the threshold method? I guess I don't want to add
>> more parameters to line 244...
>
> I would have renamed the quantile= option to parameter= rather than
> having a separate threshold= option, and done likewise for the
> "quantile" field in struct output.
Sounds good, I am happy about suggestions.
Drawback: then currently enforced 0.-1. range for quantiles
would be removed. Maybe a minor issue or to be tested in
the c_percentile.c file.
> But if additional aggregates start getting more complex parameters
> (e.g. multiple parameters or different types), the more general
> solution is to add a "const void *parameter" to struct output, which
> is set when the structure is initialised.
I have an extra issue: For the particular growing degree day calculation
I am facing the problem that the values I am comparing with a FP values
and that GRASS_EPSILON is useless in this particular case. It works
only with
/* EPSILON = GRASS_EPSILON; */
EPSILON = 10.
if (fabs(tval - values[i]) < EPSILON ) {
because the pixel values are growing so quickly from one map to the
next. Since we need a generic solution, another "precision" or whatever
parameter needs to be passed otherwise the thresholding fails completely.
EPSILON however depends on the input maps and needs to be user
controllable.
How to deal with that?
Markus
More information about the grass-dev
mailing list