Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[load_stac]: add resolution parameter? #445

Closed
clausmichele opened this issue Jun 28, 2023 · 4 comments
Closed

[load_stac]: add resolution parameter? #445

clausmichele opened this issue Jun 28, 2023 · 4 comments

Comments

@clausmichele
Copy link
Member

I'm trying to implement load_stac in openeo-processes-dask Open-EO/openeo-processes-dask#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
Copy link
Member

m-mohr commented Jun 28, 2023

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
Copy link
Contributor

jdries commented Jul 1, 2023

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
Copy link
Member

m-mohr commented Sep 30, 2023

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

@m-mohr m-mohr closed this as completed Sep 30, 2023
@m-mohr m-mohr closed this as not planned Won't fix, can't repro, duplicate, stale Sep 30, 2023
@clausmichele
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants