> 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.