On Mar 13, 2009, at 4:20 AM, <grass-dev-request@lists.osgeo.org> wrote:
Date: Fri, 13 Mar 2009 11:20:47 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault
To: Hamish <hamish_b@yahoo.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <18874.16783.811980.871775@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-asciiHamish wrote:
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??
The old r.mfilter (7.0's r.mfilter is r.mfilter.fp) uses
G_get_map_row(), which reads null as zero (i.e. 4.x behaviour).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.Note that there's a special case if the divisor is zero: the numerator
is calculated over the non-zero/non-null cells, and the divisor is the
sum of the weights whose corresponding input cells are non-zero/non-null.It's only if you specify a non-zero divisor that propagation (or
skewing toward zero) occurs. In this situation, avoiding propagation
probably doesn't make sense, as the calculation will typically be
relying upon the sum of the weights being a specific value (possibly
zero, i.e. a combination of positive and negative weights).--
Glynn Clements <glynn@gclements.plus.com>
A somewhat more pragmatic issue prompted my initial question. Right now, we have both r.mfilter AND r.mfilter.fp in distribution copies of GRASS. r.mfilter is in the menu but r.mfilter.fp is not. Both have identical documentation. I am reluctant to put 2 apparently identical r.mfilter entries into the menu, and having 2 of these without saying what the difference is will be confusing to users. But if r.mfilter.fp is better, it should arguably be the one that most users access. So I was thinking about replacing the entry for r.mfilter with r.mfilter.fp. But it seems better to just have a single more functional version of this module.
Michael