Add the fill_value parameter to GeocodeCov CPU module

[gshiroma]

This PR adds the fill_value parameter to the GeocodeCov CPU module. It is inspired by #337 and sets the fill value of the layover/shadow mask layer in the Static Layers (STATIC) product to 255, instead of the default value of 0. Details about the issue and the discussion can be found in that PR.

The C++ and Python interfaces have been updated with the new parameter. The two CPU geocoding algorithms, interpolation and area projection, have also been updated to account for the new parameter. For the interpolation algorithm, the array is first filled with fill_value before interpolation occurs. In contrast, for the area projection algorithm, fill_value is applied after multilooking. This is necessary because the area projection algorithm accumulates averaged values (multilooked backscatter), and applying fill_value before data accumulation could cause it to be interpreted as a valid value.

[gshiroma]

We just met to review this PR, and it was decided that we should add a warning message to alert the user when casting the data or fill value to the output raster type changes the data or fill value. In addition, the docstring for fill_value needs to be updated to explain these changes. The new feature should also be covered by a unit test.

[gshiroma]

We just met to review this PR, and it was decided that we should add a warning message to alert the user when casting the data or fill value to the output raster type changes the data or fill value. In addition, the docstring for fill_value needs to be updated to explain these changes. The new feature should also be covered by a unit test.

@hfattahi , @bhawkins , and @nemo794 . I implemented all the suggestions from our PR review meeting. I can’t pinpoint specific commits because the changes are spread across several commits. The changes are:

• Added a unit test.
• Added warning messages when data or fill values are cast while being stored in the output raster files.
• Replaced the invalid complex fill value NaN + 0j with NaN + NaN.j.

Would you mind taking another look at this PR?

[bhawkins]

LGTM

[hfattahi]

looks good to me overall. Good functionality added. I have one minor question below

[hfattahi]

Can you clarify what do you mean exactly here? Do you intend to provide a warning that the geocoding is done by casting integer to float and then the final geocoded value will be cast to integer by isce3::io::Raster, during writing the output?

[gshiroma]

That's correct, @hfattahi . @bhawkins asked that the user be informed about this casting. This is the same type of casting that caused the “problem” in the STATIC workflow, where the NaN values were silently cast to 0.

[gshiroma]

@bhawkins , just letting you know that I'm setting the fill value for the GCOV & GSLC inputDataExceptionMask to 65535 in the commit c2e7f6e (instead of issuing a new PR).