Document Review

Mis-alignment with the "searchable identifiers" recommendations here: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md. Perhaps the recommendation should be that the naming follows GCMD but best practice for the case sensitivity is that of STAC.  (Open for discussion) → ok fixed to lowercase

I suggest though that any updated version simplifies the list to sentinel-1[a,b,c,d] and likewise for sentinel-2 and 3, also provides ellipsis ... since the requirement should be generic for the expansion missions and others.

STAC-CORE-COL-REC-0120

STAC-CORE-ITEM-REQ-0180

STAC-CORE-ITEM-REC-0190

Closed

The semantics of the "created" and "published" properties may differ between the EOF services. This should be reflected in the individual EOF Service ICDs.

→ Yes noted.

Fixed

There is a difference between data not being valid and not being available any more. Maybe differentiate this by also using the "unpublished" property from the Timestamps extension.

→ ok, updated the requirement as followed:

STAC-CORE-ITEM-REC-0190 – Additional timestamp information [Recommendation]

EOF Service STAC implementations should encode any Item with the following properties, when relevant:

• "created" Timestamp of the Item metadata creation, if different from the "published" property (specified by [STAC_ITEM_SPEC]),
• "expires" Timestamp when the Item will no longer be available in the Catalog (specified by [STAC_TIMESTAMP_EXTENSION]).

"unpublished" Timestamp when the Item was unpublished (specified by [STAC_TIMESTAMP_EXTENSION]).

Closed

The default fields may differ between the various EOF Services and should be defined in the service-level ICDs.

→ Yes, it has to be specified at Service level ICD.

STAC-API-ADVSRCH-CREQ-0640

STAC-API-ADVSRCH-CREQ-0650

Closed

Maybe consider to allow an EOF Service to tailor this behavior e.g. to optimize query performance.

→ question submitted to the working group.

• ✓ A link for the file info extension is missing → link added  
• ✓ STAC-...-0020: All values should be lowercase as per STAC spec recommendation → ok fixed to lowercase
• ✓ STAC-...-0060: "role": "metadata" is invalid STAC → ok fixed
• ✓ STAC-...-0130: Two options are given but not detailed enough to decide which to use when. → keep only the via option
• STAC-...-0160: It's unclear why start and end_datetime need to be provided as duplicate values. → Discussed during STAC catchup → ok to keep this requirement as is
• ✓ STAC-...-0290/0300/0310: This seems a bit ambiguous and confusing. Maybe linking to the newly added best practice (in STAC 1.1) around thumbnails and overviews may help. → ok replace requirements by recommendation from STAC 1.1 best practices 
• ✓ STAC-...-0340/0350: "role"="data" is invalid STAC → ok fixed
• STAC-...-0370: The extension is not stable at all and is likely to change drastically, a requirement seems not be a good idea at this point. → see comment
• ✓ STAC-...-0440: A secret is not required in a web-browser based OIDC flow (not sure whether that's a usecase). → see comment
• If the OGC API - Features conformance classes get implemented, you can't exclude the conformance and service-desc relation types → see comment
• ✓ STAC-...-0590: The selection of JSON Schema properties is a little random?! → see comment

Jan Musial

(CloudFerro)

Jan Musial

(CloudFerro)

Closed

e.g. MMM_MSIXXX_YYYYMMDDHHMMSS_Nxxyy_ROOO_Txxxxx_<Product Discriminator>.SAFE

see: https://sentinels.copernicus.eu/en/web/sentinel/user-guides/sentinel-2-msi/naming-convention

Jan Musial

(CloudFerro)

Fixed

✓ not clear if the extension would be adjusted to meet CDSE requirements

to clarify how information provided by storage extension will be provided in CDSE implementation. See also comment to #7

 → reference to storage extension removed

Jan Musial

(CloudFerro)

Fixed

Added a recommendation to highlght the need to properly defined this parameter, considering a trade-off between client needs and technical constraints

STAC-API-SIMPSRCH-REC-0521 – Maximum page size [Recommendation]

EOF Service STAC implementation should carefully define the maximum number of items that could be returned, considering a trade-off between STAC Client needs and technical/performance constraints.

Jan Musial

(CloudFerro)

Fixed

Not clear in the querable geometry can be a multipolygon?

Added following requirement:

STAC-API- ADVSRCH-CREQ-0571 – Limiting the number of vertexes in spatial query [Conditional Requirement]

When a geometry search criterion is provided and exceeds the maximum number of vertexes supported by the EOF Service STAC implementations, a 413 HTTP status code (Request Entity Too large) shall be returned including an error content including a clear explanation of the issue.  

Jan Musial

(CloudFerro)

Jan Musial

(CloudFerro)

Jan Musial

(CloudFerro)

Jan Musial

(CloudFerro)

STAC-CORE-GEN-REQ-0040

STAC-CORE-COL-REC-0135

These statements have conflicting identifier and type (requirements with REC or recommendations with REQ)

2 references renamed 

STAC-API-GEN-REQ-0411

The type "[Requirement]" shall be added in the title, like other requirements in the document

Title fixed

STAC-API-SIMPSRCH-REQ-0530

All STAC-API-ADVSRCH-CREQ-*

Some extra characters are present in these requirement identifiers, it causes issues with traceability tools.

Extra spaces deleted

STAC-CORE-COL-REC-0110

Wrong spelling of Recommendation ('a' instead of 'e')