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 <fran...@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev