| Id. | Author | Section/ Page number | Title | Status (Open/Fixed/Closed) | Initial Comment | Discussion | To update for PRIP |
|---|---|---|---|---|---|---|---|
| 1 | DLR | 1.2 | Relation of "Product" to STAC concepts | Fixed | The definition of the term "Product" should be extended to put it in relation to the STAC concepts catalog, collection, item and asset. | Changes made in 1.0-RC2 : definition extended | |
| 2 | DLR | 3.1 | Distinguish AIP and LTA | Fixed | The AIP consists of all (cloud-based) LTA service elements which are necessary to implement the LTA ICD. Behind this, the LTA may consist of other elements taking care of safe preservation. Since these are not relevant for the ICD, and not depicted/described here, this architecture should only refer to the AIP, not the full LTA. (see also Jolyons comment) This applies also to many requirement definitions in section 3, "LTA instance" → "AIP instance" | Changes made in 1.0-RC2 : diagram updated and LTA instance replaced |
|
| 3 | DLR | 3.2 / p.17 | Zarr content | Closed | The .zmetadata file is a non-standard extension to the Zarr v2 specification made by EOPF and might by subject to change when EOPF adopts Zarr v3. Whats the relevance of mentioning it in this ICD anyway? | OG: It's the same in PRIP ICD. I propose to keep it like this to ensure consistency JM: OK for me, we can wait for V3 implementation to be sure no change intended. Decision: to be updated this in a next version, according to migration to zarr v3 status | |
| 4 | DLR | 3.2 / p.17 | Download Zarr content | Closed | Since a EOPF Zarr store can contain thousands of files this would be very inefficient. Instead, an on-the-fly zipper approach should be considered. | JM: This will change with Zarr V3 and the sharding opportunities. I would tend to resist the on-the-fly zipper approach as an un-necessary complication (but still for discussion). Decision: to be reviewed later | |
| 5 | DLR | 3.2.1 | Table is incomplete | Open | The table does not contain all entities of the LTA Data Model, and some are named differently. | OG: Can you precise : missing entities : order, JobStatus ? | |
| 6 | DLR | 3.2.1 / p.18 | LTA Data Model figure | Open | This diagram is misleading. The data model of the LTA service is defined by the STAC Core model and the STAC extensions listed as applicable at the | OG: The diagram at the begining of the document is a general STAC diagram (with both parts API and Core). The Data model in page 17 details the structure of a AIP/LTA product in the meaning of STAC. | |
| 7 | DLR | 3.2.1 / p.18 | LTA Data Model | Fixed | What is meant with "production additional data"? Maybe provide an example here. | JM: Agreed with comment. Example added | |
| 8 | DLR | 3.2.4 | STAC-LTA-ITEM-REQ-0065 multiple simultaneous orders | Closed | The API seems not able to prevent simultaneous orders on the same product in the status "orderable". Which client would get notified on oder completion (see Fig. 2). | OG: The first order made against an offline product leads to a change of the "order:status" attribute (orderable --> ordered). We can imagine that a productOrder job first checks the value of this attribute and terminates in "failed" status if the attribute is not in the "orderable" value, with an explicit message. I could detail §3.5.1 to describe this mechanism. Decision: The implementation should manage concurrent orders for same product --> not to be defined in this ICD | |
| 9 | DLR | 3.2.4 | order status versus product status | Fixed | The Order STAC extension seems not adequate to describe the product online/offline status in the AIP. The "order:status" represents the status of an order linked to a product. There could also be multiple orders in parallel for the same product. Instead, consider
| OG: The previous mechanism prevents multiple orders for a same product. Besides, the "estimatedDate" property is not described in API Processes standard, and can be implemented by the "order:date" attribute Decision:
| |
| 10 | DLR | 3.2.3 / p.21 | Missing required attributes in the example | Fixed | The “items” and “queryables” attributes required in the STAC- LTA-COL-REQ-0030 requirement are not included in the example. | Changes made in 1.0-RC2: Example updated | |
| 11 | DLR | 3.2.4 / p.28 STAC-LTA-ITEM-REQ-0065 | Differing meaning of $.properties.order:date | Fixed | Meaning of $.properties.order:date differs from what´s defined in the table on page 24. Also, is $.properties.order:date relevant information for a user interested in a product or is it sufficient for a user to know if a product is online or offline? Note that the time when an offline item has been ordered is already part of the order itself. | OG: I propose to use this property to meet the "EstimatedDate" of the current ICD, even if it differs from the STAC order extension specification. Changes made in 1.0-RC2 : table p 24 updated |
|
| 12 | DLR | 3.2.4 | Uniqueness of $.id | Fixed | The STAC specification states: "The ID should be unique within the Collection that contains the Items". It follows that even if uniqueness within a collection is enforced (which is strongly recommended), it is not guaranteed across collections, which poses a problem when an order references a product, see comment to OGC-AIP-PRO-REQ-030. It should thus explicitly be stated in the LTA ICD that $.id MUST be unique across all collections and implementations MUST prevent the creation of STAC items with the same ID in mutliple collections. | Changes made in 1.0-RC2 : | done |
| 13 | DLR | 3.2.4 | Clarification of timestamps | Fixed | Please clarify the difference between $.properties.eopf:origin_datetime and $.properties.created from STAC Common Metadata. If there is no difference, should "created" be used instead of "eopf:origin_datetime"? The timestamps extension specifies "published", "expires" and "unpublished" properties. Please clarify the exact semantics of this properties in the context of the LTA service e.g.
In general, please define which and how timestamps should be set/updated when
| OG: to me, $.properties.created is the data for creation of the STAC item into AIP catalog, whereas $.properties.eopf:origin_datetime is the date of item availability on PRIP endpoint. $.properties.published has the same value as $.properties.created when the item is first added. Afterwards, it is used when the item is put online again after being offline Changes made in 1.0-RC2 : - add missing $.properties.created https://github.com/stac-extensions/timestamps/blob/main/examples/item.json | done |
| 14 | DLR | 3.2.4 | Clarification of $.properties.platform | Fixed | Please clarify how $.properties.platform relates to platformShortName and platformSerialIdentifier defined in the OData interface. This will have an impact on e.g. metrics. | Changes made in 1.0-RC2 : $.properties.platform is the concatenation of platformShortName and platformSerialIdentifier (eg: sentinel-1a) | done |
| 15 | DLR | 3.2.4 | STAC- LTA-ITEM-REQ-0070 STAC- LTA-ITEM-REQ-0087 | Closed | Should all assets be included in the STAC item or only the "product" asset (i.e. link to Zarr product, because all other assets can be determined by harnessing the Zarr layout)? What's the use case behind an archive service to provide individual or group of bands of the product as assets? Since the EOPF format specifies no assets at all, the assets to expose should be driven by the use case of the LTA clients. | OG: to discuss with ESA to see if specific use cases can occur for partial product downloading, in the context of LTA. JM: interesting point, use case could be on-demand creation of a data cube directly from AIP containing only the bands of interest. Current samples .zmetadata contain assets without hrefs ... to be investigated with EOPF team Decision: keep like this for now | |
| 16 | DLR | 3.2.4 | Some fields may be missing in STAC-LTA-ITEM-REQ-0090 | Fixed | Have the fields $.assets.<asset_name>.file:size and $.assets.<asset_name>.file:checksum been omitted deliberately ? | JM: good point Changes made in 1.0-RC2: add both properties in assets' properties table | done |
| 17 | DLR | 3.2.4 | Mission in bucket naming convention, see STAC-LTA-ITEM-REQ-0101 | Fixed | The requirement states that "mission" should be part of the bucket name. Where does the mission come from? It is not part of the required properties of an item as listed in STAC-LTA-ITEM-REQ-0050. Maybe use the collection id in the bucket name instead or include mission in the item from STAC Common Metadata. | OG: To decide with ESA JM: I also think it is unnecessary, could be removed. mission is probably in any case embedded in the productType Changes made in 1.0-RC2: add mission property in table, and remove "mission" from bucket name | done |
| 18 | DLR | 3.2.4 / p.30 | STAC- LTA-ITEM-REQ-0085 – Thumbnail asset | Closed | Are there any plans to include a thumbnail in the EOPF product? | OG: I don't think so. to see with ESA JM: Not planned | |
| 19 | DLR | 3.2.4 | Lifecycle as described in STAC-LTA-ITEM-REQ-0060 and STAC-LTA-ITEM-REQ-0065 | Fixed | Some remarks: 1. Setting "order:status" to "succeeded" seems incorrect if no order has been processed yet. 2. Shouldn't it be possible to create orders even in "shipping" and "succeeded" status? More generally, shouldn't it be allowed that different users create orders for the same product? This approach provides several benefits, e.g. users can cancel their orders without affecting other users, $.properties.expires may be updated if a new order is created to reflect the new user's expiration requirements, users may get individually notified upon order completion etc. Also see comment "order status versus product status". | OG: 1. setting of order:status removed for product creation/publication 2. I propose to restrict an retrieval order to 1 user for a same product (see comment #8). See how we can formalize this | |
| 20 | DLR | 3.2.4 | Lifecycle as described in STAC-LTA-ITEM-REQ-0060 and STAC-LTA-ITEM-REQ-0065 | Fixed | Please specify, how the assets href should be set for an Offline product. We see two possibilities:
| OG: I propose option 1, to avoid recalculation of href when a product is retrieved. Changes made in 1.0-RC2: | |
| 21 | DLR | 3.3.1.2 | STAC-AIP-API-REQ-0220 – Global access control semantics | Fixed | Is it really required for a client to be authenticated for the discovery operations (search and browse)? Usually, only retrieval and ordering are subject to authentication/authorization. | OG: That's what had been specified for PRIP. Maybe it's different for LTA ? Discussion to have with ESA JM: For the ESA LTA we want this, for a more generic definition of an LTA service the it is true, probably a open discovery is sensible, perhaps a different wording could indicate this. Changes made in 1.0-RC2: | |
| 22 | DLR | 3.3.1.3 | Quota Management | Fixed | Where are these quotas defined? Since the IAM is going to be centralized, are they also going to be defined there e.g. with OPA? | OG: Discussion to have with ESA Decided for PRIP :
Changes made in 1.0-RC2: add comment explaining that it will be described in another document (in STAC-AIP-API-REC-0335) | |
| 23 | DLR | 3.3.1.3 | Exceeded quotas | Fixed | It is not defined how a quota exceedance is communicated to the client. Information about when the quota is reset would be helpful for the client. In a HTTP based service, usually 429 Too Many Requests is used. We could propose it here. | Added the following recommendation p 34: STAC-AIP-API-RECO-0335 | done |
| 24 | DLR | 3.3.1.3 | Please clarify checksum feature in STAC-LTA-API-REQ-0305 | Fixed | 1. It is unclear what kind of checksum feature of the S3 infrastructure shall be leveraged. There are several options: | OG: is it in the scope of this ICD to detail how checksum is calculated ? A limitation for PRIP ICD had been raised by Cloudferro and the following had been decided : It's up to client's implementation and should be adressed by "tailored ICD" Discussion to have with ESA to arbitrate Proposition : the ICD could require that in case of multipart uploads, an adequate method shall be used to guarantee the reliability of an object checksum, without going into details on method/algorithm. JM: A good point, I'm not keen to leave this to a tailored ICD, I believe we need a solution here. Changes made in 1.0-RC2: STAC-LTA-API-REQ-0305 updated | done |
| 25 | DLR | 3.3.2 LTA Client requirements | Order completion notification missing | Closed | In Fig. 2 the client is supposed to offer a callback for order completion notifications, but there is no requirement defined for this. Should maybe be added in a separate LTA client requirements section within 3.5 "Product Retrieval". | The client is not required to provide a callback URL when submitting an order. See fig.3 and Fig.4 for both alternatives. I propose to close | |
| 26 | DLR | 3.3.3.3 | stac_extensions in STAC item | Closed | Does "stac_extensions" contain the same values for all STAC items? This may be important for implementations in order to prevent storing redundant information. | OG: I think it's the default behaviour of STAC implementation software (see https://stac.core.eopf.eodc.eu/collections/sentinel-2-l2a/items). Anyway, it's a matter of implementation, not specifications. I propose to close | |
| 27 | DLR | 3.3.3.3 | numberMatched in FeatureCollection | Closed | A FeatureCollections contains "numberMatched". We propose to state in the ICD that this may be an approximation and does not need to reflect the exact number of matched STAC items. Otherwise, query performance may be negatively affected. | OG: It depends if this information is used or not by client to know the current number of items meeting the input query. Again, it's a matter of implementation. JM: I think it maybe worth a note to the effect that it may be an approximation when result set is v large, but I don't know how to define v large. Decision: leave it that way (no requirement on numberMatched) | |
| 28 | DLR | 3.4 | OGC-AIP-API-REQ-030 / OGC-AIP-PRO-REQ-010 | Fixed | IDs are not named consistently, e.g. "productOrder" and "BulkCreate" and in OGC-AIP-PRO-REQ-060, it says "bulkCreate". We recommend consistent naming, e.g. "ProductOrder", "BulkOrder" and "BatchOrder". | Used formalism: camelCase e.g. "productOrder", "bulkOrder" and "batchOrder" | |
| 29 | DLR | 3.4 | Canceled status missing in OGC-AIP-API-REQ-060 and inconsistent status names | Open | Note that even if not allowed for a user to cancel an order, it should at least be allowed for an operator. Furthermore, can the status names of the OData interface be retained? Also note that the status names differ from the ones in OData and also $.properties.order:status, e.g. we have "completed" (OData), "succeeded" (STAC item), "successful" (OGC) or "in_progress" (OData), "shipping" (STAC item), "running" (OGC). This only contributes to confusion so we strongly advise to harmonize and abandon the STAC order extension. Why is the OGC Processing API used in the first place? What are the limitations of the currently used Order API? | OG: several topics here
JM: Cancel could indeed be supported ? Decision: to be discussed further and add in a next version | |
| 30 | DLR | 3.4 | OGC-AIP-PRO-REQ-030 | Closed | See also comment to $.id, otherwise "productId" is not guaranteed to be unique. Of course, a collection could be stored alongside "productId", but this is discouraged. | added STAC-LTA-ITEM-REQ-0055 (see comment #12) |
|
| 31 | DLR | 3.4 | OGC-AIP-PRO-REQ-040 | Fixed | In the example in section 3.5.1.3 (Example of process description) the spelling does neither reflect the spelling in this requirement nor is it consistent (e.g. "productLink" vs "EvictionDate"). It is strongly advised to be consistent in attribute naming. | Changes made in 1.0-RC2: attributes names have been harmonized (camelCase) |
|
| 32 | DLR | 3.4 | OGC-AIP-PRO-REQ-120 | Fixed | Please clarify what happens if some products could be ordered successfully and some products failed. | OG: Interesting question. We could propose that for a product whose retrieve fails, no URL is provided in "productLinks" job output for that product. I propose to discuss on this one. How does the current OData implementation manage this ? JM: I'm not sure either Changes made in 1.0-RC2: add "orderStatus" outputs to specify which products has failed/succeeded | |
| 33 | DLR | 3.5 Figures | AIP and LTA namings | Fixed | In order to make clear that AIP is part of the LTA, the LTA on the right could be named "LTA backend". | Changes made in 1.0-RC2: Diagrams updated | |
| 34 | DLR | 3.5.1 (and similar in 3.5.3) | Product access after order inconsistent | Fixed | The access to a product after successful order differs from the specification in section 3.3.1. It is especially unclear to which assets/files the "productLink" in the job result output would point to, since the orderable unit is always the full product. The "productLink" could better point to a STAC item to which the access can occur as defined in section 3.3.1. The "evictionDate" seems semantically the same as $.properties.expires of the corresponding STAC item. Please specify that after a successful order the expires attribute of the item must be updated accordingly. In this case it should also be considered to remove the "evictionDate" from the process output to avoid duplication of information. | OG: several topics:
JM: indeed productLinks would make sense to be STAC Items Changes made in 1.0-RC2: OGC-AIP-PRO-REQ-040 and OGC-AIP-PRO-REQ-110 updated | |
| 35 | DLR | 3.5.2.2 / p.55 | OGC-AIP-PRO-REQ-070 – Process inputs | Fixed | Suggest to also add collections and datetime as explicit parameters, like in STAC item search with simple filtering (https://api.stacspec.org/v1.0.0/item-search/#tag/Item-Search/operation/getItemSearch) | OG: to be discussed if we extract datetime and collection from within "filterParam" Add input params: collections, ids, datetime Changes made in 1.0-RC2: OGC-AIP-PRO-REQ-070 updated with additional inputs (collections, ids). datetime fileds kept in filterParam | |
| 36 | DLR | 3.6.1.2 / p.67 | OGC-AIP-PRO-REQ-150 – Process inputs | Closed | Align process inputs with OGC-AIP-PRO-REQ-070 | OG: please precise what you mean. The subscriptionCreate process must have specific inputs Decision: keep the inputs as specified | |
| 37 | ESA / JM | 3.2.4 / p 29 | STAC- LTA-ITEM-RECO-0085 | Closed | Not convinced that we will have thumbnails for the L0 data. | OG: it is a recommendation, not a requirement | |
| 38 | CAP | 3.4 / p 48 | OGC-AIP-API-REQ-080 | Open | Find a way for a client to provide authentication credentials in its callback URLs (not supported in API Processes standard) | OG: to be discussed | |
| 39 | DLR | 51 | OGC-AIP-PRO-REQ-030 – Process inputs | Open | When an order is created, the productOrder process would at first need to find the corresponding product in the STAC catalog e.g. to check its state (if its already online). To speed up this discovery we would suggest adding a collection parameter to the process inputs. Otherwise, the whole catalog needs to be searched. | ||
| 40 | DLR | 55 and 68 | OGC-AIP-PRO-REQ-070 – Process inputs
| Open | To be consistent with the STAC filter extension we would suggest to fully support cql2-json and cql2-text expressions directly as value of the filterParam instead of defining a custom filter language. This would allow clients to easily test and tune their filter expression against the STAC API before creating a bulk order or a subscription. |
| Open | 4 |
|---|---|
| Fixed | 23 |
| Closed | 11 |
| To be fixed |