Update module to handle both geodetic and cartesian coordinate systems

[reweeden]

This PR refactors the module structure, docstrings and readme to reflect what I've learned about the different CMR coordinate systems to make it more clear what coordinate system each function will work correctly in.

Near the poles the geodetic and cartesian systems become very different from eachother. Luckily we can still achieve approximately the right polygons using cartesian operations (shapely) if we have a sufficiently dense polygon. This PR adds a 'densify' operation that uses pygeodesy to densify a polygon along great circle arcs. This should allow us to continue using cartesian coordinates in CMR, but produce more accurately split polygons by simply adding a densify operation to the start of our tranformation pipelines.

Old densify implementation by maximum line segment length

Here's an example of how a cartesian rectangle looks after being densified and rendered in webmercator projection:

And a cartesian rectangle with a hole in the middle:

New implementation based on cross track error

4 point diagonal box in cartesian space

Densified with an error tolerance of 50km:

Densified with an error tolerance of 20km:

Densified with an error tolerance of 5km:

With this implementation edges are only densified when they need to be in order to reduce error. For instance edges that run due north/south will not be densified at all since they are the same in both cartesian coordinates and the geodetic great circle model. Similarly, edges that run along the equator will also not be densified, but edges that run parrallel to the equator at a high latitude will be densified quite a lot.

For instance this polygon:

Densified with an error tolerance of 5km:

Only results in a small number of points being added along a single edge.

Pull Request Checklist

I have:

• performed a self review of my code I&A code style
  • Resources and Data Structures are sorted by ABC or a defined sorting pattern
• updated the documentation accordingly
• verified required action checks are passing
• bumped the version number as appropriate

[mattp0]

This feels more like readme info. I think as a user of the module. Id rather just have a bit of info on the constraints, the key bits about umm-g formatted polygon. The rest feels a bit noisy. I think linking to a readme for more info would make more sense. its just a huge text block when you hover the transformations.

[reweeden]

Interesting take. I find it quite useful to have all the info I need show up when I hover over something in my editor rather than have to exit to another application (web browser), find the correct third party link and look stuff up there. I quite like using doc strings to document the code and I also think it makes the docs less likely to go out of date as the code churns.

[mckadesorensen]

I am inclined to lean towards what Matt is saying. It does kind of feel like a readme. That being said, I also see the case for having it here and am more than happy with its current location.

[mattp0]

I like having the doc string but this is TLDR situation imo.

There are several challenges with representing polygons on a spherical surface,
the primary being that since all straight lines will 'wrap around' the surface,
it becomes impossible to unabmiguously define a polygon using only an ordered
set of points. This is the primary reason for the CMR requirements, as those
additional constraints make it possible to determine exactly which area is
meant by a set of points. Unfortunately, the polygons that we get from the data
provider won't necessarily meet those same requirements and we must use mission
specific knowledge to convert them to an unambiguous set of polygons to be used
by CMR.

Im not sure this is valuable in my editor when im trying to use the transformations. but this isnt a show stopper.