OGC Scenes API "competing" with STAC?

[m-mohr]

OGC seems to be creating a somewhat similar specification to STAC, the Scenes API.

I think we should check and discuss this, and if required, try to push them towards STAC. I'm not sure why they don't just use STAC?!

See: opengeospatial/ogcapi-coverages#171 and https://github.com/opengeospatial/ogcapi-coverages/files/12491708/19-087.pdf, chapter 13.

Has anyone thoughts or more details?

cc @cholmes

[jerstlouis]

@m-mohr The aim is not to compete with STAC but to integrate the STAC properties applying the OGC API - Records Local Resource Catalogs concept on "scene" resources within a specific collection (/collections/{collectionId}/scenes). This avoids the need for mixing a "metadata"-only collection that sits at the same level as a "data" collection in the same API end-point.

It is also to be able to provide access to the data at both an overall "collection" level comprised of multiple scenes (e.g., /collections/sentinel2-l2a/coverage), and for a single scene /collections/sentinel2-l2a/scenes/{sceneId}/coverage).

It also allows the use of record properties as queryables directly as part of a coverage request for the overall collection, so that a client does not need to first query scene metadata, then perform request on individual scenes -- it can do it all directly as part of a GET request on the overall /collections/sentinel2-l2/coverage resource e.g., ?filter=scene.cloudCover < 30.

The other aspect of the scene API is for being able to create / update / delete scenes that automatically updates the overall coverage (as per the Images API from OGC Testbed 15).

It would also be possible to include a link from the same collection providing a /collection/{collectionId}/scenes link to also link to a STAC API /items end-point. To what extent these could be one and the same I think is related to the Records / STAC harmonization and the ability to apply the Local Resource Catalog to endpoints other than /collections/{collectionId}/items (/collections/{collectionId}/scenes in this case, but also for example /processes).

[pvretano]

I'm not sure if this helps resolve this particular issue or not but I should point out that the Local Resources Catalogue conformance class can be applied to any OGC API endpoint where catalogue-like queries make sense. /collections/{collectionId}/scenes is one example of such an endpoint. collections and /processes are other endpoint examples.