{"id":17118,"date":"2021-01-20T17:42:00","date_gmt":"2021-01-20T22:42:00","guid":{"rendered":"https:\/\/www.ogc.org\/?p=5601"},"modified":"2025-11-16T18:27:12","modified_gmt":"2025-11-16T18:27:12","slug":"bringing-stac-into-ogc","status":"publish","type":"post","link":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/blog-article\/bringing-stac-into-ogc\/","title":{"rendered":"Bringing STAC into OGC"},"content":{"rendered":"\n

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<\/a><\/em> family of standards aims to apply the best practices of the web to geospatial<\/a> while also shifting from monolithic services to a set of \u2018building block\u2019 components that can add spatial capabilities to any modern API, well before STAC. <\/p>\n\n\n\n

What became known as OGC API – Features<\/em> was originally named WFS 3.0, and it was quite different<\/a> 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<\/a> to work on the interoperability of satellite data APIs, which kicked off the Spatial Temporal Asset Catalog (STAC)<\/a> 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<\/em> have been evolving together and continually aligning. Indeed, the second<\/a> and fifth<\/a> STAC sprints were done in conjunction with OGC API – Features <\/em>team.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

But, as both specifications mature and get more adoption, we\u2019ve received more and more questions about the relationship between the two specifications. Radiant Earth<\/a>, the steward of STAC, just put together a medium post<\/a> explaining exactly how the two specs work together. We wanted to reiterate what it says, and provide OGC\u2019s perspective. The main takeaway is:<\/p>\n\n\n\n

\u2018STAC API implements and extends the OGC API \u2014 Features standard, and our shared goal is for STAC API to become a full OGC standard\u2019<\/strong><\/em><\/p>\n\n\n\n

From OGC\u2019s perspective, we have identified that STAC has a clear role to play in our evolving OGC API<\/em> standards baseline, to help bridge the core building blocks to a variety of user needs, especially in the remote sensing and \u2018new space<\/a>\u2019 communities. OGC API – Features<\/em> enables any spatial \u2018feature<\/a>\u2019 to be represented in a web api, and all SpatioTemporal Assets are features, where the geometry is generally a footprint of the data represented. <\/p>\n\n\n\n

The long term vision is for the STAC API specification<\/a> to simply be a bundle of OGC API<\/em> building blocks that are relevant for the STAC use cases, with STAC Core specs<\/a> providing the content to be used with any relevant OGC API<\/em> component. Getting to that vision requires a lot of work on the core OGC APIs<\/em>, so our plan is to continue to evolve and align OGC APIs<\/em> with STAC, while following our processes to merge the STAC community with our OGC standards process.<\/p>\n\n\n\n

The first step will be to bring STAC in as a Community Standard<\/a>, 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<\/em> components in close alignment with STAC. Indeed, OGC API – Records<\/em> has recently shifted its path slightly to better align with STAC (see GitHub issues #58<\/a> #62<\/a> #22<\/a> for more detail), while STAC is working<\/a> to align<\/a> to OGC API – Features<\/em> Parts 3 (CQL) and 4 (Transactions), and their future work<\/a>. And the recent STAC API 1.0.0-beta.1 release<\/a> also adopted OGC\u2019s style of conformance classes, which also enables easier alignment. <\/p>\n\n\n\n

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<\/em> 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. <\/p>\n\n\n\n

If you have any remaining questions about the relationships between the standards, don\u2019t hesitate to ask<\/a>. And please join us in shaping the open, interoperable geospatial future.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":17917,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_eb_attr":"","footnotes":""},"categories":[190],"tags":[204,174,205],"class_list":["post-17118","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-article","tag-ogc-api-features","tag-ogc-apis","tag-stac"],"acf":[],"_links":{"self":[{"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/posts\/17118","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/comments?post=17118"}],"version-history":[{"count":2,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/posts\/17118\/revisions"}],"predecessor-version":[{"id":23545,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/posts\/17118\/revisions\/23545"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/media\/17917"}],"wp:attachment":[{"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/media?parent=17118"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/categories?post=17118"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fm-connect1.fortmindz.in\/wp-ogc\/wp-json\/wp\/v2\/tags?post=17118"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}