SpatioTemporal Asset Catalogs and the Open Geospatial Consortium
By: Chris Holmes
Tags: Earth Observation, Stac Spec, Geospatial, Standards, Satellite Imagery

As SpatioTemporal Asset Catalog (STAC) specification matures one of the more frequent questions we get asked is the relationship between STAC and the Open Geospatial Consortium (OGC). I wanted to write this post to help clarify, at both a technical and an organizational level.

The tl;dr version is:

‘STAC API implements and extends the OGC API — Features standard, and our shared goal is for STAC API to become a full OGC standard’

The longer version has a lot more detail, but if you’re interested then read on!

The Backstory

STAC started in October of 2017 when Radiant Earth Foundation convened a group of diverse people to come together to solve a common problem: every API to find satellite imagery was a JSON, RESTful service, but every single one was different. Most everyone had looked at the OGC specifications, but at the time there was nothing that fit well, as the W*S standards (WMS, WFS, etc) were in XML and not quite RESTful, and never quite had a clear answer for searching satellite imagery (outside of CSW ebRIM profile, which had been fading). At that point, I’d also been a board member of OGC for over 4 years, and it felt like I’d made very little progress on some of my core pushes that I believe would build better specifications — small pieces loosely coupled, fully open development, JSON/REST, focus on developers, build specs on GitHub. I helped bring GeoPackage to 1.0, and dragged it along to be the first OGC specification on GitHub, but it was really just ‘published’ to GitHub — we weren’t using any of the tools (Jeff Yutzler subsequently did lead GeoPackage to truly embrace GitHub, which has been great to see).

GeoPackage now has a robust & collaborative GitHub repository

So I decided that the best route available to me was to build outside of OGC, and then bring results and practices in when they were more mature. So that’s always been the plan, but things have actually unfolded in a much more aligned way. Right before we started STAC, I saw Clemens Portele at an OGC Member Meeting at Ordnance Survey and realized that the shifts I had been hoping to trial outside of OGC were already happening inside. They were starting the new version of Web Feature Service according to all the principles I had been trying to promote at the board level, but it had emerged bottom up. The time was right to embrace GitHub, REST, JSON, and simpler, smaller specifications.

At the inaugural STAC sprint, Radiant Earth provided a neutral meeting venue for diverse actors to meet in person and align. We used WFS 3 (which became OGC API — Features) as our starting point. It had only just started and was honestly a bit too early for us, so it served more as inspiration. But we’ve done two of our six sprints in collaboration with the OGC API — Features group, seeking to always align ourselves.

Alignment

Once the OGC Features API stabilized to 1.0 we worked to fully align STAC 0.8.0 with the published standard. This means every STAC API is an OGC Features API. Clients that work with OGC Features API will work with STAC API’s. STAC adds a bit of functionality that our users needed, mainly richer filtering, transactions, sorting, property names, versioning, and cross-collection search. While STAC has run ahead on several of these we are working to make it so each of those pieces of functionality can be a ‘building block’ that OGC Features API’s that don’t implement STAC can use. In STAC API 1.0.0-beta.1 we adopted OGC’s ‘conformance classes’ functionality, which helped us make STAC into smaller building blocks, and helps to make it clear to clients exactly what functionality (OGC Features API & STAC) a service supports.