STAC (SpatioTemporal Asset Catalog) lets people discover and filter datasets to find exactly which data they need to answer their questions. It is a flexible specification and that flexibility can be both powerful and a bit of a curse. It can be hard to figure out how to do things “right” – in a way that will integrate well with other catalogs and be well supported by tooling.

STAC has seen significant adoption in the earth observation community across many different scales of data producers including large government efforts like Landsat and large commercial efforts like Earth Search and Microsoft’s Planetary Computer. Many of these STAC implementations contain exclusively satellite imagery. They have a collection for each data product (for instance “landsat-c2-l2”) and within that collection there is an item for each scene. The items contain assets pointing to COGs on object storage. That is a well-documented way to use STAC.

But STAC is not just for satellite imagery. STAC is a specification for defining and searching any type of data that has spatial and temporal dimensions. For example you can use standalone collections and the Datacube Extension to represent n-dimensional data cubes (such as an earth system model stored in Zarr). Or you can catalog all the sensor data captured during a research cruise using one collection per data type. To capture that kind of data you need to know how much metadata to capture at the STAC level and how to structure your STAC hierarchy. This talk will go through the interconnected decisions and discuss how to weigh priorities to maximize the usefulness of your STAC.