STAC: How Modern Satellite Data Discovery Actually Works
Quick Answer: STAC is a standardized API for searching satellite imagery by location, time, and properties. It replaced fragmented, provider-specific search interfaces with a single specification that works across data providers. When you search for Sentinel-2 data over Tokyo from last month, a STAC query is what makes that work behind the scenes.
The Old Way Was Painful
Before STAC, finding satellite imagery meant navigating a maze of provider-specific interfaces. Want Landsat data? Go to USGS EarthExplorer. Sentinel data? ESA's Copernicus Open Access Hub. Commercial imagery? Each vendor's proprietary portal.
Each system had different search parameters, different metadata formats, different download workflows, and different APIs (if they had APIs at all). Building a tool that searched across multiple data sources required writing and maintaining separate integrations for each provider.
I spent more time in the early days of my career figuring out where the data was than actually analyzing it.
What STAC Provides
STAC (SpatioTemporal Asset Catalog) is a specification — a set of rules for how to describe and search geospatial data. It defines four core components:
Item
A single spatiotemporal dataset — typically one satellite scene. Each Item has:
- Geometry: The spatial footprint (where on Earth)
- Datetime: When it was acquired
- Properties: Metadata (cloud cover, processing level, sensor details)
- Assets: Links to the actual data files (images, thumbnails, metadata)
Collection
A group of related Items — for example, all Sentinel-2 Level-2A scenes. Collections describe the common properties shared by all their Items.
Catalog
A top-level container that organizes Collections. A single STAC server might host catalogs for multiple satellite missions.
API
The search interface. Send a query with spatial, temporal, and property filters, and get back matching Items with links to their data assets.
A Real Query
When you search for satellite data in Off-Nadir Delta, the platform constructs a STAC API query. Here's what a simplified request looks like:
{
"collections": ["sentinel-2-l2a"],
"bbox": [139.5, 35.5, 140.0, 36.0],
"datetime": "2026-01-01/2026-01-31",
"query": {
"eo:cloud_cover": { "lt": 20 }
},
"limit": 10
}
This asks: "Find up to 10 Sentinel-2 Level-2A scenes that overlap this bounding box around Tokyo, acquired in January 2026, with less than 20% cloud cover."
The response contains Items with metadata and asset links — including links to Cloud-Optimized GeoTIFF files that can be streamed directly for visualization.
The Major STAC Endpoints
Several organizations host public STAC APIs with free satellite data:
| Provider | URL | Data |
|---|---|---|
| AWS Earth Search | earth-search.aws.element84.com | Sentinel-2, Landsat, others |
| Microsoft Planetary Computer | planetarycomputer.microsoft.com | Sentinel-1, Sentinel-2, Landsat, many more |
| NASA CMR-STAC | cmr.earthdata.nasa.gov/stac | NASA missions (VIIRS, MODIS, etc.) |
Off-Nadir Delta queries these endpoints on your behalf, abstracting away the differences between providers. The user experience is consistent regardless of which backend serves the data.
Why STAC Won
Previous approaches to satellite data catalogs existed — OGC CSW, OpenSearch, custom REST APIs — but STAC succeeded because of several design choices:
JSON-native: STAC uses GeoJSON, which every web framework and mapping library already understands. No XML parsing, no custom serialization.
Static or dynamic: A STAC catalog can be a set of static JSON files on a web server (no database needed) or a full search API backed by a database. This flexibility means it works for both massive cloud archives and individual researchers sharing a few datasets.
Community-driven extensions: The core spec is minimal. Extensions add domain-specific fields (electro-optical properties, SAR parameters, scientific citations) without bloating the base specification.
Cloud-native: STAC was designed for the era of cloud-hosted data. Asset links point to cloud storage (S3, Azure Blob, GCS) where data lives, not to download queues or FTP servers.
What Users Should Know
If you're using Off-Nadir Delta or similar platforms, STAC is working behind the scenes — you don't need to write API queries yourself. But understanding the architecture helps you:
- Interpret search results: The metadata in search results (cloud cover, orbit number, processing date) comes from STAC Item properties
- Understand coverage gaps: If you search for data and get no results, the STAC catalog may not include that location/date combination — it doesn't mean the data doesn't exist anywhere
- Know the data source: Different STAC endpoints may host the same satellite data but with different processing levels or update frequencies
Explore our satellite data search to see STAC in action — every search you perform constructs and executes a STAC query against the appropriate backend.
