Over three years ago, a small group of OGC members working on the next version of the venerable Web Feature Service (WFS) standard started the next major evolution of our standards baseline. What has since become known as the OGC API family of standards aims to apply the best practices of the web to geospatial while also shifting from monolithic services to a set of ‘building block’ components that can add spatial capabilities to any modern API, well before STAC.
What became known as OGC API – Features was originally named WFS 3.0, and it was quite different from the earlier versions of WFS. Perhaps the most important thing it did was shift to a model of open development, with the entire standard evolving in the public, on GitHub. At around the same time a group of developers from 14 different organizations gathered in Boulder, Colorado to work on the interoperability of satellite data APIs, which kicked off the Spatial Temporal Asset Catalog (STAC) specifications. From the start there were many overlapping objectives between the two groups, but instead of competing, both embraced the open collaboration enabled by GitHub. So anyone paying close attention has seen that STAC and OGC API – Features have been evolving together and continually aligning. Indeed, the second and fifth STAC sprints were done in conjunction with OGC API – Features team.
But, as both specifications mature and get more adoption, we’ve received more and more questions about the relationship between the two specifications. Radiant Earth, the steward of STAC, just put together a medium post explaining exactly how the two specs work together. We wanted to reiterate what it says, and provide OGC’s perspective. The main takeaway 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’
From OGC’s perspective, we have identified that STAC has a clear role to play in our evolving OGC API standards baseline, to help bridge the core building blocks to a variety of user needs, especially in the remote sensing and ‘new space’ communities. OGC API – Features enables any spatial ‘feature’ to be represented in a web api, and all SpatioTemporal Assets are features, where the geometry is generally a footprint of the data represented.
The long term vision is for the STAC API specification to simply be a bundle of OGC API building blocks that are relevant for the STAC use cases, with STAC Core specs providing the content to be used with any relevant OGC API component. Getting to that vision requires a lot of work on the core OGC APIs, so our plan is to continue to evolve and align OGC APIs with STAC, while following our processes to merge the STAC community with our OGC standards process.
The first step will be to bring STAC in as a Community Standard, our newer, lightweight process that makes it easier to collaborate with standards work that starts outside of OGC. We will continue to evolve the OGC API components in close alignment with STAC. Indeed, OGC API – Records has recently shifted its path slightly to better align with STAC (see GitHub issues #58 #62 #22 for more detail), while STAC is working to align to OGC API – Features Parts 3 (CQL) and 4 (Transactions), and their future work. And the recent STAC API 1.0.0-beta.1 release also adopted OGC’s style of conformance classes, which also enables easier alignment.
OGC is ready to take on maintenance of STAC as a full OGC standard once the user community is ready for such maintenance. This will likely be when STAC and the core OGC APIs are mature, and only require incremental maintenance. Radiant Earth has agreed that this is the best path as well: to consolidate standard maintenance in one organization. Radiant Earth will continue to focus on the use cases and tooling around STAC, as their goal was always to incubate the standard and play their role in enabling interoperability.
If you have any remaining questions about the relationships between the standards, don’t hesitate to ask. And please join us in shaping the open, interoperable geospatial future.