Announcing the SpatioTemporal Asset Catalog (STAC) specification
By: Chris Holmes
Tags: Cloud Native Geospatial, Standards, Geospatial, Satellite Imagery, Stac Spec

Today I am pleased to announce that the SpatioTemporal Asset Catalog (STAC) repository is ‘open for business’. This was the result of a lot of work by many amazing people at the Boulder sprint, bringing together a huge variety of perspectives to increase interoperability in searching for satellite imagery and other spatiotemporal assets. There is still lots of work to do to turn STAC into a really solid specification, but we invite any interested developer to check out the latest version, implement in their software, and participate in the open collaboration to iteratively improve it.

What is a SpatioTemporal Asset Catalog?

The SpatioTemporal Asset Catalog, also known as STAC, is an open specification that came about from 14 different organizations coming together to increase the interoperability of searching for satellite imagery. When a user wants to search for all the imagery in their area and time of interest they can’t make just one search — they have to use different tools and connect to API’s that are similar but all slightly different. The STAC spec aims to make that much easier, by providing common metadata and API mechanics to search and access geospatial data.

While the scope was initially focused on imagery, it became clear that the most valuable thing to do was to define a small, flexible, solid core that could handle a wider variety of information — derived data, point clouds, hyperspectral data, etc. Several attendees had built catalogs that originally just handled imagery, but they soon got pulled towards other types of geospatial assets. So the end definition of an Item in a SpatioTemporal Asset Catalog is a GeoJSON Feature that includes links to its ‘assets’ that can be downloaded or streamed.

The end goal of this work is to enable a global index of all imagery (satellite, aerial, drone, etc), derived data products and alternative geospatial captures (LiDAR, SAR, Full Motion Video, Hyperspectral, etc). The STAC specification focuses on the fundamental first step towards that goal — an easily implementable standard for organizations to expose their data in a persistent and reliable way. This enables their geospatial holdings to be crawled and queried. So the STAC specification by itself has no aim to provide one single index. Instead the aim is to encourage the basic unit of information from which a variety of indexes can be built.

For STAC that basic unit is the actual geospatial asset (such as a geotiff, ideally a cloud-optimized one) and a JSON description of the core fields. This mirrors the design of the web as a whole — html pages are the basic unit of information, and companies like Google build the global search index. Creating a great geospatial search index is left to others to innovate on, but the STAC spec aims to encourage software implementations and data providers to expose their holdings in a way that everyone can understand.

So STAC itself has no aim to provide one single index, but to encourage the basic unit of information from which a variety of indexes can be built. For STAC that basic unit is the actual geospatial asset and a JSON description of the core fields. This mirrors the design of the web as a whole: html pages are the basic unit of information, and companies like Google build the global search index. Creating a great geospatial search index is left to others to innovate on, but the STAC spec aims to encourage software implementations and data providers to expose their holdings in a way that everyone can understand.

Update: For more information on the power of STAC, see posts on the potential of STAC and static catalogs in depth.

Specification Overview

The SpatioTemporal Asset Item

A STAC Item is the core of any implementing Catalog, and is defined by a json specification. The repo directory the spec lives in includes a number of samples, additional documentation, and JSON Schemas for validation. The Item is a GeoJSON feature, so can be easily read in most any GIS, and includes additional fields for the time the asset represents, a thumbnail, and links to other relationships and the core assets. It is currently a very flexible specification, as it can easily combine with other JSON structures of data. Most any additional fields can be added to the core structure, and it is anticipated that data and software providers will use it in lots of different ways. In time there should emerge shared fields in various domains, and once consensus solidifies these will be available as extensions to the core specification.