> I am having trouble with r.fillnulls and a raster having a
> resolution of 0.48.
>
> Is it right that r.fillnulls only works for raster with a resolution
> 1?

Markus:

thanks for finding the problem. I have fixed it in 6.1-CVS and
6.0-CVS (for future 6.0.2).

the buffer around the holes was twice the resolution on purpose. With
nominally two points around the edge you interpolate into the hole with
a trained slope at the edges, otherwise you just get a flat plane.

Perhaps that should even be three times the mean resolution to give
three points in all directions to define both the incoming slope &
curvature. It shouldn't affect processing time any and hopefully would
give a more realistic guess of what is in the hole. Maybe even a bigger
buffer?

With just a single row of cells around the hole you often get gaps
around the edges when distance > mean (.5 of the time? diagonals? worse
when ewres!=nsres).

also,
nsres_int="`g.region -gm | grep 'nsres=' | sed s/nsres=//`"
ewres_int="`g.region -gm | grep 'ewres=' | sed s/ewres=//`"

On Tue, Oct 25, 2005 at 02:11:33PM +1300, Hamish wrote:

Robert:
> > I am having trouble with r.fillnulls and a raster having a
> > resolution of 0.48.
> >
> > Is it right that r.fillnulls only works for raster with a resolution
> > 1?

Markus:
> thanks for finding the problem. I have fixed it in 6.1-CVS and
> 6.0-CVS (for future 6.0.2).
..
> Now resolution of 0.48 are accepted as well.

the buffer around the holes was twice the resolution on purpose.

Hi Hamish,

it seems that I was too hasty:

Looking at cvs2cl.pl/Changelog:

2005-03-02 03:22 hamish
* r.fillnulls: remove AWK for doing decimal multiplication -- broke
when decimal point was a ",". The buffer distance is pretty
arbitrary anyway, so not a big deal if we lose sub-meter precision
(I hope).

Note:
The decimal point story should be fixed due to the LC_.. statements
earlier.

With nominally two points around the edge you interpolate into the hole with
a trained slope at the edges, otherwise you just get a flat plane.

Perhaps that should even be three times the mean resolution to give
three points in all directions to define both the incoming slope &
curvature. It shouldn't affect processing time any and hopefully would
give a more realistic guess of what is in the hole. Maybe even a bigger
buffer?

This sounds good to me.

With just a single row of cells around the hole you often get gaps
around the edges when distance > mean (.5 of the time? diagonals? worse
when ewres!=nsres).

also,
nsres_int="`g.region -gm | grep 'nsres=' | sed s/nsres=//`"
ewres_int="`g.region -gm | grep 'ewres=' | sed s/ewres=//`"

On Tue, Oct 25, 2005 at 02:11:33PM +1300, Hamish wrote:
...

the buffer around the holes was twice the resolution on purpose. With
nominally two points around the edge you interpolate into the hole with
a trained slope at the edges, otherwise you just get a flat plane.

Perhaps that should even be three times the mean resolution to give
three points in all directions to define both the incoming slope &
curvature. It shouldn't affect processing time any and hopefully would
give a more realistic guess of what is in the hole. Maybe even a bigger
buffer?

offlist we fixed the problem, now a 3 points buffer is used for
better terrain (or whatever) reconstruction in the holes.

I also fixed MASK problems in r.fillnulls, should be soon in CVS.