[GRASS-dev] RFC: variations of statistics in r.neighbors (and the stats lib)

Markus Metz markus.metz.giswork at gmail.com
Tue Jan 31 10:47:49 PST 2023


Hi Francesco,

the proposed change to r.neighbors is interesting, but maybe too specific:
you have introduced two new functions, and many more functions would be
needed to e.g. get the filtered standard deviation or median.

Therefore I suggest adding some filtering option to r.neighbors consisting
of a filtering function and a comparison operator. The filtering function
would be any of the currently supported neighborhood functions returning
some value. The comparison operator would be one of gt, ge, le, lt (>, >=,
<=, <). r.neighbors would then first get the result value of the filtering
function, then set all values in the neighborhood to NULL that do not
fulfil the condition "value <comparison operator> <result value">, then
call the actual neighborhood operation with the filtered values. This would
be more flexible, because the user can freely combine a neighborhood filter
function with a neighborhood operation.

Makes sense?


On Wed, Jan 25, 2023 at 10:55 AM Francesco P. Lovergine <frankie at debian.org>
wrote:

> Hi,
>
> for some specific needs of a research project, I had to make a little
> change to r.neighbors (the target version was 7.8.5 but that's not
> essential).
>
> Essentially, the idea behind is computing first order statistics on partial
> populations as identified by selected quantiles (samples >= or <= of a
> threshold value of quantile).
>
> For that, I introduced average_ge_quantile and average_le_quantile
> operators modes.
>
>
> https://github.com/fpl/grass/commit/6b83795b037c6645a32d6a525cfdee3cc65d521c
>
> (the html file is still not updated)
>
> I'm not persuaded this is the most elegant way of doing this kind of
> things,
> maybe it would be better using an option (as in the case of -w for weighted
> operations) to compute average and possibly other statistics. Even, one
> could
> think in general to other multiple ways of selecting population on the
> base of
> quantiles/percentiles of population in a window.
>
> Any hint/opinion/alternative/critic about that?
>
> All this in the remote hypothesis that a pull request could have sense
> for such a kind of features.
>
> Thanks
>
>
> --
> Francesco P. Lovergine
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20230131/c8d282c3/attachment.htm>


More information about the grass-dev mailing list