> Assuming that this report turns out to be not a problem,
a segfault is not a user error, so it's pretty much guaranteed to
be a real problem and not ready to be the primary version for the
6.4.0 release without being fixed. you can't get more of a "more
testing required" red flag for a new modile than a segfault, even
if it is just for a bad-input G_fatal_error() message.
> is there any reason not to simply replace r.mfilter with
> r.mfilter.fp?
Glynn:
Only the fact that it's not 100% backwards compatible,
although I have no idea whether anyone will actually want the
old behaviour.
more likely if anyone will need consistency. ie they probably won't
want the old method, but they might not want to have half of their
maps one way and the other half silently different.
if it's a bug and all old maps are actually broken, I'd say fix
the bug but don't change (arguably) valid methodology.
Apart from the use of integers, r.mfilter reads nulls as zero,
sounds like a bug- the more NULLs, the more it biases the result
towards zero. e.g. spearfish elevation is all >1000m. add a MASK
and so a bunch of zero-meter elevation into the moving window and
you get bogus results.
or is that 0-weights not 0-value??
while r.mfilter.fp reads nulls as null and propagates them
(i.e. the result cell will be null if any cell in the moving
window is null).
propagate vs not to propagate nulls is a methodology choice
(regardless of lopsided merits) and so for my 2c I'd vote to
replace it in grass7 but not devbr6 or relbr64. and of course
clearly explain the situation in the modules' help pages in the
gr6 branches.
Hamish