Blockwise coregistration apply method does not take nodata properly into account

[adehecq]

When the DEM is resampled during the blockwise coregistration, if nodata value exist, they will "leak" around the gaps.
A way to visualize it is to run the plot_blockwise_coreg.py example script and at L 76* to create an artificial gap in the DEM, e.g. with:

dem_to_be_aligned.data[0, 450:500, 450:500] = -9999
dem_to_be_aligned.set_ndv(-9999)

The nodata "leak" shows up on the upper edge of the gap. See attached figure.
The issue is that the nodata values are used in the resampling, so the "leaked" values do not match the nodata value and can be extremely difficult to filter out.

I just checked and apparently, the issue shows up when running the same example with the Nuth & Kaab coregistration instead, but to a lesser extent.

• Note: the script must be interrupted at that line. For some reason, if the entire script is run and then L 75-77 are re-run, without any change, they fail with the following error. Maybe one of the variables is being modified later in the script?

LinAlgError: Matrix is singular.

[adehecq]

Apparently, something funky is going on with the NaN mask. It should simply be translated and not warped like this.

This is due to the lines here. I'm not sure why the filling is needed here, as in my test case, tranformed_points does not contain any gap. Any idea @erikmannerfelt ?
Anyway, the issue is fixed by replacing those lines with:

x_inds = transformed_points[:, :, 0].copy()
y_inds = transformed_points[:, :, 1].copy()

But I'm not sure if that won't break other things? This is another argument towards #140 !

[adehecq]

Actually, it solves the issue for NuthKaab, but not for blockwise. For that one, apparently the dilate_mask option has no effect...
And it's impossible to stop the execution in the middle to check some results due to the asynchronous run.

[adehecq]

Weirdly, in blockwise, the function apply_matrix is run during coreg.fit, instead of coreg.apply (as can be seen by printing out on screen during that function). I really don't understand what is going on...

[adehecq]

I'm giving up. @erikmannerfelt I hope you can check that when you come back.

[erikmannerfelt]

Am I right to assume that the problem only occurs when Rasters are supplied, and not when numpy arrays are given to the Coreg functions?

I've identified the problem and I have a fix for Rasters. Now I just need to know if you found another problem or if we are talking about the same thing

[adehecq]

Am I right to assume that the problem only occurs when Rasters are supplied, and not when numpy arrays are given to the Coreg functions?

I've identified the problem and I have a fix for Rasters. Now I just need to know if you found another problem or if we are talking about the same thing

No, if you check the example script, a numpy array is passed, not a Raster. This issue actually occurred before PR #175.

[erikmannerfelt]

Okay, thanks. I'll see if my fixes solves it.

[erikmannerfelt]

It seems to work! I'll mention it in the PR.

[adehecq]

Fantastic!