STAC’s evolution is reshaping how organizations publish, find, and use open geospatial data in the cloud.
October 2025 marked two big moments for the SpatioTemporal Asset Catalog (STAC) community: its recognition as an Open Geospatial Consortium (OGC) Community Standard and a community sprint focused on representing multidimensional data with Zarr. Together, they show how STAC is growing into a flexible framework for a wider range of geospatial data.
If you're working with cloud-native geospatial data, here's why this matters.
Presenting the Zarr Summit results
STAC recognized as an OGC Community Standard
The OGC officially recognized STAC as a Community Standard, covering both the core specification (v1.1.0) and API specification (v1.0.0). This milestone represents years of community work and widespread use in production systems across the geospatial industry.
In practice, this means STAC is now part of the formal standards landscape while keeping its community-driven development model. This recognition gives organizations more confidence to adopt STAC without slowing its evolution. For data providers and users, it reduces implementation risk and signals long-term stability.
Tackling Multidimensional Data with STAC+Zarr
Modern cloud-native geospatial workflows increasingly involve multidimensional data such as climate models, atmospheric measurements, and oceanographic observations. While STAC excels at cataloging discrete scenes, representing complex data cubes with multiple variables and dimensions has required new patterns.
From October 14-16, 26 developers from across the STAC and Zarr communities convened at European Space Agency ESRIN in Frascati, Italy, to dig into these challenges. They focused on how to represent multidimensional Zarr stores in STAC in a way that’s clear, scalable, and interoperable. The group set out to give users the context they need to work with Zarr datasets through STAC without requiring them to parse entire hierarchies.
Key Technical Outcomes
Asset Discovery Patterns
The group agreed on a best practice for representing Zarr stores as STAC assets. A Zarr asset should reference a group in the Zarr hierarchy (similar to an xarray Dataset), with individual arrays described through the asset's bands array. This follows the same pattern STAC uses for components within raster assets like Cloud Optimized GeoTIFFs, enabling users to discover variables through metadata and construct the correct paths without parsing the entire Zarr hierarchy.
Datacube Extension Evolution
The sprint explored consolidating the datacube extension's cube:variables with the core STAC bands concept. This would align multidimensional data with its existing raster data patterns, making metadata richer and simpler. The community is still weighing the trade-offs - especially around CF-convention datasets, terminology, and backward compatibility.
Domain-Specific Patterns
Work on EOPF-specific STAC patterns addressed European Space Agency requirements for Sentinel products in Zarr format. These patterns show how STAC's extensibility supports specialized workflows while maintaining interoperability.
Zarr-embedded STAC
The idea of embedding STAC metadata directly inside Zarr stores sparked interest. This could enable self-describing archives that remain discoverable through catalogs.
The sprint's detailed notes and roadmap provide guidance on implementing these patterns. Next steps include finalizing documentation for these best practices, completing the datacube extension PR, and setting up reference implementations.
Building tools for federated catalog discovery
As STAC adoption grows, one practical challenge stands out: how do you search across multiple independent catalogs?
Through our work on the MAAP project, we built a lightweight solution:
stac-fastapi-collection-discovery: A collection-search-only STAC API that interleaves results from multiple upstream STAC APIs. It lets users search federated catalogs without requiring providers to modify their own implementations.
Federated Collection Discovery UI: A simple interface to search collections across federated catalogs. Try the example deployment to see federation in action.
These tools rely on STAC API extensions for collection search and free-text search. If you maintain a STAC API, implementing these extensions lets your catalog plug into federated discovery ecosystems out of the box.
What's Next
These developments show how STAC is evolving from a satellite imagery standard to a flexible framework for many kinds of geospatial data. The multidimensional data patterns coming out of the Rome sprint meet real needs in climate science, Earth system modeling, and hyperspectral analysis. OGC Community Standard recognition gives STAC institutional weight while preserving its open development model. Federation tools make it easier to scale discovery as more catalogs come online.
Get Involved
-
For multidimensional data you can review and comment on the best practices PR and datacube extension proposal.
-
Try out collection-search and free-text extensions to your STAC API to enable federated discovery.
-
Join the standards conversation in STAC community channels.
The STAC community keeps showing that collaborative, practical specification work can shape the future of cloud-native geospatial. These latest milestones are a big step toward making that vision real.
We’re continuing to build, test, and apply these standards in production. If your team is exploring STAC adoption, federated discovery or cloud-native data architecture, get in touch or schedule a Co-Lab session.
What we're doing.
Latest