On Mar 11, 2009, at 5:02 PM, <grass-user-request@lists.osgeo.org> wrote:
Date: Wed, 11 Mar 2009 19:02:11 +0000
From: Glynn Clements <glynn@gclements.plus.com>
Subject: Re: [GRASS-user] r.mfilter.fp seg fault
To: Thierry Schmitt <thierry_schmitt@yahoo.com>
Cc: grass-user@lists.osgeo.org
Message-ID: <18872.2739.830971.946417@cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Thierry Schmitt wrote:
I have been investigating the r.mfilter.fp function with a relatively
large raster file. My poor 6.3.0 version (on a x64bits - Poseidon
(ubuntu) distribution) of this binary keeps sending me a deadly
"segmentation fault".
I would like to know if this is a known issue? If yes any suggestion on
how to solve it?
I can't find any record of any bugs being fixed in r.mfilter.fp since
it was created, so it doesn't look like a known issue.
Can you provide a recipe to reproduce this using only the sample
datasets or generated data?
--
Glynn Clements <glynn@gclements.plus.com>
Glynn, others,
Assuming that this report turns out to be not a problem, is there any reason not to simply replace r.mfilter with r.mfilter.fp?
Michael
Michael Barton wrote:
>> I have been investigating the r.mfilter.fp function with a relatively
>> large raster file. My poor 6.3.0 version (on a x64bits - Poseidon
>> (ubuntu) distribution) of this binary keeps sending me a deadly
>> "segmentation fault".
>> I would like to know if this is a known issue? If yes any
>> suggestion on
>> how to solve it?
>
> I can't find any record of any bugs being fixed in r.mfilter.fp since
> it was created, so it doesn't look like a known issue.
>
> Can you provide a recipe to reproduce this using only the sample
> datasets or generated data?
>
> --
> Glynn Clements <glynn@gclements.plus.com>
Glynn, others,
Assuming that this report turns out to be not a problem, is there any
reason not to simply replace r.mfilter with r.mfilter.fp?
Only the fact that it's not 100% backwards compatible, although I have
no idea whether anyone will actually want the old behaviour.
Apart from the use of integers, r.mfilter reads nulls as zero, 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).
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Mar 12, 2009 at 11:45 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Only the fact that it's not 100% backwards compatible, although I have
no idea whether anyone will actually want the old behaviour.
This might be unlikely.
Apart from the use of integers, r.mfilter reads nulls as zero, 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).
Could we have the same mechanism as in r.series (-n flag)?
Markus
On Mar 12, 2009, at 3:45 AM, Glynn Clements wrote:
Michael Barton wrote:
I have been investigating the r.mfilter.fp function with a relatively
large raster file. My poor 6.3.0 version (on a x64bits - Poseidon
(ubuntu) distribution) of this binary keeps sending me a deadly
"segmentation fault".
I would like to know if this is a known issue? If yes any
suggestion on
how to solve it?
I can't find any record of any bugs being fixed in r.mfilter.fp since
it was created, so it doesn't look like a known issue.
Can you provide a recipe to reproduce this using only the sample
datasets or generated data?
--
Glynn Clements <glynn@gclements.plus.com>
Glynn, others,
Assuming that this report turns out to be not a problem, is there any
reason not to simply replace r.mfilter with r.mfilter.fp?
Only the fact that it's not 100% backwards compatible, although I have
no idea whether anyone will actually want the old behaviour.
Apart from the use of integers, r.mfilter reads nulls as zero, 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).
--
Glynn Clements <glynn@gclements.plus.com>
Following up on this, are the rest of the group willing to replace the old r.mfilter code with code from the new r.mfilter.fp?
Michael
Markus Neteler wrote:
> Only the fact that it's not 100% backwards compatible, although I have
> no idea whether anyone will actually want the old behaviour.
This might be unlikely.
> Apart from the use of integers, r.mfilter reads nulls as zero, 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).
Could we have the same mechanism as in r.series (-n flag)?
We can add a flag to make it interpret null as zero.
Note that there's already the special treatment used if the divisor is
zero.
--
Glynn Clements <glynn@gclements.plus.com>