Update rubbersheeting upsampling method

[xhuang-jpl]

This PR is to replace the default Nearest Neighbor upsampling method in the rubbersheeting with the bilinear method as suggested by the Science team members.

[seongsujeong]

LGTM, but please be advised that saving intermediate file in ENVI format may cause issue that GDAL reader misinterprets the raster's format. See here for detail.

[xhuang-jpl]

here

Thank you @seongsujeong, it seems strange that GDAL misinterprets the ENVI format.

[seongsujeong]

That's related to how GDAL recognizes the file format of raster. It makes use of first few bits of the file (i.e. magic bytes. So, the first few bytes of the ENVI file coincides with magic bytes of certain file format, GDAL will treat the raster file as such. For example, the first few bytes of ENVI raster starts with ff d8 ff e0 then GDAL will try to load ENVI file as JPG.

This issue has been found from COMPASS, which caused very few processes to fail. More information is documented in the issue below:
opera-adt/COMPASS#206

[xhuang-jpl]

That's related to how GDAL recognizes the file format of raster. It makes use of first few bits of the file (i.e. magic bytes. So, the first few bytes of the ENVI file coincides with magic bytes of certain file format, GDAL will treat the raster file as such. For example, the first few bytes of ENVI raster starts with ff d8 ff e0 then GDAL will try to load ENVI file as JPG.

This issue has been found from COMPASS, which caused very few processes to fail. More information is documented in the issue below: opera-adt/COMPASS#206

Interesting, thank you @seongsujeong for the classification. From the code, it seems that GDAL tries to recognize ENVI format via reading ENVI's header file (.HDR .hdr etc.) which starts with ENVI string. You are right that it is because the first few bytes of ENVI file coincides with the magic bytes.

https://github.com/OSGeo/gdal/blob/7041600447d878dee35b64f5510c1c232de3616c/frmts/raw/envidataset.cpp#L1899

[seongsujeong]

This happens even when .hdr file exists. I'll send you a separate message to test it by yourself.

[xhuang-jpl]

This happens even when .hdr file exists. I'll send you a separate message to test it by yourself.

Thank you @seongsujeong, I get your point and no need the test anymore.

[xhuang-jpl]

In addition, I checked the resampling steps, the resampling reader uses the plain binary file so there will be no issue for this change, but we should keep track of this issue for other steps.

isce3/python/packages/nisar/workflows/resample_slc_v2.py

Line 179 in 7bb4eb8

az_off_reader = np.memmap(

[seongsujeong]

Sounds good. Thanks for checking the code's behavior @xhuang-jpl