Doc: Add Python docstring for gdal.FillNodata

[dbaston]

Side note, I found the first result in the example a little surprising.

[rouault]

I found the first result in the example a little surprising.

what exactly was surprising ? at first sight, that seems plausible to me

[dbaston]

I would have expected the results in the two columns to be the same.

[dbaston]

Disregard, I posted a different example than the one I was troubleshooting:

import numpy as np
data = np.array([[1, 1, 1, 1], [9, 9, 9, 9], [9, 9, 9, 9], [4, 4, 4, 4]], dtype=np.float32)
ds = gdal.GetDriverByName("MEM").Create("", 4, 4, eType=gdal.GDT_Float32)
ds.WriteArray(data)
mask = data != 9  # replace pixels with value = 9
mask_ds = gdal.GetDriverByName("MEM").Create("", 4, 4, eType=gdal.GDT_Byte)
mask_ds.WriteArray(mask)
gdal.FillNodata(ds.GetRasterBand(1), mask_ds.GetRasterBand(1), 5, 0)

with result

[[1.       1.       1.       1.      ]
 [2.070572 2.070572 2.070572 2.      ]
 [2.929428 2.929428 2.929428 3.      ]
 [4.       4.       4.       4.      ]]

I would have expected all columns to have the same result. But the first three columns consider values directly above and below as "top left" and "bottom left" and the values in the next column to the right as "top right" and "bottom right". In the last column, the values directly above and below are considered for all of "top left", "top right", "bottom left", and "bottom right", giving a different set of interpolation weights.

That seemed confusing, so I changed the example for the docs.

[coveralls]

coverage: 69.09%. remained the same
when pulling 8f39aca on dbaston:python-api-docs
into a393f0a on OSGeo:master.