Copernicus Data Space Ecosystem (CDSE) STAC catalogue

Within the Copernicus Data Space Ecosystem there are two STAC catalogues available:

1. Production catalogue available here: https://radiantearth.github.io/stac-browser/#/external/catalogue.dataspace.copernicus.eu/stac

2. Development catalogue available here: https://radiantearth.github.io/stac-browser/#/external/pgstac.demo.cloudferro.com

Sentinel-5P attributes to be discussed on 27.05.2024

Sentinel-1 attributes to be discussed on 20.05.2024

Additional attributes for bursts:

Sentinel-3 attributes to be discussed on 13.05.2024

Sentinel-2 attributes to be discussed on 06.05.2024

Mappings not directly defined in the Sentinel extensions:

Sentinel-2 STAC extension attributes to be discussed (not all present in Odata):

• s2:generation_time (also in s1)
• s2:datatake_id (also in s1)
• s2:product_type (also in s1, s3, s5)
• s2:tile_id
• s2:product_uri
• s2:datastrip_id
• s2:datatake_type
• s2:processing_baseline
• s2:reflectance_conversion_factor

See the table below for details.

STAC Sentinel extensions

A priority should be to update the STAC Sentinel extensions to be less extensive at least. The plan is to find spaces in the general STAC community for these fields.
As a first step, we need to identify which fields are actually relevant to the general public.

General fields

For descriptions of the fields, please refer to the Sentinel extensions or the stactools-package implementations.

Idea is to keep a small variant of the Sentinel extensions as best practices, mostly using other extensions.
EOPF is for "private" fields that externals are not interested in.

Percentages

Depending on the asset structure, some percentages may be provided as a classification percentages as proposed in https://github.com/stac-extensions/classification/pull/49

Deprecated

For completeness, the following fields did exist in the past and are already deprecated in favor of existing STAC fields:

CDSE querables attributes for Sentinel-2 L1C


CDSE STAC development roadmap

0. Simplify the geofootprint which is the largest attribute in the STAC response and slows down spatial querying (especially relevant for S-3 and S5P) ← to be provided by the Bureau d'Etude

1. Disable the overview displaying on items/assets level for selected collections e.g. Senitnel-3 where overviews generated in satellite projection is not displayed correctly. 

2. [Done at the collection level] Implement the CEOS-ARD extension for Level-2 and Level-3 products https://github.com/stac-extensions/ceos-ard First would be the Sentinel-2 L2A (stac item example https://github.com/stac-extensions/ceos-ard/blob/main/examples/optical-sr/item.json), then Sentinel-3 and Sentinel-5P products. There is no CEOS ARD for radar data yet. Currently it is only for CEOS ARD PFSes (so surface reflectance and temperature, and aquatic reflectance)

3. Populate the development catalogue with the Sentinel-2 L1C and L2A products and make the online version of the catalogue publicly available for testing

4. Add new collections based on the on the stac-tools for Sentinel-1 (https://github.com/stactools-packages/sentinel1), Sentinel-3 (https://github.com/stactools-packages/sentinel3), Sentinel-5P (https://github.com/stactools-packages/sentinel5p) These collections will conform to the new Sentinel's extensions: https://github.com/stac-extensions/sentinel-1 , https://github.com/stac-extensions/sentinel-3 ,  https://github.com/stac-extensions/sentinel-5p

4. Update ASAP current "more generic" extensions: EO, SAR, etc. Add new Sentinel collections excluding the Sentinel specific extensions.  

5. [In progress] Migrate some generic attributes from platform specific extension to more general extensions such as eo and sar. The rest of missions specific attributes (red crosses) should be maintained in the mission specific extensions not in the EOPF extension: https://github.com/CS-SI/eopf-stac-extension

7. Add to STAC Functionality of online/offline products. Add on demand product generation (url-s)

Missing STAC API functionalities to be potentially implemented in new STAC extensions

• Hiding entire extensions in the https://github.com/stac-api-extensions/fields This could mimic the Odata $expand option for advanced, ESA internal extensions. 
  
• Hiding items and assets within a Collection by an AOI
  
• User levels and permissions to filter the Json response for general & expert CDSE users. 
  

Modification of current STAC extensions:

• Add processing:version and processing:datetime: https://github.com/stac-extensions/processing/pull/32
• Deprecate s1:processing_datetime in favor of processing:datetime: https://github.com/stac-extensions/sentinel-1/pull/1
• Deprecate baseline and generation time: https://github.com/stac-extensions/sentinel-2/pull/14
• Deprecate snow/ice cover: https://github.com/stac-extensions/sentinel-2/pull/13
  

Various issues related to population of the STAC catalogue:

1. NaN values in the Sentinel-2 viewing geometry: https://esa-cams.atlassian.net/browse/GSANOM-15086
   
   Coordination desk reply:
   

   This product is absolutely normal with respect to the current IPF implementation. It is really small as only few pixels from the datastrip intersect this tile as you can see in the CDSE and QGIS screenshots attached (the rainbow effect visible for the TCI displayed in QGIS is normal, and due to the fact that the different spectral bands do not share exactly the same footprint).

   A consequence of this very limited intersection between the tile footprint and the datastrip footprint is that we get only NaN viewing incidence values for several bands in the tile metadata, resulting in NaN mean viewing incidence values for these bands. This is because the grid on which the viewing incidence values are computed is very coarse (5 km x 5 km). Then this behaviour could happen sometimes for this kind of products (with limited intersection between the tile and the datastrip), and did happen before.