[Bug] r.fillnulls bicubic interpolator fails to fill large holes

[marisn]

Describe the bug Some changes within the last year have changed behaviour of r.filllnulls bicubic interpolator. If it encounters large hole, it is not completely filled — there are unfilled squares left + some strange values around the new hole edges produced.

To Reproduce Steps to reproduce the behaviour:

g.region n=1000 s=0 e=1000 w=0 res=1
r.surf.fractal output=surf
r.circle -b output=circle coordinates=500,500 max=300
r.mapcalc expression="holed = if(isnull(circle), surf, null())"
r.fillnulls input=holed output=filled method=bicubic
r.univar map=filled | grep "total null cells"

Expected behavior No null values

System description (please complete the following information):

• Operating System: Ubuntu Bionic
• GRASS GIS version: 9da94b70eab8313f2a1e70752609f7b2caa2e741

[neteler]

I checked with G78 and can confirm the issue.

Filling works with "bilinear":

r.fillnulls input=holed output=filled_bilin memory=500 method=bilinear
...
r.univar map=filled_bilin | grep "total null cells"
total null cells: 0

but not with bicubic (perhaps suboptimal default settings?).

[metzm]

This is really a big hole. When I run r.resamp.bspline with the parameters used by r.fillnulls, I get

...
subregion 15 of 36
WARNING: No data within this subregion. Consider increasing the spline
         step.
...

Increasing the spline step helps, and all NULL cells are interpolated.

Does the exact same test case work with GRASS 7.6?

The default parameters used by r.fillnulls when calling r.resamp.bspline apparently do not work for such large holes. A possibility would be to completely rewrite r.resamp.bspline and use an adaptive moving window approach as in r.resamp.tps.

As GRASS version you provided the commit 9da94b70eab8313f2a1e70752609f7b2caa2e741, but I can't tell from this commit which GRASS version you are using. I guess master.

[neteler]

@marisn Does the exact same test case work with GRASS 7.6? And, which version did you use for this bug report?