Fix handling of lon/lat coordinates on CRS with prime meridian != 0

[djhoese]

For a long time we have used a shortcut when transforming lon/lat area coordinates to generic "lon/lat degrees" by checking if the CRS of that area is "geographic" and returning the original input coordinates. This is really only correct in the cases where the CRSes are the same. This shortcut was causing issues in nearest (and other) resamplers where if you resampled to an AreaDefinition with a shifted prime meridian (ex. at 180/-180). In these cases the resampling was using the non-shifted lon/lat coordinates which usually meant you got a black image as a result of resampling. This PR removes this shortcut.

By removing this shortcut this means that the utility/custom Proj class in pyresample/_spatial_mp.py is no longer needed as it doesn't actually do anything any more. I will remove this utility class shortly.

• Closes #xxxx
• Tests added
• Tests passed
• Passes git diff origin/main **/*py | flake8 --diff
• Fully documented

[codecov]

Codecov Report

Merging #447 (dd82610) into main (93df018) will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #447      +/-   ##
==========================================
+ Coverage   94.21%   94.28%   +0.06%     
==========================================
  Files          68       68              
  Lines       12349    12361      +12     
==========================================
+ Hits        11635    11654      +19     
+ Misses        714      707       -7     

Flag	Coverage Δ
unittests	94.28% <100.00%> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
pyresample/_spatial_mp.py	82.94% <100.00%> (-0.63%)	⬇️
pyresample/bilinear/_base.py	95.80% <100.00%> (ø)
pyresample/bilinear/xarr.py	92.90% <100.00%> (ø)
pyresample/bucket/__init__.py	97.95% <100.00%> (ø)
pyresample/geo_filter.py	100.00% <100.00%> (ø)
pyresample/geometry.py	87.17% <100.00%> (+0.01%)	⬆️
pyresample/grid.py	88.05% <100.00%> (+0.55%)	⬆️
pyresample/test/conftest.py	98.01% <100.00%> (+4.54%)	⬆️
pyresample/test/test_bilinear.py	100.00% <100.00%> (ø)
pyresample/test/test_geometry.py	99.51% <100.00%> (-0.01%)	⬇️
... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

[gerritholl]

Looks good to me.

[djhoese]

Ok, now this PR is done. There were a couple inconvenient usages of the Proj utility class as a stand-in for Proj_MP or Proj where nprocs was being passed to either one even though Proj doesn't actually support that kwarg and doesn't do anything with it (just blindly accepts it). I'm not a fan of that usage. If we want a class to act as both and only do multiprocessing stuff when nprocs is greater than 1, then we should do that, not have a class that hides keyword usage or not usage.

[djhoese]

Also, I ran satpy's tests against this PR and it was fine.

[djhoese]

Whoa, unexpected, but this seems to fix nearest's (and possibly bilinear @pnuu ) handling of AreaDefinitions that start on the positive longitudes (0 to 180) and cross the antimeridian going 180-360.

Previously, it would just cut this image off at 180.

[coveralls]

Coverage increased (+0.06%) to 94.126% when pulling dd82610 on djhoese:bugfix-lonlat-pm180-nearest into 93df018 on pytroll:main.

[mraspaud]

LGTM, nice with the simplification!