[load_stac]: add resolution parameter?

[clausmichele]

I'm trying to implement load_stac in openeo-processes-dask https://github.com/Open-EO/openeo-processes-dask/pull/127.

The main libraries we could use to perform the stac to xArray bridge are stackstac and odc-stac. I'm currently using stackstac since it provides better support for metadata, but it would be possible to use odc-stac as well without much effort.

I'm currently facing this issue, which occurs if a STAC Collection and Items are valid but do not provide enough details to establish automatically the data resolution:

E                           ValueError: Cannot automatically compute the resolution, since asset 'preview' on item 0 'S2A_MSIL2A_20180502T102031_R065_T32TPS_20201012T045559' doesn't provide enough metad
ata to determine its native resolution.
E                           We'd need at least one of (in order of preference):
E                           - The `proj:transform` and `proj:epsg` fields set on the asset, or on the item
E                           - The `proj:shape` and one of `proj:bbox` or `bbox` fields set on the asset, or on the item
E
E                           Please specify the `resolution=` argument to set the output resolution manually. (Remember that resolution must be in the units of your CRS (http://epsg.io/32632)---not neces
sarily meters.

I am currently testing against https://planetarycomputer.microsoft.com/api/stac/v1/collections/sentinel-2-l2a

I was wondering if this is a common scenario. Is the proj extension is mandatory or not? If not, would it make sense to allow to pass a resolution parameter to overcome this?

cc @soxofaan @m-mohr @LukeWeidenwalker

[m-mohr]

Hmm, the preview image should be ignored, I think. It's just a preview. proj is not required in STAC so it might always happen that some STAC data can't be loaded. Ideally it's in the metadata though as otherwise you may need to specify it per asset (e.g. the S2 bands have different resolutions) and that quickly gets complicated.

[jdries]

Note that it's indeed quite common for stac metadata to be incomplete. The fallback is to get resolution information from the actual raster. This is of course slower, we often make the assumption that we can fetch metadata from the first raster, and that it's the same for other rasters that are loaded. (This is not always true, and then you get an error.) What we also do is inferring a target resolution and crs from resample_spatial or resample_cube_spatial.

[m-mohr]

Does this solve the issue? If not, let me know an I can reopen.

[clausmichele]

Hi @m-mohr, fine to close this for the moment. For some collections another workaround is to filter directly using the gsd property.