<div dir="ltr">Hello Francesco, Markus<div><br></div><div>I find the possibility of getting statistics for only a certain fraction of a neighbourhood really interesting and I like Markus' idea as it is more general and allows for more use cases 🤓 Count me in for testing ;)</div><div><br></div><div>Vero</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 31 ene 2023 a las 15:48, Markus Metz (<<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Francesco,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Makes sense?<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 25, 2023 at 10:55 AM Francesco P. Lovergine <<a href="mailto:frankie@debian.org" target="_blank">frankie@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, <br>
<br>
for some specific needs of a research project, I had to make a little<br>
change to r.neighbors (the target version was 7.8.5 but that's not essential).<br>
<br>
Essentially, the idea behind is computing first order statistics on partial<br>
populations as identified by selected quantiles (samples >= or <= of a<br>
threshold value of quantile). <br>
<br>
For that, I introduced average_ge_quantile and average_le_quantile operators modes.<br>
<br>
<a href="https://github.com/fpl/grass/commit/6b83795b037c6645a32d6a525cfdee3cc65d521c" rel="noreferrer" target="_blank">https://github.com/fpl/grass/commit/6b83795b037c6645a32d6a525cfdee3cc65d521c</a><br>
<br>
(the html file is still not updated)<br>
<br>
I'm not persuaded this is the most elegant way of doing this kind of things,<br>
maybe it would be better using an option (as in the case of -w for weighted<br>
operations) to compute average and possibly other statistics. Even, one could<br>
think in general to other multiple ways of selecting population on the base of<br>
quantiles/percentiles of population in a window.<br>
<br>
Any hint/opinion/alternative/critic about that? <br>
<br>
All this in the remote hypothesis that a pull request could have sense<br>
for such a kind of features.<br>
<br>
Thanks<br>
<br>
<br>
-- <br>
Francesco P. Lovergine<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</blockquote></div>