...
| Id. | Author | Section/Page number | Title | Status (Open / Fixed / Closed) | Comment |
|---|---|---|---|---|---|
| 1 | JM | STAC-CORE-GEN-REC-0020 | Use of mixed case in e.g. platform values | Closed | 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. |
| 2 | Mario Winkler (DLR) | STAC-CORE-COL-REC-0110 | Collection Identifier | Fixed | The specific collection names for each EOF Service should be defined in the corresponding EOF Service ICDs since the set of collections is known in advance. → this will be done in the specific ICD related to each individual EOF Service |
| 3 | Mario Winkler (DLR) | STAC-CORE-COL-REC-0120 STAC-CORE-ITEM-REQ-0180 STAC-CORE-ITEM-REC-0190 | Semantics of "created" and "published" | 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. |
| 4 | Mario Winkler (DLR) | STAC-CORE-ITEM-REC-0190 | Additional timestamp information | 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]
"unpublished" Timestamp when the Item was unpublished (specified by [STAC_TIMESTAMP_EXTENSION]). |
| 5 | Mario Winkler (DLR) | STAC-API-ADVSRCH-CREQ-0630 | Set of fields returned by default | 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. |
| 6 | Mario Winkler (DLR) | STAC-API-ADVSRCH-CREQ-0640 STAC-API-ADVSRCH-CREQ-0650 | Empty or no "fields" directive | Closed | Maybe consider to allow an EOF Service to tailor this behavior e.g. to optimize query performance. → question submitted to the working group. |
| 7 | Matthias Mohr | various | Fixed |
| |
| 8 | Jan Musial (CloudFerro) | page 4 | outdated STAC version | Fixed | STAC has been already released in version 1.1 beta (official release planned next week) so it would be beneficial to start with the most recent version instead of creating a technological backlog from the very beginning. Furthermore, the CDSE is implemented in v1.1. so PIRP in v 1.0 would not compatible. ✓ The extensions versions should also match the ones used in the CDSE. → OK, Document is now aligned with STAC 1.1 |
| Closed |
| |||
| 10 | Jan Musial (CloudFerro) | STAC-CORE -ASSET-REQ-0370 | STAC storage extension is outdated and temporarily removed from CDSE STAC | 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 |
| 11 | Jan Musial (CloudFerro) | STAC-API-SIMPSRCH-REQ-0520 | maximum allowed items per page not defined | 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]
|
| 12 | Jan Musial (CloudFerro) | STAC-API- ADVSRCH-CREQ-0570 | maximum number of vertexes in querable geometry not defined. | 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. |
| 13 | Jan Musial (CloudFerro) | general comment | lack of specific list of required & recommended STAC extension with corresponding versions | Closed | It has to be specified in service level ICD. |
| 13 | Jan Musial (CloudFerro) | general comment | lack of specific list of required STAC extension with corresponding versions | Closed | duplicate from previous |
| 14 | Jan Musial (CloudFerro) | general comment | no relation to INSPIRE specification. It was agreed that the STAC should be INSPIRE compliant at collection level | Closed | As discussed in catchup meeting, no additional requirement expected. |
| |||||
| 16 | Vincent Privat (ADS) | STAC-CORE-GEN-REQ-0040 STAC-CORE-COL-REC-0135 | Mispelled identifiers (REQ vs. REC) | Fixed | These statements have conflicting identifier and type (requirements with REC or recommendations with REQ) 2 references renamed |
| 17 | Vincent Privat (ADS) | STAC-API-GEN-REQ-0411 | Type (requirement) forgotten | Fixed | The type "[Requirement]" shall be added in the title, like other requirements in the document Title fixed |
| 18 | Vincent Privat (ADS) | STAC-API-SIMPSRCH-REQ-0530 All STAC-API-ADVSRCH-CREQ-* | Extra space characters in requirement identifiers | Open | Some extra characters are present in these requirement identifiers, it causes issues with traceability tools. |
| 19 | Vincent Privat (ADS) | STAC-CORE-COL-REC-0110 | Typo | Open | Wrong spelling of Recommendation ('a' instead of 'e') |