You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+11-2
Original file line number
Diff line number
Diff line change
@@ -6,20 +6,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
6
6
7
7
## Unreleased / Draft
8
8
9
+
### Added
10
+
11
+
-**New extensions:**
12
+
-[Remote Process Definition Extension](./extensions/remote-process-definition/README.md)
13
+
- Added `version` property to `GET /processes`[#517](https://github.com/Open-EO/openeo-api/issues/517)
14
+
9
15
### Fixed
10
16
11
17
-`GET /file_formats`: Base paramater on top of normal JSON Schema, not Process JSON Schema
12
18
-`PATCH /services/{service_id}` and `PATCH /jobs/{job_id}`: Explicitly allow updating back-end specific properties (as in `POST`)
13
19
-`GET /services/{service_id}` and `GET /jobs/{job_id}`: Explicitly allow listing back-end specific properties (as provided in `POST`)
14
20
-`GET /jobs/{job_id}/results`: Clarify that signed URLs (used as "canonical" link) should be regenerated each time.
21
+
- Clarified for log levels which default values apply
22
+
- Clarified how the relation types `license`, `version-history` and `author` can be used to enrich the process metadata. [#531](https://github.com/Open-EO/openeo-api/issues/531)
23
+
- Clarified the behaviour of `federation:backends` for `POST /validation`
15
24
16
25
## [1.2.0] - 2021-05-25
17
26
18
27
### Added
19
28
20
29
-**New extensions:**
21
-
-[Commercial Data Extension](./extensions/commercial-data/README.md)
|[Commercial Data](extensions/commercial-data/)| 0.1.0 | experimental | Provides an interface for discovering, ordering and using commercial data. |
35
+
|[Federation](extensions/federation/)| 0.1.0 | experimental | Covers federation aspects, i.e. where multiple back-ends are exposed as a single API. |
36
+
|[Remote Process Definition](extensions/remote-process-definition/)| 0.1.0 | experimental | Load user-defined processes that are hosted externally through the process namespace into process graphs. |
36
37
37
38
## Repository
38
39
@@ -43,7 +44,7 @@ This repository contains a set of files formally describing the openEO API, each
43
44
* The [assets](assets/) folder contains some useful additional files such as examples or schemas. All of these are non-binding additions. The source of truth are the top-level specification files.
44
45
* The [extensions](extensions/) folder contains extensions to the openEO API.
45
46
46
-
# Development
47
+
##Development
47
48
48
49
The `draft` branch is the latest version and is the one to create Pull Requests against.
Copy file name to clipboardExpand all lines: extensions/commercial-data/README.md
+9-8
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Commercial Data Extension
2
2
3
-
The Commercial Data API extension provides an interface for discovering, ordering and using commercial data in the openEO API.
3
+
The Commercial Data Extension to the openEO API provides an interface for discovering, ordering and using commercial data in openEO.
4
4
5
5
- Version: **0.1.0**
6
6
- Stability: **experimental**
@@ -12,7 +12,7 @@ Extensions can not change or break existing behavior of the openEO API.
12
12
13
13
## Overview of the workflow
14
14
15
-
All the available datasets provided by a backend are listed on the `GET /collections` endpoint. The collections are normally freely accessible. This extension adds capabilities for providing collections that are not free of charge and require purchasing data products that can thereupon be used in processing. Commercial data collections usually allow purchasing small subsets of the data (products), for example, a single observation of an area.
15
+
All the available datasets provided by a back-end are listed on the `GET /collections` endpoint. The collections are normally freely accessible. This extension adds capabilities for providing collections that are not free of charge and require purchasing data products that can thereupon be used in processing. Commercial data collections usually allow purchasing small subsets of the data (products), for example, a single observation of an area.
16
16
17
17
Therefore, the client must have an ability to search the available products that match their desired criteria and inspect their metadata to decide whether the products should be purchased.
18
18
@@ -22,7 +22,7 @@ When the order is completed, the data is ingested in a collection and its ID is
22
22
23
23
### Collection discovery
24
24
25
-
A backend should add general information about a commercial data collection to the `/collections` and `/collections/{collection_id}` endpoints, the same as with freely available collections. Only the metadata about the entire dataset needs to be provided, not about the specific data products that a user has already purchased.
25
+
A back-end should add general information about a commercial data collection to the `/collections` and `/collections/{collection_id}` endpoints, the same as with freely available collections. Only the metadata about the entire dataset needs to be provided, not about the specific data products that a user has already purchased.
26
26
27
27
Commercial data collections are distinguished from freely available collections by including `"order:status": "orderable"` as specified in the [STAC Order extension](https://github.com/stac-extensions/order/tree/v1.0.0).
28
28
@@ -82,7 +82,7 @@ Commercial data collections must also include human-readable pricing information
82
82
83
83
### Filtering parameters discovery
84
84
85
-
Searching for products can support refining the search by filtering with general or collection-specific attributes. Backends should implement a top level `/queryables` endpoint for attributes available for all collections, and collection-specific attributes should be provided at `/collections/{collection_id}/queryables` according to [OGC Queryables specification](https://portal.ogc.org/files/96288#filter-queryables) and [STAC Filter extension](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/fragments/filter).
85
+
Searching for products can support refining the search by filtering with general or collection-specific attributes. Back-ends should implement a top level `/queryables` endpoint for attributes available for all collections, and collection-specific attributes should be provided at `/collections/{collection_id}/queryables` according to [OGC Queryables specification](https://portal.ogc.org/files/96288#filter-queryables) and [STAC Filter extension](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/fragments/filter).
86
86
87
87
#### Example
88
88
@@ -125,7 +125,7 @@ Example response from `GET /collections/PLEIADES/queryables`:
125
125
126
126
### Searching available products
127
127
128
-
Backends should implement the top-level `GET /search` endpoint as specified in the [STAC Item Search API specification](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/item-search). This should include the [Filter Extension](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/fragments/filter), which enables filtering the available products by attributes specified in `GET /queryables` and `GET /collections/{collection-id}/queryables`.
128
+
Back-ends should implement the top-level `GET /search` endpoint as specified in the [STAC Item Search API specification](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/item-search). This should include the [Filter Extension](https://github.com/radiantearth/stac-api-spec/tree/v1.0.0-rc.1/fragments/filter), which enables filtering the available products by attributes specified in `GET /queryables` and `GET /collections/{collection-id}/queryables`.
129
129
The endpoint returns a list of [STAC Items](https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md) that match the criteria. The products should be aligned with the STAC specification, utilising the existing [STAC extensions](https://github.com/radiantearth/stac-spec/blob/v1.0.0/extensions/README.md) as much as possible, and trying avoiding custom attributes, if a generally accepted definition does not exist.
130
130
131
131
#### Example
@@ -155,29 +155,30 @@ Example request payload to `GET /search` for `PLEIADES` products from "Living Li
155
155
156
156
### Ordering products
157
157
158
-
Backends must implement the following endpoints:
158
+
Back-ends must implement the following endpoints:
159
159
160
160
-`GET /orders`: Get a list of all created orders
161
161
-`POST /orders`: Create an order
162
162
-`GET /orders/{order_id}`: Get full metadata of a specific order
163
163
-`POST /orders/{order_id}`: Confirm a created order
164
164
165
165
Optionally, they can also implement:
166
+
166
167
-`DELETE /orders/{order_id}`: Delete an order
167
168
168
169
See the [OpenAPI document](openapi.yaml) for details.
169
170
170
171
### Product metadata
171
172
172
-
The backend can provide full product metadata as STAC Items following [STAC API Features specification](https://github.com/radiantearth/stac-api-spec/tree/main/ogcapi-features). This requires implementing two additional endpoints, `/collections/{collection_id}/items` and `/collections/{collection_id}/items/{item_id}`.
173
+
The back-end can provide full product metadata as STAC Items following [STAC API Features specification](https://github.com/radiantearth/stac-api-spec/tree/main/ogcapi-features). This requires implementing two additional endpoints, `/collections/{collection_id}/items` and `/collections/{collection_id}/items/{item_id}`.
173
174
174
175
`/collections/{collection_id}/items/{item_id}` may return an error if the data has not been ingested yet.
175
176
176
177
Items should contain links to the respective orders that made them available using relation type `parent_order`.
177
178
178
179
### Payment
179
180
180
-
Payment should be done in the currency used by the backend, listed at `GET /` under `billing`. When an order is created, the backend should return the full final cost of the order.
181
+
Payment should be done in the currency used by the back-end, listed at `GET /` under `billing`. When an order is created, the back-end should return the full final cost of the order.
The order can contain additional parameters that specify how the items should be delivered.
88
88
For example, it might be possible to set the projection, resampling method, bit depth etc. of the delivered data.
89
89
90
-
Backends SHOULD expose the available ordering parameters in `GET /collections/{collection_id}` in the `order_parameters` field, following the `process_parameters` schema of [`GET /service_types`](https://openeo.org/documentation/1.0/developers/api/reference.html#tag/Secondary-Services/operation/list-service-types).
90
+
Back-ends SHOULD expose the available ordering parameters in `GET /collections/{collection_id}` in the `order_parameters` field, following the `process_parameters` schema of [`GET /service_types`](https://openeo.org/documentation/1.0/developers/api/reference.html#tag/Secondary-Services/operation/list-service-types).
91
91
92
92
Returns `Location` and `OpenEO-Identifier` header with the link to the detailed information about the order.
93
93
tags:
@@ -148,7 +148,7 @@ paths:
148
148
description: |-
149
149
Get full metadata of the order.
150
150
151
-
Backends can optionally link to the spatial and temporal extent information and other metadata about the items using the relation type `item`, preferrably by implementing and linking to `GET /collections/{collection_id}/items/{item_id}`.
151
+
Back-ends can optionally link to the spatial and temporal extent information and other metadata about the items using the relation type `item`, preferrably by implementing and linking to `GET /collections/{collection_id}/items/{item_id}`.
152
152
tags:
153
153
- Orders
154
154
security:
@@ -176,7 +176,7 @@ paths:
176
176
177
177
When an order is created through `POST /order`, the data isn't yet ordered from the commercial data provider. The client MUST explicitly confirm the order whereupon the order is executed, the costs are deducted from the client's account and the data is ingested in the target collection.
178
178
179
-
The target collection is the collection through which the ordered data is made available. The source and the target collection can be the same or different, it's up to the backend if the ordered data id ingested into a new target collection or the existing source collection. Additionally, if the backend creates new target collections, it can provide access to the union of all purchased products through the source collection.
179
+
The target collection is the collection through which the ordered data is made available. The source and the target collection can be the same or different, it's up to the back-end if the ordered data id ingested into a new target collection or the existing source collection. Additionally, if the back-end creates new target collections, it can provide access to the union of all purchased products through the source collection.
180
180
181
181
This endpoint only has an effect if `order:status` is `orderable`.
0 commit comments