Move raster footprint functionality into a class

[pjhartzell]

Updated Description

Related Issue(s): None.

Description: The raster footprint utility often produces incorrect geometry polygons when the data spans the edge of the sinusoidal projection used by MODIS and VIIRS. A fix requires an alternative densification approach and a custom reprojection function. There is currently no convenient way to override these steps in the raster footprint utility since they are: 1) bundled into a single function (densify_reproject_simplify) and 2) that function exists at the end of a chain of function calls.

This PR replicates the functionality of the raster footprint utility in a class (named RasterFootprint) with an eye toward subclassing for selective method overrides. In addition to breaking out individual methods for the densify, reproject, and simplify steps, alternative constructors are provided for footprint creation directly from an href or from a file opened with rasterio (a rasterio DatasetReader object). An alternative densification function is also provided; you can now choose to densify by factor or by distance.

The existing raster footprint functions are retained, but marked as deprecated. Their functionality is fully contained in the new RasterFootprint class and the functions themselves now rely on RasterFootprint.

PR checklist:

• [x] Code is formatted (run scripts/format).
• [x] Code lints properly (run scripts/lint).
• [x] Tests pass (run scripts/test).
• [x] Documentation has been updated to reflect changes, if applicable.
• [x] Changes are added to the CHANGELOG.

Original Description (for context)

Related Issue(s): None.

Description: The raster footprint utility often produces incorrect and globe-spanning geometry polygons when the data is on the edge of the sinusoidal projection used by MODIS and VIIRS.

• The nature of the sinusoidal projection precludes data that spans the antimeridian, so the globe-spanning polygons are a symptom of bad vertices.
• It appears that vertices very close to the projection edge are occasionally projected beyond the antimeridian. Some experimenting with the basic sinusoidal projection equations that are part of this PR indicate a high sensitivity to small changes in the coordinates and/or projection parameters at the projection edges.

This PR provides a fix to create correct raster footprints at the edges of the sinusoidal projection.

Approach:

• Densely infill the footprint polygon (using the ground pixel size as the densify interval) while still in grid coordinates.
• Project the densified grid polygon vertices to spherical lon/lat (using equations provided by a MODIS user guide) and throw out any coordinates with an abs(longitude) value greater than 180. This should be able to be done without the custom projection equations, but I am unable to force proj to not wrap the longitude coordinates.
• By densifying at the ground distance of a single pixel, we should be within at least one pixel of the antimeridian (should the furthermost pixel be thrown out due to reprojection error/instability).

Notes:

• I converted the existing raster geometry code to a base class, which is then subclassed to recreate the original functionality (the "Default" subclass) and new functionality that handles sinusoidal data (the "Sinusoidal" subclass). This is fine, but it does require some gymnastics to retain the existing function signatures.
• There is a new, but unused, sinusoidal_pixel_to_grid function in projection.py. It will be used by the MODIS stactools-package and it seemed natural to place it alongside the new sinusoidal_grid_to_lonlat function.
• I changed the name of an underscored/private function: _densify() to _densify_by_factor(). The name parallels the new _densify_by_distance() function used by the sinusoidal class.

Example: Current, incorrect behavior (pink) for an h01v11 MODIS tile (MCD15A2H.A2022025.h01v11.061):

Proposed, correct behavior (green) via this PR for the same MODIS tile:

[gadomski]

Free functions that duplicate class methods are now marked as deprecated since version 0.4.4. Should we bump that to 0.5.0?

We don't have an explicit deprecation policy, but IMO it's best to give at least one release cycle for the deprecations to kick in. So depreacted in 0.4.4, removal planned for 0.6.

Thoughts? Is the different underscoring a breaking change?

I think the problem was due to using rasterio wheels rather than building from scratch (f75b36c8d4d299ce32247dfe10827ba413876fdb). I agree that the test is a bit fragile but #401 should fix it.