[GRASS-dev] Re: [GRASS-user] r.mfilter.fp seg fault

Glynn Clements glynn at gclements.plus.com
Fri Mar 13 07:20:47 EDT 2009


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>


More information about the grass-dev mailing list