AMSR2 reprojections have "stretched" border pixels

[kathys]

I am able to create P2G V3.0 AMSR2 L1B reprojections that closely match the V2.3 files, except for the pixels that border the image. Those pixels appeared unrealistically "stretched out". I am creating files using the default projection, default products, and default resampling method (nearest neighbor).

Here are examples from AMSR Band 89ah (data from Hawaii).

It is hard to see from this. A noisy longer example overpass from Miami shows it better:

[djhoese]

Do you have the log files for this? I'm guessing the resampling parameters are different?

Can you point me to the data?

[kathys]

Sorry, I meant to provide data and log files.

Input data files
bumi:/data/users/kathys/test_data/amsr/2022_examples/GW1AM2_202209121053_051D_L1DLBTBR_1110110.h5
bumi:/data/users/kathys/test_data/amsr/2022_examples/GW1AM2_202209120729_019D_L1DLBTBR_2220220.h5

Output GeoTIFF and log files
bumi:/data/users/kathys/test_data/amsr/output_v23
bumi:/data/users/kathys/test_data/amsr/output_v30

I looked in the log files and I can see that they are both using nearest neighbor as the resampling method.

[djhoese]

So I think I have a "solution". @kathys you can test it yourself by specifying --method nearest --radius-of-influence 7200. This produces a much smaller outer border. However, this 7200 was calculated by taking the P2G v2.3 value for "distance upper bound" of 12 and multiplying it by 600. The 12 from v2.3 is 12 output grid cells. The 600 is an estimate in that I believe our default wgs84_fit grid is ~600m pixel resolution at the equator (from memory) so the geocentric meters that pyresample's nearest neighbor works with would be 12 grid cells * 600m for approximately what the geocentric spacing might be.

By default, Satpy/pyresample was trying to get at this radius of influence based on the input swath and output grid and came up with 10000. This is based on the 5000m nadir resolution that I have coded into the reader multiplied by 2 as a "nadir to limb" factor.

The problem with all of this: only Satpy's estimate adjusts to the input and output data and where it is on the Earth (using geocentric meters instead of lon/lat degrees or projected meters of the output grid). The 12 grid cells of v2.3 was dependent only on the output grid and not the input data which doesn't make much sense to me. The 7200 is based on the old value and happens to work in this case. I can play around with values and see what looks best without introducing holes but trying to get to that limit may cause holes in special cases (high latitudes, etc).

</rambling>

[djhoese]

FYI a value of 5000 introduces holes near nadir. So maybe 7200 is a good enough value?

[kathys]

Let me make a couple of images using this value. Does this also affect AWIPS NetCDF images?

[djhoese]

Yes. This is the resampling step so everything in the writing stage is affected. The easiest decision might be to just go with 7200 as the closest to the original value for now. The estimates that Satpy/pyresample do and came up with 10000m could be improved and the reader could be updated with more information like the expected/estimated limb resolution. Pyresample could then use that in its calculations.

[kathys]

Okay, let me make some test images, but that sounds good Dave.

[kathys]

@djhoese Images look very close to originals. I think the 7200 should be implemented and an issue written for a the 3.1 milestone for Satpy/pyresample improvements to be implemented for the reader.