STAC ICD for PRIP - 1.0

EOPF_SPECIFICATION

Fixed

Proposal to keep the same precision as for CDSE (second or µs ?)

REQ-0050 augmented in v1.1 (page 20)

specify the set of queryables in tailored ICDs

Added in v1.1 : add column "queryable" into "common attributes" table

Fixed

It's up to client's implementation and should be adressed by "tailored ICD"

Added in v1.1 (REQ-0410 & REQ-0305): Only single part upload supported in case of Zarr files

No known standard to include s3 credentials into IAM → out of scope of this ICD. It must be described by infrastructure provider.

Should go into tailored ICDs 

Closed

PRIP client point of view, retrieving an asset needs to:

List all S3 objects sharing the prefix provided by the asset link, leveraging the ListObjectsV2 S3 operation

Question already discussed with ESA, and submitted to its arbitration.
In which way it can raise the maintenance cost ? 

Precision added in STAC-PRIP-API-REQ-0400 (use of .zmetadata file to discover the content)

Final discussion: no needed changes for the moment (no checksum info in .zmetadata) 

One collection corresponds to a unique product_type at PRIP level.

Quota adjustement should be managed at operations level and arbitrated by ESA.

Not to describe in the ICD

Correction in 1.1 : Requirement on "Quota management" removed

Fixed

We propose to add an additional requirement on the maximum number of returned items as configurable, but not less than 100 items (lower limit).

New requirement added in v1.1 : STAC-PRIP-API-REQ-0203 – STAC API limit parameter

Closed

Not to describe in the ICD

For the moment, an existing product shouldn't be updated on PRIP

Zarr item is provided in extended form (folders & sub-folders) → neither file extension nor checksum are relevant here

Open point / to have discussion internally (ESA) : which concatenation format to require ? (zip or tar)

no enforcing at prip level ?

Closed

More info needed regarding "Note:  It  is  assumed  that  the  AWS  CLI  is  configured  with  the  expected  S3  API  endpoint  and authentication credentials."

It is not clear how to the authentification will look like. Sample AWS CLI config file would be appreciated. Are the short-term credentials to be used or the long-term ( https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-files.html )? Are the https://docs.unified-streaming.com/documentation/vod/cloud/amazon/aws_s3_authentication.html#aws-security-tokens to be used?

Should depend on the provider → not candidate for the ICD. rather provided in tailored ICD

should S3 key for each downloading client (entity)

Not ICD related

Fixed

It is sufficient to explain abbreviations only once (e.g., STAC, PRIP, API). On the other hand, abbreviations must be explained at the first time they are mentioned in the text (e.g. EOF, EOPF, JSON). A list of abbreviations at the beginning of the document would also be helpful.

We will add a list of abbreviations at the beginning of the document.

Table added in page 4 (v1.1)

2.2/page 9

ff.

Fixed

A PRIP instance manages product for a given Sentinel Mission. → A PRIP instance manages products for a given Sentinel mission.

Compared to the formal PRIP ICD, current document does not currently address following PRIP functions: → Compared to the formal PRIP ICD, the current document does not address the following PRIP functions:

The entire document should be thoroughly reviewed for grammar in general and uppercase and lowercase lettering more specifically.

Corrections included in v1.1

STAC-PRIP-ITEM-REQ-0090 STAC Asset properties, page 25

File extension .zarr in Local Folder path

Fixed

The example for the Local Folder path should include the .zarr file extension, since the <product_id> does not contain it.

<product_id>.zarr/...

Corrections included in v1.1

STAC-PRIP-ITEM-REQ-0100 STAC Asset href, page 26

File extension .zarr in product path

Fixed

The <product_path> should include the .zarr file extension.

<product_path>=<product_id>.zarr/<folder>/...

STAC-PRIP-ITEM-REQ-0101 Bucket naming convention, page 26

Fixed

The bucket name in the text does not match the bucket name of the URLs in the table.

Also, the URL of the 10m Band 2 of a S02MSIL2A product would be .../measurements/reflectance/r10m/b02. This also applies to various places in the Use case examples section, page 31 ff.

The bucket name in the table is : prip-sentinel-2-l2a
Thus it's compliant with pattern "prip-<mission>-<productType>" (maybe rename mission to constellation ?)

Band 2 URL : Corrections included in v1.1

3.4.3.2/page 34 ff.

Fixed

Maybe leave out the assets and item_assets from the examples since they are not defined finally for the EOPF products?

It's about presenting the exemples : put ....... instead of asset products !!

Need for Jolyon's arbitration 

Corrections included in v1.1:assets removed in examples

3.4.3.3/page 36

Fixed

The example is referring to https://pgstac.demo.cloudferro.com/. Maybe use an anonymous URL like in the other examples.

Corrections included in v1.1

2.1/page 8

Fixed

The PRIP API specifies not only the access to newly published Sentinel data products, it also supports the on-demand processing of (user level) data products, as defined in the  PRIP ICD ESA-EOPG-EOPGC-IF-3 section 2.1. "ODPRIP" is an extension of "PRIP" and its data structures and functions (section 4 of the PRIP ICD) should also be supported in the new STAC-based ICD.

The restricted scope of the document is described on page 9. It was agreed with Jolyon.

Besides, is ODPRIP really used until now ?
(for processing use case)

Discussion to have with Jolyon on how to implement processing API ?
→ organize tech. meeting on this topic

To make in a second step → put empty section (placeholder) in this version

STAC-PRIP-ITEM-REQ101 Bucket naming convention 3.3.3/page 26

Fixed

Depending on the chosen cloud provider the naming of prip-<mission>-<productType> is not possible for multiple service providers. E.g. on several CloudFerro data centers and OVHcloud the bucket names need to be unique throughout the data center or across all data centers. (see https://docs.cloudferro.com/en/latest/s3/How-to-use-Object-Storage-on-CloudFerro-Cloud.html, https://help.ovhcloud.com/csm/en-ie-public-cloud-storage-s3-limitations?id=kb_article_view&sysparm_article=KB0047379)
As such, it would not be possible to have to service providers in parallel at the same cloud provider. Even hand-over activities would not work without violation of this requirement. To reach uniqueness the service provider could be added to the naming convention.

To discuss during next STAC API Catchup (10 th February

Change : prip-<provider>-<mission>-<productType>

Corrections included in v1.1 (page 26)

§3.4.3.3

Fixed

Two curl examples in this section should use Accept: application/geo+json instead of Accept: application/json.  

response on page 33

Fixed

Example response contains two identical sections with http://www.opengis.net/def/rel/ogc/1.0/queryables.  
Remove one of both (e.g. the one with method=get"

STAC-PRIP-API-REQ-0340

Fixed

STAC-PRIP-API-REQ-0340 is defined two times for two distinct requirements

rename to STAC-PRIP-API-REQ-0345 – STAC compliance