[GRASS-dev] Re: grass-dev Digest, Vol 35, Issue 44

[Michael Barton]

On Mar 13, 2009, at 4:20 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Fri, 13 Mar 2009 11:20:47 +0000
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault
> To: Hamish <hamish_b at yahoo.com>
> Cc: GRASS developers list <grass-dev at lists.osgeo.org>
> Message-ID: <18874.16783.811980.871775 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hamish 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 at 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