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 note takes the engineering angle: 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

For engineering purposes it helps to read the 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. An asset is a pointer to a real file in storage — a band’s cloud-optimized GeoTIFF, a thumbnail, a metadata sidecar — so 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 is the atomic unit of search, and its value is entirely in the properties you choose to record: a footprint geometry, a timestamp, and the dataset-specific 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 carries the shared definition and extent for a family of items, and it is where you encode the things that should never vary within a dataset: the license, the band list and their 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 agreed-upon add-ons that describe clouds, projections, electro-optical bands, view angles, processing history, and the like. 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 the raster 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. This is also where the raster versus vector distinction lives in practice: STAC keeps the discovery layer uniform while the assets underneath differ, so it is the extensions and asset roles, not the catalog structure, that tell a consumer what kind of thing they are 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. Because footprints and timestamps are first-class, STAC pairs naturally with the time series reasoning that assembles comparable dates, but that only holds if updates preserve the identifiers and properties those comparisons depend on. 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 object model into a queryable service, answering spatial, temporal, and property filters server-side and paging through large result sets — the difference between a catalog you crawl and one you interrogate. 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 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. The provenance STAC records — what an item is, when it was captured, and often how it was processed — is what lets a derived result trace back to the exact observations behind it, which is precisely what makes a selection reproducible when it feeds a workflow like NDVI monitoring. The endpoints, the signing scheme, and the extension coverage change from one provider to the next; the object model, the search-filter-select logic, and the obligation to keep metadata honest do not, and that stability is exactly why STAC is worth operating as shared infrastructure rather than reinventing per project.