47
This page aims to collect the comments on the Document "STAC Requirements and Recommendations for EOF Services", downloadable from this link;
RC 1 : CAP-TN-030-BE_STAC_Requirements_and_recommendations_for_EOF_services-1.0-RC1.pdf
RC 2 : CAP-TN-030-BE_STAC_Requirements_and_recommendations_for_EOF_services-1.0-RC2.pdf
Note: Comments from Yves Coene are available in this file: CAP-TN-030-BE_STAC_Requirements_and_recommendations_for_EOF_services-1.0-RC1-yc-v2-car.pdf
This document provides a set of common requirements and recommendations to be applicable by any EOF Service that will adopt STAC as the main API specification for the discovery and downloading of their products.
Each EOF Service will complete those common requirements by its own service-level ICD to address its specificities.
Please, add your comments to the following table:
...
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]
...
- "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]
...
Jan Musial
(CloudFerro)
...
Fixed
Not clear in the querable geometry can be a multipolygon?
...
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)
...
This content has moved to Document Review in STAC Shared Resources space.