Port xr_reproject from odc.algo

[Kirill888]

Most of the low-level utilities needed for Dask-backed reprojection are already in odc-geo. This is mostly

odc-geo/odc/geo/geobox.py

Line 909 in 11c5937

class GeoboxTiles:

and also:

odc-geo/odc/geo/overlap.py

Line 130 in 11c5937

class ReprojectInfo:

Expected interface:

xx = dc.load(.., dask_chunks= {}) # or any other supported load backend

# automatically choose resolution and bounding box, align pixel edges to 0
# automatically choose chunk size
yy = xx.odc.to_crs("epsg:3857")

# fully defined destination pixel plane
# configurable destination chunking
yy = xx.odc.reproject(GeoBox.from_bbox(..), chunks={'x': 2048, 'y': 4096})

• Support Dask and non-Dask inputs
• Support xarray and dask.dataarray
• Support xarray Datasets as well as DataArray
• Support reasonable automatic resolution, bbox and chunking determination
• Support any number of leading dimensions as well as optional interleaved band dimension: ..., y, x[,band]

[robbibt]

Hey @Kirill888 , a question: with a Dask-enabled .reproject method, will it be possible to apply re-projection to a dataset with multiple timesteps and take advantage of Dask to have it applied in parallel across all timesteps? At the moment, .reproject is applied in series to each timestep which makes it pretty slow for large datasets.

(that said, some option for non-Dask parallelism would also be useful - my current application uses data that originates in memory so Dask-only parallelism will be a little tricky for that)

[Kirill888]

Dask version will certainly have concurrency across timestamps as well as spatial chunks. In odc-stac there is a bunch of logic for data loading that deals with partitioning output space into spatial chunks and then applying data load concurrently with or without Dask. I feel like this shares a lot with Dask enabled reproject and should probably move into odc-geo in a somewhat generalized form: it should support temporal chunking for example opendatacube/odc-stac#81