Last summer at FOSS4G Kosovo I gave a talk on the last tasking sprint we ran in Philadelphia. Afterward, European Space Imaging (EUSI) approached me, interested in how they could become involved. A later discussion with Felix and Miriam from Up42 sparked the idea of hosting the next Tasking Sprint at Up42 Berlin, a central hub for European businesses and several geospatial companies.

STAC (SpatioTemporal Asset Catalog) has established itself as a successful model for interoperability in the geospatial community. However, previous tasking sprints were all held in the US, limiting participation from other regions. With the aim of engaging a wider audience and fostering global collaboration, Berlin was an ideal location for our next sprint. Its central location in Europe made it easily accessible for many interested companies and individuals, allowing us to tap into a broader pool of voices and business models. Attending data providers (BlackSky, Satellogic, Open Cosmos, Umbra, Planet, EUSI, SatVu) provided insights into different business models, and data consumers and resellers (Up42, LiveEO) had experience with multiple APIs across providers.

Accomplishments

This sprint was larger than the last two efforts which made it slightly more difficult to efficiently manage and create a consensus, but by keeping the goals focused and breaking into smaller groups, it was overall a productive and positive experience for everyone involved. We formalized and documented the spec itself, with over 60 PRs from more than 20 contributors. We developed a deployable and extensible FastAPI project implementing the spec that can be used to create custom proxy APIs to existing tasking APIs, as well as a map-based UI to query and explore tasking opportunities from multiple providers.

In addition to the spec, this sprint focused on developing open-source tooling for deploying and working with API implementations.  We developed a deployable and extensible FastAPI project that implements the specification. This project serves as a backbone for creating custom proxy APIs to existing tasking APIs, enabling easier integration with different geospatial data providers. The sprint also included the creation of a map-based UI, allowing users to query and explore tasking opportunities from multiple providers in a user-friendly way.

Sponsors

Before continuing, I want to express a big thanks to our sponsors. The Berlin sprint was longer and more complex, requiring additional resources and support, than any previous sprint we conducted previously. As the host, Up42 provided an excellent venue and provided valuable contributions. AWS was not only our gold sponsor, but also provided credits for the sprint and has been a valuable partner in this effort. CEOS and the Cloud-Native Geospatial Foundation both understand and support the value of interoperability across government agencies and commercial companies as we move more workloads into the cloud. As data providers, BlackSky, Hydrosat, Satellogic, and Open-Cosmos are looking at a tasking API as a way to improve the user experience and promote a better and more scalable way to sell their services.

The STAPI Specification

The structure of the sprint was key to its success. We had three days to work with, compared to the previous sprints’ two-day format. On the morning of the first day we split into four groups, each focusing on different aspects of the spec. One group dove into developing a backend template stub, while the other three revisited the entities defined in the last sprint: Products, Opportunities, and Orders. Given the presence of new participants, some rehashing of previous discussions was expected. In hindsight, a more detailed review at the beginning might have streamlined the process, but we aimed to keep the sessions interactive and engaging from the start.

On the final day, we made an important decision: renaming the specification from SpatioTemporal Asset Tasking (STAT) to Sensor Tasking API (STAPI), since the previous name was often confused with STAC. The new name better represents the purpose of the specification and provides a clearer identity for the project. The specification and tooling repositories have all been moved into a new GitHub org – stapi-spec.

Open-Source Tooling

A significant outcome of the sprint was the creation of stapi-fastapi, an open-source library designed to implement the STAPI specification. Special thanks to Christian Wygoda from SatVu, who took the lead on developing this library. This framework comes with built-in tests, a CDK-based deployment system, and three built-in backends for testing and demonstration: Landsat-8, custom TLEs, and a generic backend. It serves as a starting library for extending the STAPI specification and fostering broader adoption.

Several provider-specific APIs were also developed, including stapi-umbra, stapi-blacksky, stapi-planet, and stapi-up42. These APIs act as proxies, allowing users to interact with existing tasking APIs from a single endpoint. This approach streamlines the user experience and reduces complexity in accessing data from multiple providers.
To demonstrate the value of STAPI, we modified our FilmDrop-UI to use STAPI endpoints instead of STAC, allowing users to interact with different providers and products. This user interface provides a practical way to evaluate the user experience and gather feedback for iterative improvements to the spec.

What’s Next?

The Berlin sprint was a significant step forward in the documentation and details of the specification, while we also developed the foundation of an ecosystem to prove out the specification. We look forward to building on this momentum and expanding the scope of STAPI to create a more connected and interoperable geospatial ecosystem.

As we look to the future, we aim to continue improving STAPI with additional sprints to develop additional tooling for validation, iterate on the spec, and work with providers to develop more implementations.. We are considering a fall sprint in theDenver, Colorado area to engage additional stakeholders. The success of the Berlin sprint also suggests another sprint outside the US would be beneficial to further broaden our reach.

If you are interested in contributing or learning more, check out the stapi-spec GitHub organization or reach out.