OpenSearch here too limited

[uvoges]

The OpenSearch endpoint is not able to allow detailed searches (as done e.g. by machineclients in hostedProcessing environments) which is especially important when searching within huge amount of very similar data. Those dataset cadn only be distinguished by specific Parameters: Area of interest, Time of interest, Sensor, cloudCover, acquisitionDate.... The single search param cannot provide this.
I suggest to consider OGC 13-026r9 (and its related JSON encodings OGC 17-047 and 17-003) with two endpoints:
/openSearch/osdd providing the OSDD
/openSearch/search providing the search URL

[m-mohr]

Thanks for contributing by opening this issue. This issue is very much covered by #68, but it's a good time to give a short overview on the plans on OpenSearch within openEO.

tl;dr: The current implementation in v0.0.2 was a placeholder and was removed for now as it was too limited, but we are interested in OpenSearch and are still trying to figure out how to integrate it without increasing the implementation effort for our back-ends by a big chunk.

You were probably reading openEO API v0.0.2, which is about to be replaced by a new version 0.3 in some days (see #116). The first versions (including v0.0.2) had a placeholder for an OpenSearch endpoint as there were thoughts to include it, but it never got much attention or enough thoughts how it could be incorporated. I took over the specification part at some points and also realized that OpenSearch in this shape was not useful and too limited. We have the same opinion here. Therefore, I removed that endpoint from the current version as it was not useful at all at this stage and we planned to integrate STAC for our data discovery. STAC itself is compatible with OGC WFS3. Both are not (yet?) supporting OpenSearch at all, but I hope that at least WFS may get an OpenSearch extension that we can simply use. Otherwise, I'd personally make OpenSearch an extension to openEO due to its complexity. The documentation is very lengthy compared to the openEO documentation. Having it as an extension is just logical here as the OpenSearch endpoints are actually separate and have a different JSON schema than our collection descriptions, so they can easily be added on top. There are also some implementation issues based on our data cube based approach that need to be tackled and more time and thoughts. For example, how would we integrate a cloud cover filter? On granules that's probably an easy task, but we still need to figure out how the different architectures can incorporate that for data cubes. We'll figure that out at some point, but the project is still in an early stage and it needs more time, thoughts and maybe also some help to get into the extensive OpenSearch spec. I'd appreciate that.

[m-mohr]

Will be tackled with #68.