-
Notifications
You must be signed in to change notification settings - Fork 12
OpenSearch support for data discovery #68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I removed OpenSearch from the API spec for now. It is not useful as of now and it's unclear whether we support it or at which endpoint it is implemented. What has been removed:
|
I removed process discovery as I don't think OpenSearch makes sense in this context and make things more complex than they need to be. |
I just removed (see 9091559) the query parameters for the data discovery endpoint as they most likely will be changed later in favor of either a standard-specific version of the body contents (e.g. STAC) or OpenSearch. |
I just had a brief look into the most recent version of OGC OpenSearch EO, incl. the new JSON encoding. I found it very hard to really get into it due to its massive length. Some comments follow... Most interesting is probably the search functionality:
Regarding the JSON response format:
Preliminary conclusion: Too complex for us. Would skip it for now and just take the easier things we inherit from using STAC. |
Now that we incorporate STAC and WFS into the data discovery, it's time to make a short wrap-up regarding OpenSearch in openEO. I already listed some information in my previous comments and there were some related discussions also in a STAC issue (radiantearth/stac-spec#16). In the end, OpenSearch is very complex, it's like a 300 pages that are exceeding the current documentation of the whole openEO project, a better start is probably the CEOS OpenSearch best practice document. OpenSearch enforces a different JSON encoding for the responses, which is not compatible with STAC. So that's something that could not really be incorporated into our existing endpoints. I see it more to be put on top as a separate endpoint/extension, but I don't currently see in the core. It may be added to STAC or WFS as extension, but not even WFS as a OGC standard has included their own OGC OpenSearch extension, so I don't really see a point why we should push it into the core. Maybe we could work that out as an openEO API extension by interested parties/partners. |
As discussed in #103, we won't go for OpenSearch support at the moment. We may reconsider it in the future. |
Currently, we have a place holder for OpenSearch support in the API for data (and process) discovery. It bases on OpenSearch 1.0 and doesn't really fit into our API as it is XML based and not JSON as everything else.
It seems that OGC is working on a new JSON based draft as I could read here:
That sounds pretty interesting. They are overdue(?), but maybe we can just wait for the release and incorporate this version in favor of the XML-based version.
Can't really find further information, but there is a presentation from a CEOS meeting regarding the EO OpenSearch GeoJSON Encoding. There are some interesting information included, which we should look at, e.g. regarding on how to format the acquisition information that were proposed also in #64 for the general data discovery endpoint.
The text was updated successfully, but these errors were encountered: