Searching for collections as defined in OGC API and OGC API Records ...

[pvretano]

I present this material to explain how queries of a sub-set of collections is defined in OGC API Common and OGC API Records and start a harmonization dialogue between OGC API and STAC.

OGC API Common defines the bbox, datetime and limit parameter at the /collections endpoint so that you can search the list of available collections using a query like:

GET /collections?bbox=-69.64,37.76,-56.12,46.63&datetime=2020-01-11T00:00:00/2020-01-12T00:00:00

OGC API Records extends this capability by ...

1. Addiing additional properties to the collection object to enhance its information content beyond what is define in Common and Features
2. Allowing implementation to extend the endpoint by adding additional parameters like q (for keyword search) or filter/filter-lang/filter-crs (for using CQL2) or sortBy (for sorting), etc.

This allows for queries like:

GET /collections?q=seabed&bbox=-69.64,37.76,-56.12,46.63

which would respond with all collections that contain the keyword seabed in the specific bounding box. The response is example like that from GET /collections but only those collection objects that satisfy the specified predicates are included in the result set.

In OGC API Records this is called a "local resources catalogue" and the capability allows you to query OGC resource endpoints as if they where mini-catalogues. Other examples of such an endpoints include the /processes endpoint that offer lists of available processes and the /collections/{coverageId}/scenes endpoint that offers a list of scenes used to construct a mosaiced coverage. In each case the response is that same as doing a GET at the endpoint (i.e. GET /processes, GET /collections/{coverageId}/scenes) but only those object instances that satisfy the query predicates are included in the response.

[m-mohr]

I think that's exactly what we are looking for. So you do that only for GET /collections, right? Do you allow POST for larger geometries for examples?

[pvretano]

@m-mohr no. POST behaviour is not defined at the /collections endpoint (for example) but some servers like ours use it to create new collections (i.e. POST /collecttions with a body that contains metadata about the new collection to be created). I suppose the MIME type could be used by a server to distinguish a POST that is a query and contains a query expression and a POST that is a "create new collection" with a body that contains collection metadata.

[m-mohr]

Thank you, appreciated!

So OGC API is using GET /collections only, no POST for larger payloads.

So if we want to inherit from them, we need to do GET /collections and the POST equivalent for searching would be an issue that we need to solve in STAC ourselves, e.g. via content negotiation.

This also means you re-use the "data" relation type and you can use conformance classes to detect whether it supports additional queries etc.

I'll try to align this with the OGC APIs tomorrow and update the Readme. @jmigueldelgado could update the OpenAPI then? Maybe we can also just take OpenAPI parts from OGC...

[m-mohr]

I think the basic alignment is done, closing in favor of more specific issues.