Remote Sensing Labs
Browse all docs

STAC Overview

The STAC Catalogs page introduces the SpatioTemporal Asset Catalog from the reader’s side — the object model and the reasoning that make imagery discoverable. This page takes the publisher’s side: what it means to operate a catalog rather than merely query one. The shift in perspective matters because the same object model that makes discovery pleasant for an analyst is also a contract you have to populate, validate, index, and keep correct as data flows in. STAC is deliberately small, and that smallness is what lets it sit at the seam between object storage below and search, processing, and applications above. The engineering job is to hold that seam steady: to make sure the metadata that describes your assets stays accurate, findable, and traceable as collections grow from a handful of scenes into archives that no one will ever read by hand.

The object model as a contract you populate

The object model is defined on the reader’s page; for engineering purposes it helps to read the same catalog → collection → item → asset chain not as a description of data that already exists but as a set of obligations you take on when you publish. Every asset link is a promise that the object is where you say it is and is readable by whoever holds the item. An item’s value is entirely in the properties you choose to record — footprint, timestamp, and the fields an analyst will filter on. An item with a sloppy footprint or a missing cloud-cover field is not wrong so much as invisible — it will simply fail to match the queries that would have surfaced it. A collection is where you encode the things that should never vary within a dataset: the license, the band list and its meanings, the spatial and temporal bounds. The catalog is the entry point that links the whole tree together. The engineering discipline is to treat each level as the authoritative home for a specific kind of truth, so that a fact lives in exactly one place and the same fact never drifts between two items that should agree.

Extensions, and metadata you can actually rely on

The STAC core is intentionally thin, and almost everything domain-specific arrives through extensions (the STAC Catalogs page explains what they are and why coverage varies). Some metadata has moved the other way: STAC 1.1 promoted band descriptions into core as a common bands array, replacing the separate eo:bands and raster:bands fields, so check which version your consumers’ tools expect. Extensions are what let a raster item advertise its coordinate reference system and native resolution, or a machine-learning output declare the model that produced it. From an operations standpoint the important thing about extensions is that they are optional, which means their presence is a decision you make and then must honor consistently. If half of a collection’s items carry the projection extension and half do not, a consumer cannot rely on filtering by it, and the collection quietly loses part of its searchability. So the engineering posture toward extensions is deliberate: choose the small set your consumers actually need — typically band and projection metadata that connects to digital imagery and the coordinate systems an item sits in, plus whatever your processing track requires — and then populate them on every item, every time. Extensions and asset roles also carry the raster versus vector difference: the catalog structure looks the same for both, so these fields are what tell a consumer what kind of thing it is about to fetch.

Making a catalog searchable and operable

A catalog earns its keep only if the queries analysts want to run return the right items quickly, and that turns on a few operational concerns the object model alone does not settle. The first is indexing: a static tree of JSON files can be crawled, but a large or frequently queried archive needs its geometries, timestamps, and filterable properties in an index that answers spatial-and-temporal searches without walking every item. The second is validation — checking, before an item is published, that its geometry is well-formed, its datetime is present and sane, its asset links resolve, and any declared extension fields are actually filled. Validation is cheapest at write time and most expensive after a bad item has already been indexed and cited downstream. The third is versioning and updates: archives are not static, and you will re-process scenes, correct metadata, and add newly acquired observations. The catalog needs a defined story for how an item changes — whether it is replaced in place, superseded by a new identifier, or carries a version field — so that a consumer who recorded an item id can tell whether the thing behind it still means what it did. Any time series a consumer assembled from the catalog is only as stable as those identifiers and properties, so updates must preserve them or announce the break. Get these three right — index for the queries you serve, validate before you publish, and define how items change — and the catalog stays trustworthy as it grows; neglect them and it degrades into a store that technically parses but no longer answers questions reliably.

Where STAC sits in the architecture

STAC is a metadata and discovery layer, not a storage system and not a compute engine, and keeping that boundary clean is most of using it well at scale. Underneath sit the actual bytes in object storage, usually as cloud-optimized GeoTIFFs whose internal tiling lets a consumer read a window of a scene without downloading the whole file; STAC’s job is only to point at those objects and describe them, never to hold them. Above the catalog, a STAC API turns the static tree into a queryable service. Serving one is an engineering commitment of its own — the index behind it, and which search extensions you implement, decide which of your consumers’ filters actually work. That API is the discovery front door for the cloud-native geospatial patterns this track builds on, where processing reads assets directly from storage rather than staging local copies. Two operational realities live at this boundary and are worth planning for early: results arrive in pages, so any client that enumerates a large query has to iterate rather than expect one response; and if assets are protected, the signing service and its token lifetimes become part of what you operate. For a publisher, provenance is a write-time duty: the processing and source fields you populate are all a consumer of a workflow like NDVI monitoring will have to trace a result back to its observations. That shared obligation, more than any one provider’s endpoints, is why STAC is worth operating as common infrastructure rather than reinventing per project.

Sources