STAC Catalogs

STAC — the SpatioTemporal Asset Catalog — is not itself a source of imagery; it is the shared language that makes every other source discoverable. Where the Sentinel-2 and Landsat pages describe what the data is, STAC describes how you find and select it in a way that works the same across providers. Cloud archives hold petabytes of scenes, and without a consistent way to ask “which images cover this area, in this time window, below this cloud cover,” that volume is unusable. STAC is the community answer: a small, agreed-upon metadata specification that lets one search pattern and one mental model span many catalogs. Learning it once pays off everywhere, which is why it sits between this site’s data-acquisition material and its engineering track. This page is conceptual — the object model and the reasoning — not a tour of any one provider’s endpoints.

The object model

STAC’s usefulness comes from a small, nested set of objects, and understanding how they relate is most of understanding STAC. At the bottom is the asset: an individual file or resource — a single band’s cloud-optimized GeoTIFF, a thumbnail, a metadata sidecar. Assets are grouped into an item, which is the atomic unit of a STAC search: one item represents one observation of one place at one time — typically a single scene — and carries the properties you filter on, chiefly its footprint geometry, its timestamp, and dataset-specific fields like cloud cover. Items belong to a collection, which groups items that share a definition — all Sentinel-2 surface-reflectance scenes, say — and holds the metadata common to them: the license, the spatial and temporal extent, the list of bands and their meaning. Collections in turn are organized by a catalog, the top-level entry point that links out to everything beneath it. The chain runs catalog → collection → item → asset, and it maps cleanly onto the questions you actually ask: which dataset, which observations, which files.

Why the consistency matters

The payoff of that shared model is that discovery and selection become repeatable across providers. Because every compliant item exposes its geometry and time the same way, a single spatial-and-temporal query works whether you point it at one archive or another, and the results describe themselves consistently enough to compare. This is what lets a workflow specify its inputs precisely — a collection, a bounding area, a date range, a cloud-cover ceiling — and get back the same set of items on every run, which is the reproducibility the applied workflows depend on. STAC also carries provenance: an item records what it is, when it was captured, and often how it was processed, so a downstream result can be traced to the exact observations behind it. Because footprints and timestamps are first-class, STAC fits naturally with the Coordinate Systems reasoning about where data sits and the Time Series reasoning about assembling comparable dates. And since assets are just referenced files, the same catalog can describe optical imagery, other rasters, vector products, and model outputs alike — the Raster vs Vector distinction lives in the assets, while the discovery layer above stays uniform.

Limitations and honest caveats

STAC is a specification, not a guarantee, and its limitations are mostly about the gap between the standard and any given implementation. Catalogs vary in quality and completeness: two providers can both be “STAC-compliant” yet differ in how richly they populate metadata, how they name things, and which optional extensions — the add-ons that describe clouds, projections, view angles, and the like — they actually support. So a filter that works against one catalog may find nothing useful in another simply because the field it relies on is absent, and you cannot assume every property you want is present until you check the collection’s definition. There are also access realities: many cloud assets are protected, so an item’s asset links may need to be signed to become temporarily readable, and those signed links expire — a detail that matters the moment you move from browsing to fetching. None of this makes STAC unreliable; it means you read the specific catalog’s conventions rather than assuming one provider’s flavor is the universal standard.

STAC in a workflow

Seeing STAC in motion ties the object model to real work. A typical data-acquisition step is a short pipeline: search a catalog by collection, area, and time window; filter the returned items by properties such as cloud cover or processing level; select the comparable subset the analysis needs — perhaps the least-cloudy item per month over a season; and then hand those items’ assets to processing as inputs, carrying their identifiers forward so the result records exactly which observations produced it. That last step is where STAC’s provenance turns a one-off download into an auditable, repeatable selection: the search parameters and the item list together are a specification anyone can re-run. This pattern is how STAC feeds the acquisition side of workflows like NDVI Monitoring and any multi-date Change Detection, and it is the same model the site’s engineering track builds on in the STAC Overview page, where the operational details of paging through results, validating metadata, and handling signed assets are developed further.

Accessing catalogs

STAC is accessed two broadly different ways, and knowing which you are dealing with shapes how you query. A static catalog is just a set of linked JSON files hosted somewhere — you crawl it by following links, which is simple and cheap but not built for arbitrary queries at scale. A STAC API is a dynamic service that answers search requests directly, letting you filter by geometry, time, and properties server-side and page through large result sets — the right tool when a catalog is big or you need flexible queries. Client libraries wrap either style so you work in terms of collections and items rather than raw requests, and many analysis platforms, including cloud archives and hosted environments like the Microsoft Planetary Computer, expose their holdings through a STAC API precisely so that one familiar pattern reaches all of them. Whichever route you take, the durable reasoning is the same: you are navigating catalog → collection → item → asset, filtering on space, time, and properties, and preserving the item identifiers that make the selection reproducible. The endpoints and conventions change from provider to provider; the object model and the search-filter-select-provenance logic do not, and that is what makes STAC worth learning once and using everywhere.