Investigate antimeridian improvements and pyproj updates

[djhoese]

I had these changes lying around and needed to get them out of the way. Maybe I'll get back to this soon...for now it is here for comment if people are really really bored.

• Closes #xxxx
• Tests added
• Tests passed
• Fully documented

[djhoese]

Needs versioneer fixes from #648

[codecov]

Codecov Report

Attention: Patch coverage is 98.48485% with 1 line in your changes missing coverage. Please review.

Project coverage is 93.98%. Comparing base (98f20a7) to head (2c4004b).
Report is 14 commits behind head on main.

Files with missing lines	Patch %	Lines
pyresample/test/test_kd_tree.py	85.71%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #645   +/-   ##
=======================================
  Coverage   93.98%   93.98%           
=======================================
  Files          86       86           
  Lines       13543    13534    -9     
=======================================
- Hits        12728    12720    -8     
+ Misses        815      814    -1     

Flag	Coverage Δ
unittests	93.98% <98.48%> (+<0.01%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coveralls]

coverage: 93.68% (+0.003%) from 93.677%
when pulling 2c4004b on djhoese:feat-antimeridian-lonwrap
into 873a511 on pytroll:main.

[djhoese]

@mraspaud @pnuu I'm curious what you guys think about this PR and if I should split it up or go further or I don't know what. The main important change that I wanted was the DynamicAreaDefinition's change to use +lon_wrap=180 which allows extents to go beyond 180 longitude (0-360 essentially). However, that gets complicated because for that to be useful the nearest neighbor resampling also needs to support those coordinates which means removing the valid input/output index arrays. Then we get more complicated since there is base kdtree resampling (numpy-style), then an xarray-based/dask class used by satpy with caching, and an xarray/dask class with included caching in the "future" subpackage of pyresample.

Do I maybe switch this PR to be just the DynamicAreaDefinition changes? Then do another PR for the future class to drop valid input/output arrays? Then do another PR for the xarray-based class (and maybe the numpy functions) to drop valid input/output? I'm not sure.

This doesn't even begin to talk about my real desire which is to explore the XYZ transformation by pyproj changes after all of this (which I have working locally).

[pnuu]

I'd say do the DynamicAreaDefinition first and the others later on.

Just a thought on the input/output array stuff perhaps be adapted based on the validity range of the coordinates? I don't remember exactly, but I think at the masking we would know whether the coordinates are from -180 to 180 or from 0 to 360. I'm not say not to remove them if it makes new things possible, just a thought.

[djhoese]

For validity arrays, I think the bottom line, from what I can tell, is that in modern practices they are unnecessary. From the sound of it, most users are probably masking their geolocation already or Satpy is or the input files people are reading do. Or as a last resort the computations by pyproj will make them infinity or NaN.