OGC API — Features + STAC Sprint Recap
By: Chris Holmes
Tags: Ogc, Specifications, Geospatial, Stac Spec, Cloud Native

Introductions and Kick-off

We kicked off the first day with a round of introductions, rotating between everyone gathered in-person and remote. We had a number of people fly in from Europe and Canada, and remotes joined from as far away as the Philipines, joining at 10:00 pm. It was great to see so many people from different backgrounds coming together to work on common standards, and it’s nice to see the communities grow with each sprint, welcoming in new faces.

The focus for the day was to kick off the joint work between STAC and Features API, particularly a powerful Filter language that both could use, and tackling a number of other parts of a full-fledged Query, like sorting, paging, requesting specific fields and more.

Beginner Sessions

While sprints are a time for the specification experts to go deep on major topics together, they are also a prime opportunity to welcome new people into the community. Building on some ad-hoc sessions at the last STAC sprint, we decided to have 4 explicit ‘Beginner Sessions’, so those who are newer can get up to speed and ask all their newbie questions in a friendly environment. We kicked off with a walkthrough and Q&A of STAC, and then Rob Emanuele gave a great introduction to creating and working with STAC catalogs using PySTAC, so participants didn’t just have the theory of STAC but also some practical hands-on experience. We streamed out all the sessions, but only managed to record the PySTAC one, which you can see on youtube.

PySTAC Tutorial delivered by Rob Emanuele

On day two we repeated the structure of walkthrough and then hands-on, but this time Peter Vretanos gave the overview of OGC API — Features, and Tom Kralidis did a great introduction to pygeoapi, a leading OAFeat implementation (that actually implemented STAC during the sprint!). The sessions overall seemed to work quite well, and hopefully, at the next sprint, we’ll have even more sessions, diving deep into various tools that people can use.

Happy Hour

Another new tradition that started at the last sprint and we continued this time was a happy hour, hosted by Element84 at their office in Alexandria. And in our effort to make these events more remote-friendly, this time we managed to record the lightning talks! The video mostly shows the presenter, so I’ve included a link to the slide decks where possible, so you can follow along.

Matt Hanson presenting at the Happy Hour at Element84

It was amazing to see the diversity of perspectives coming together around standards, and how these two very young specifications are already tackling major real-world problems.

We also joined the GeoDC Meetup on the next night, sharing about STAC and OGC API. It was great to interact with the local geospatial community, and we hope to repeat that at future events.

Results

It would take a lot of text to recap all that happened at the sprint, with so many great discussions throughout. I think the major results will speak for themselves, in terms of improvements to the STAC and Features API specifications, and an ever wider ecosystem of implementations. But I’ll quickly go through some of the highlights. There are rough notes on everything we talked about at, with lots of links to the work that was done. And we also recorded the full session (though unfortunately missed the very beginning — an update from Peter Vretanos on work he did on his server and the OGC API — Features specification), you can watch it on youtube.

Implementation Work

pygeoapi — As mentioned above, pygeoapi implemented STAC support during the sprint, which was awesome to see come together. Several other features were also worked on, including cross-collection search, many: many feature: collection connections, improvements to the postgresql provider, and several more. Tom also implemented one of the things I’ve wanted to see — automatically making an OGC API — Catalog from the collection's metadata.

code.usgs.gov/stac was started to enable USGS’s Water Missions Area and Landsat/EROS teams to collaborate around STAC.

Ordnance Survey put together a Java springboot server implementing OGC API — Features that served up OS data. A prototype is up at os-ogc-features-api.azurewebsites.net/ and Ordnance Survey seems quite committed to continuing in this direction. It was awesome to see that the spec is easy enough to make a complete server from scratch in less than three days.