Conversation
| ### Dataset organization | ||
|
|
||
| 1. STAC collections will be mapped to openEO collections | ||
| 2. All STAC products in the same collection have the same set of 'bands', that are defined at collection level. This allows backends to look up the selected bands in a product. |
There was a problem hiding this comment.
I assume this means eo:bands in summaries?
There was a problem hiding this comment.
I was thinking more in terms of raster:bands, even though I didn't explicitly require that one yet. It's more about what we in openEO have in the standard 'bands' dimension.
There was a problem hiding this comment.
I see, makes sense.
We are currently discussing merging raster:bands and eo:bands anyway, so this might get a bit less messy in the future.
| ### Projection information | ||
| openEO backends require knowledge about the projection system, which should be provided at the collection level if it is the same for all products. | ||
| Collections with multiple projections, for instance based on UTM, can specify it at product level. | ||
| The [proj:epsg](https://github.com/stac-extensions/projection#item-properties-or-asset-fields) property is used to specify the projection. |
There was a problem hiding this comment.
From other implementation I know that they need two of proj:transform, proj:shape, proj:bbox - This is not required in Platform, right?
There was a problem hiding this comment.
it would actually be very helpful, but not a lot of catalogs have this info in the metadata.
| ### Product geometry | ||
|
|
||
| The product geometry specifies the footprint of the data in the raster file. It may be used by the backend for spatial filtering, | ||
| so any pixel outside of the footprint may not be loaded by the backend. The geometry is provided in EPSG:4326, but may be interpreted in the |
There was a problem hiding this comment.
This is invalid in STAC and contradicts with the "if this is perceived to be the case, the STAC specification should get precedence". The geometry must always be EPSG:4326, but you could provide a geometry and bbox in the native projection via proj:geometry and proj:bbox.
There was a problem hiding this comment.
But the geometry does specify the footprint in EPSG:4326 right? Or is the part about the interpretation wrong?
Maybe I should add that proj:geometry can be used as way to provide a less ambiguous geometry?
There was a problem hiding this comment.
Yes, the geometry must be EPSG:4326. proj:geometry can be used to specify a geometry in the native CRS (bbox works the same way). What I'm confused about is "but may be interpreted in the product projection system." - What does this mean/imply? I guess this should be dropped and replaced with a mention or the proj: fields?
Co-authored-by: Matthias Mohr <m.mohr@uni-muenster.de>
dthiex
left a comment
dthiex
left a comment
There was a problem hiding this comment.
Going through our documentation as part of SAP05 and think it would be great to finish and add this.
|
|
||
| This document lists the requirements for a data provider that wants to make a dataset available as a | ||
| new collection in the openEO platform. More specifically, it defines the requirements for STAC catalogs. The STAC specification | ||
| is also used within openEO, and is a common choice in the EO community. |
|
|
||
| 1. STAC collections will be mapped to openEO collections | ||
| 2. All STAC products in the same collection have the same set of 'bands', that are defined at collection level. This allows backends to look up the selected bands in a product. | ||
| 3. Assets in a product are raster files that contain a single band. |
There was a problem hiding this comment.
This is not clear to me. What is meant by product? A single item? If that is stored as GTIFF it can contain also several bands.
| These are some often used examples: | ||
| - [eo:cloud_cover](https://github.com/stac-extensions/eo#eocloud_cover) for cloud cover percentage | ||
| - [sat:orbit_state](https://github.com/stac-extensions/sat#satorbit_state) for orbit direction (ascending/descending) | ||
|
|
There was a problem hiding this comment.
I think it would make sense to add/link to the things we already collected here: https://github.com/Open-EO/openeo-stac-extensions
m-mohr
force-pushed
the
main
branch
2 times, most recently
from
d6e3051 to
4d14eb5
Compare
| 2. S3 authentication headers | ||
|
|
||
| ## STAC metadata | ||
|
|
There was a problem hiding this comment.
Another useful extension would be the raster one, specifically when working with data that needs to be have rescale and offset applied https://github.com/stac-extensions/raster#raster-band-object.
In particular, this is essential for Senitnel-2 L2A to BOA conversion, as specified here: https://sentinels.copernicus.eu/web/sentinel/technical-guides/sentinel-2-msi/level-2a-algorithms-products
4 participants
No description provided.