You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
STAC catalogs form a graph (not acyclic!) of catalogs and items and assets.
This complex structure does not map naturally to WCS endpoint.
In this use case we limit the possible acceptable structure of STAC catalog such that this mapping exists and we can have "low friction" publishing of STAC catalog through WCS endpoint.
Configuration file for WSC service points to a single STAC catalog or collection Note: "every Collection is also a valid Catalog"
WCS endpoint can/will crawl and cache the full catalog at startup
Each STAC item will correspond to single WCS Coverage
GetCapabilities for STAC Item
For each item in catalog WCS GetCapabilities request includes a CoverageSummary which uses STAC item id as its own identification. STAC item ids are expected to be globally unique, we're using that feature here.
CoverageSummary shall include metadata element with items for:
Every element in STAC links section using their values xlink:href in xml elemet.
self, root, collection (if present)
STACT asset named meatadata with xlink:href (if present)
Every field in STAC item properties list. For example Landsat 8 STAC item may have:
Each STAC item may has a list of assets some of which may be a raster file that could be served through WCS. STAC does not restrict what can be an asset.
For purpose of this feature:
assets that have type=: image/tiff will be included
configuration will provide a list of assets to be included per item (ex: B1, B2, etc. for LC8)
Available assets will be encoded as bands through wcs:Range element per coverage.
If range is not specified per during request time, the first asset is served.
Note: This seems correct but very hard to get right. The mapping between STAC assets and WCS range elements is obviously not direct.
The "correct" behavior is to consider the stac extensions (ex: #171). So efforts here should tend towards "MVP" side of things rather than fully configurable system.
We should also consider creating a WCS coverage for Identification/Asset combination and using a naming template to smash the two identifiers together in predictable and configurable way.
The text was updated successfully, but these errors were encountered:
STAC catalogs form a graph (not acyclic!) of catalogs and items and assets.
This complex structure does not map naturally to WCS endpoint.
In this use case we limit the possible acceptable structure of STAC catalog such that this mapping exists and we can have "low friction" publishing of STAC catalog through WCS endpoint.
Note: "every Collection is also a valid Catalog"
GetCapabilities for STAC Item
For each item in catalog WCS
GetCapabilities
request includes aCoverageSummary
which uses STAC item id as its own identification. STAC item ids are expected to be globally unique, we're using that feature here.CoverageSummary
shall includemetadata
element with items for:Every element in STAC links section using their values
xlink:href
in xml elemet.self
,root
,collection
(if present)STACT asset named
meatadata
withxlink:href
(if present)Every field in STAC item
properties
list. For example Landsat 8 STAC item may have:Note: The spec talks about
ows:Metadata
STAC Assets
Each STAC item may has a list of
assets
some of which may be a raster file that could be served through WCS. STAC does not restrict what can be an asset.For purpose of this feature:
type=: image/tiff
will be includedB1
,B2
, etc. for LC8)Available assets will be encoded as bands through
wcs:Range
element per coverage.If range is not specified per during request time, the first asset is served.
Note: This seems correct but very hard to get right. The mapping between STAC assets and WCS range elements is obviously not direct.
The "correct" behavior is to consider the stac extensions (ex: #171). So efforts here should tend towards "MVP" side of things rather than fully configurable system.
We should also consider creating a WCS coverage for Identification/Asset combination and using a naming template to smash the two identifiers together in predictable and configurable way.
The text was updated successfully, but these errors were encountered: