From #185:
- 13 (Scenes) - Could the Scenes API just define relation types as used in Records or STAC and not define any new endpoints? This way you could just point to existing OAR and STAC endpoints and make the whole req. class much simpler.
There are multiple use cases for the Scenes requirement classes, which all fit nicely together:
- Being able to access a coverage both for individual scenes making up the coverage, as well as for the coverage as a whole. In particular, this is useful for a global data collection like LANDSAT with individual granules in UTM projections whereas you also want to offer a global collection in EPSG:4326.
- Offering metadata for individual scenes making up the coverage (which could be negotiated in a STAC item representation)
- Using that metadata as part of global Coverage queryables for Part 2 filter extension, with scene-level queryables (in addition to cell-level queryables) e.g.,
/collections/{collectionId}/coverage?filter=scene.cloudCover<30 and scl <> 9 to filter out cloudy scenes completely, then filter out high-probability cloudy cells, all directly within single one-step coverage request.
- Discovery of individual scenes using OGC API - Records (
q=, CQL2 filter=, bbox=, datetime=...)
- Creating/Updating/Reading/Deleting individual scenes (like Testbed-15 Images API) which automatically updates the whole coverage by adding/changing/removing new images.
You could implement both the Scenes requirement class at /collections/{coverageId}/scenes AND a STAC API at /collections/{stacCatalogID}/items. I personally really do not like the latter pattern, and I would never implement it, because it mixes up data and metadata in a way which I find truly awful.
The Scene requirement class re-uses the same query parameters as Records (many of which shared with the STAC API) and works together with the STAC item / collection media type for the list of scenes at /collections/{coverageId}/scenes and individual scenes at /collections/{coverageId}/scenes/{sceneId}, but it's nicely nested inside a particular coverage/collection/geodatacube, avoiding any of that data / metadata mixup.
13 (Scenes) - Do I understand correctly that the scenes endpoint should return responses compliant either to OAR or STAC?
The OGC API - Coverages "Scenes" requirement class integrates with STAC and Records in two ways:
- The OGC API - Records
Local Resource Catalog deployment type can be used in conjuncton with the Scenes requirement class, as the basis of the scene records data model, and for the Filtering/Searching/Sorting parameters. This should be mostly in sync with the STAC API except for the different resource path.
- A STAC collection/catalog (still confused about the distinction between those 2) can be used as a representation of a scenes listing / query at
/collections/{coverageId}/scenes and a STAC item can be used as a representation of the scene metadata for an individual scene at /collections/{coverageId}/scenes/{sceneId}.
From #185:
There are multiple use cases for the Scenes requirement classes, which all fit nicely together:
/collections/{collectionId}/coverage?filter=scene.cloudCover<30 and scl <> 9to filter out cloudy scenes completely, then filter out high-probability cloudy cells, all directly within single one-step coverage request.q=, CQL2filter=,bbox=,datetime=...)You could implement both the Scenes requirement class at
/collections/{coverageId}/scenesAND a STAC API at/collections/{stacCatalogID}/items. I personally really do not like the latter pattern, and I would never implement it, because it mixes up data and metadata in a way which I find truly awful.The Scene requirement class re-uses the same query parameters as Records (many of which shared with the STAC API) and works together with the STAC item / collection media type for the list of scenes at
/collections/{coverageId}/scenesand individual scenes at/collections/{coverageId}/scenes/{sceneId}, but it's nicely nested inside a particular coverage/collection/geodatacube, avoiding any of that data / metadata mixup.The OGC API - Coverages "Scenes" requirement class integrates with STAC and Records in two ways:
Local Resource Catalogdeployment type can be used in conjuncton with the Scenes requirement class, as the basis of the scene records data model, and for the Filtering/Searching/Sorting parameters. This should be mostly in sync with the STAC API except for the different resource path./collections/{coverageId}/scenesand a STAC item can be used as a representation of the scene metadata for an individual scene at/collections/{coverageId}/scenes/{sceneId}.