gdal_fillnodata.py doesn't fill raster when -si flag specified

[dickeya]

When I run the gdal_fillnodata.py script with no arguments, it works as expected - the nodata areas get filled. If I specify the -si flag the script fills a 1px buffer and leaves the rest unfilled. In the case of Int16 data, the remainder of the hole is filled with zeros.

I'm running as:

gdal_fillnodata.py -si 1 test_F32.tif test_F32.fill.si.tif

[Kyle Shannon]

output after patch

[Kyle Shannon]

Use -nomask:

gdal_fillnodata.py -si 1 test_F32.tif test_F32.fill.si.tif

The attached patch broke the autotests, because of setting the nodata, I will check on that and post another patch.

kss

[Kyle Shannon]

patch for setting nodata value and dst mask band

[Kyle Shannon]

Use -nomask:

gdal_fillnodata.py -si 1 test_F32.tif test_F32.fill.si.tif

The mask band is set to the srcband.GetMaskBand() if the script is called with out it and it doesn't get moved over to dstband.GetMaskBand()

Attached patch and output. I don't have test data for datasets with internal masks or external masks, so a quick test would be prudent if anyone has samples of those. I am running autotests right now. I am not totally certain this is completely correct, I ran into the assertion and replicated it with the c api, and stumbled upon the fix.

The patch also assigns the src nodata value to the dst nodata value, possibly fixing #4625.

kss

[Even Rouault]

I have some doubt this is the correct fix (for #4011), but unfortunately I don't master this algorithm to be able to be affirmative. It looks more like something unrelated that hides the bug, and changes the behaviour of FillNoData(). Passing the mask band of the source dataset and the mask band of the target dataset is not the same thing, as the mask band of the target dataset will evolve when FillNodata runs, whereas the mask band of the source dataset is static. Anyway, Fillnodata() should work well with any passed mask band that has the right dimension. Otherwise something should be fixed in it, or its contract.

[Kyle Shannon]

I agree with your statement and diagnosis of my poor patch. Looking at the GDALFilterLine() function in rasterfill.cpp, I am not totally sure if the assertion is correct. The comment for the function gives no indication that it should evaluate true, nor does it make sense to me when stepping through. Same as you though, I do not have enough knowledge of the algorithm. Removing the [patch] tag from the summary.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.