STAC: SpatioTemporal Asset Catalog for Cloud-Native Geo Discovery

STAC (SpatioTemporal Asset Catalog) is an open JSON specification for describing catalogs of geospatial assets: satellite imagery, LiDAR point clouds, rasters, and vector layers. The key point up front: STAC is not a data format but a metadata schema that references the data itself (GeoTIFF, COG, GeoParquet, Zarr, COPC) without containing it. A four-level hierarchy — Catalog → Collection → Item → Asset — plus the STAC API REST spec have, in five years, turned STAC into the de facto standard for cloud EO catalogs: AWS Open Data, Microsoft Planetary Computer, Element 84 Earth Search, ESA Copernicus Data Space — all serve their petabytes through STAC APIs. In the OSM2CDR context STAC is not an export target but a way to catalog the raster assets we already generate (GeoTIFF, COG) inside client-owned private catalogs.

History and the specification

STAC was born in 2018 at a Boulder, Colorado meeting convened by the Radiant Earth Foundation with EO providers: Planet Labs, Digital Globe (now Maxar), USGS, and NASA. The shared problem was familiar: every imagery provider ran its own catalog with its own JSON, its own API, its own fields, and a buyer had to write a custom client per source. The STAC idea was to agree on a minimal common vocabulary (datetime, bbox, geometry, assets, properties) and one JSON shape that any provider packs metadata into while consumers query the whole market with a single client.

Version 0.6 shipped in November 2018; 1.0.0 followed in May 2021 after RFC discussions in radiantearth/stac-spec. By then critical mass had formed: Microsoft launched Planetary Computer with 70+ PB of data, AWS opened Earth Search, USGS moved the Landsat archive to STAC. Version 1.1.0 followed in 2024 with extensions for temporal mosaics and refined schema validation. STAC API matured in parallel — a REST spec built as a profile of OGC API Features. The /collections, /collections/{id}/items, and /search endpoints with bbox, datetime, and query filters became the practical standard; stac-fastapi is the server implementation, pystac-client the client, and the React-based Radiant Earth STAC Browser the browser.

Inside STAC

The spec defines four hierarchical levels and a fourth entity all of them link to:

• Catalog — a root or intermediate node. JSON with required id, description, links (to child catalogs/collections/items) and stac_version. Carries no spatial-temporal information, only structure.
• Collection — an extension of Catalog with a required extent (spatial bbox + temporal interval), license, providers, and summaries aggregating properties of its items. Semantically a homogeneous group: "all Sentinel-2 L2A scenes", "all vertical orthophotos of city X for 2023", "all our commercial OSM exports in GeoTIFF".
• Item — an individual asset with required fields id, geometry (GeoJSON), bbox, properties.datetime (or start_datetime/end_datetime), and assets. Each Item is a single GeoJSON Feature; formally a STAC Item is a valid GeoJSON.
• Asset — a link inside an Item to a concrete file with href, optional type (MIME), roles (data, thumbnail, metadata, overview), and title. One Item can contain multiple Assets: the main COG raster, a JPEG preview, an XML sidecar.

Links between levels use links of types self, root, parent, child, item, and collection. A catalog can be fully crawled by starting at root.json and following child links — that's "static STAC". Or it can be served through STAC API, and a client will walk the same links over HTTP. At the JSON level both variants are indistinguishable — the catalog format is uniform.

Use cases

Crawl & analytics on open data. The flagship scenario is satellite-imagery search for ML and analytics. A query like "all Sentinel-2 L2A scenes within Moscow bbox for June 2024 with cloud cover < 5%" against Earth Search returns a JSON list of Items with direct links to COG tiles in S3. rasterio then opens the COGs via HTTP Range Requests and reads only the necessary tiles — no terabyte archive downloads.

Commercial catalogs. Planet Labs, Maxar, and Airbus publish through authenticated STAC APIs. Buyers build a pipeline once and swap endpoints between providers without rewriting the client.

ESA Copernicus Data Space Ecosystem. In 2023 ESA migrated its entire catalog (Sentinel-1/2/3/5P/6, reprocessed Landsat, Copernicus Climate) to a STAC API; the migration from uniquely-ESA OData brought tens of thousands of users under one standard.

Private academic catalogs. University labs producing derived products (deforestation monitoring, urban heat island indices) publish datasets as mini-STAC: one Collection, thousands of Items, JSON in a GitHub repo plus a static stac-browser on GitHub Pages. Publishing cost — zero.

Workflow in OSM2CDR

An important caveat: OSM2CDR does not export STAC as a "file format". STAC is metadata, while our strong suit is generating the assets themselves (vector in DXF/GeoJSON/PMTiles, raster in GeoTIFF/COG, structured in GeoParquet). So STAC integration works in two modes.

Mode 1: STAC sidecar for COG exports. When the user exports a bbox in COG, our cog_exporter.py optionally generates an item.json alongside the .tif — a STAC Item with id equal to the file name, geometry the bbox polygon in WGS84, datetime the export moment, assets.data.href linking to the .tif, type="image/tiff; application=geotiff; profile=cloud-optimized". A single COG download thus gives a ready "brick" to drop into a private STAC catalog (e.g. an S3 bucket) and surface through stac-fastapi.

Mode 2: user export catalog as a Collection. For Enterprise clients with export history (tier Pro+) we are planning a dedicated catalog endpoint — a dynamically generated Collection of past exports. Technically — stac-fastapi over our PostgreSQL tasks table with a JSONB column of pre-computed STAC properties. That's a Phase 9 roadmap feature.

Cross-formats. STAC compatibility of our GeoParquet and COG exports lines them up with the modern cloud-native triad STAC + COG + GeoParquet — the stack on which xarray, stackstac, lonboard and Felt are converging.

Conclusion

STAC is not yet another file format but a way to describe a catalog of geospatial assets so that one client codebase works with AWS, Microsoft, ESA, Planet, and private labs simultaneously. A four-level JSON schema (Catalog/Collection/Item/Asset) plus a REST API spec built on OGC Features make STAC the natural choice for any team that publishes or consumes EO data in the cloud. Our role in this ecosystem is generating the assets themselves (COG, GeoTIFF, GeoParquet) in a form ready for cataloging; a STAC sidecar next to every COG export is the logical next step. Start by building the asset itself on the /formats/stac/ page: pick a bbox, the COG format, and receive — together with the .tif — a valid STAC Item you can drop straight into your own catalog.

Related

• COG — Cloud Optimized GeoTIFF for cloud analytics
• GeoParquet — columnar vector format for the cloud
• PMTiles — single-file vector tiles

Sources

• STAC Specification — stacspec.org
• STAC GitHub — github.com/radiantearth/stac-spec
• STAC API spec — github.com/radiantearth/stac-api-spec
• pystac documentation — pystac.readthedocs.io
• AWS Earth Search — earth-search.aws.element84.com
• Microsoft Planetary Computer — planetarycomputer.microsoft.com