Last week Element 84 hosted a SpatioTemporal Asset Tasking “satellite tasking sprint” at our office (formerly Azavea’s home base) in Philadelphia. This event brought together several satellite companies and developers to define and build a proof of concept API used to harmonize data ordering APIs across providers. These sprints provide a forum for representatives from throughout the industry to tackle pressing issues as a group for the benefit of the whole community.
What is “satellite tasking”?
While “satellite tasking” implies control of the satellite, in the satellite imagery industry it refers to instances in which the user is simply requesting data to be collected at some future time. Once a user requests data, the provider may then respond with a myriad of replies which vary by provider. Some may accept tasking as a request that they will try and fulfill, or as a reserved request which is guaranteed. Other providers may respond with a description of different scenes that they expect to capture and allow users to select their desired takeaway.
There is a growing set of startup satellite companies that will provide ongoing data collection services to users, which results in a burgeoning set of tasking APIs users must navigate. These APIs offer different models of selection, different sensor-specific parameters, and different pricing schemes. Some geospatial data platforms allow tasking to multiple end-providers which provide nice user-friendly and consistent experiences across providers. However, with the scale and breadth of choices across satellite platforms we believe this to be unsustainable, and we feel that adoption of a standard is the best way to increase use of remote sensing data.
Element 84’s March 2023 tasking sprint
Last month’s sprint follows a 1-day sprint that took place last September, which was a great starting point and spawned valuable discussion, but didn’t produce many actionable items. For the second sprint we wanted the focus to be on creating and documenting an API specification and developing a demo UI showing how a user may use a tasking API.
We kicked off the sprint with knowledge sharing through lightning talks, which was extremely valuable in giving attendees context before we embarked on building our own proof of concept API. We understood what was needed for a core capability and what was common across data providers.
Attendees were then divided into two workstreams. One group was tasked with discussing the specifications of the metadata and APIs (spec groups), while the other group focused on developing front-end, user-friendly implementations (implementation groups). The full group came together periodically throughout the sprint to give updates.
STAC?
The spec groups discussed whether or not tasking could be handled via STAC (SpatioTemporal Asset Catalog) Items with a metadata extension, and if a tasking request was really just a STAC Item search. Although we used STAC as a starting place to set a common direction, it didn’t take long to determine that in fact, no, tasking does not fit into STAC. There are fundamentally different concepts involved, which require bending the meaning of terms. When considering a STAC Item as a proxy for a potential future collect we saw several issues:
- A single task feasibility request might be fulfilled via multiple individual collects (which should be individual Items)
- id – Providers should not be required to store state of responses to feasibility requests, so ID should not be required, as it is in a STAC Item
- assets don’t exist for feasibility responses, and in STAC at least 1 asset is required
- datetime does not exist because a precise time would not be known
- Similarly, the properties (e.g., collection geometries) would not be discrete values, but rather ranges or an enumeration with the exact value not known until the data is collected
On the other hand, STAC, and the set of STAC extensions provide a lot of field names that should be used for tasking, since they align with the metadata that is ultimately delivered. For example, the STAC View extension provides the view:off_nadir field, an important value to provide in a feasibility request.
Tasking also requires the concept of a product. For example, users typically include: a description of the type of data they want to order be it optical, thermal, SAR, a combination of them, or other novel sensor modalities.
SpatioTemporal Asset Tasking
Metadata Spec
It’s important to establish a shared language throughout this process, and coming to a consensus on terminology is an important piece of working as a community. I’ve detailed some of the building blocks of our shared terminology here:
- Product – A description of the data to be collected (assets), combined with available parameters (i.e., queryables), and constraints (a range or enumeration of potential values).
- Opportunity – A description of geospatial data that may be collected in the future. It is GeoJSON describing the collection location, with at least a range of dates and a product. It may optionally include potential values for arbitrary fields (see Product)
- Order – An order is an Opportunity that has been created upon user request, and naturally has a state that can change until it has been fulfilled or the window of opportunity has passed.
The above definitions describe the entities that are returned by the API, and, while we initially described common-sense endpoints (/products, /opportunities, /orders), it may make sense to align the endpoints and feature set with an existing API standard, such as OGC APIs Connected Systems, or Features (as STAC is). We will leave that for a later sprint.
API Spec
Regardless of the endpoint specifics, STAT would use conformance classes, just as STAC and OGC APIs. At its most basic, a STAT API should implement:
- / – root endpoint advertising conformance classes and links
- /products – returns available products
- /orders – Returns an order based on an Opportunity Request (like a STAC Item search)
As an optional conformance class, one can implement:
- /opportunities – Returns a collection of opportunities (valid geojson) based on an Opportunity Request
The difference between `/opportunities` and `/order` is a critical difference that helped us capture provider differences in a flexible way.
A user can place a request (minimally this is geometry, datetime, and product) to either the `/opportunities` endpoint or the `/order` endpoint. If the user is ordering and the request results in multiple opportunities, it is up to the provider to choose. Instead, if using the `/opportunities` endpoint, the provider will return a list of options and it is up to the user to choose. They select the opportunity they want, then use it to place an order using the `/order` endpoint.
STAT would allow providers to offer any level of detail in the opportunity response. Perhaps they only offer two windows of opportunity, or maybe they provide multiple ranges of view angles across dozens of opportunities. Alternatively, a provider could implement a simple API (only `/products` and `/order`) where the user puts in their requirements and the provider optimizes across all of their tasks.
Demo
All of the work throughout this sprint is visible through the progress we made on a demo. Initially, the idea was to create a proof of concept with the ability to “task” Landsat or Sentinel-2. These satellites have predictive data collections, so we could return future collects as Opportunities. However, to enable a quick demo we instead just queried scenes from the existing catalog and returned those as Opportunities.
At the end of the sprint we had created a working demo depicting a user making geospatial and temporal requests and getting back real Opportunities from 3 commercial providers (along with our Landsat/Sentinel-2 example). This was made possible through work by developers from Planet, BlackSky, and Umbra who each built API proxies to power a front-end UI for the demo.
What’s next?
Although we came to an agreement of the broad framework described here during the sprint, there is still documentation to create, clean up, and organize for an initial draft of the demo to be complete. We also want the demo to be a live, interactive example–stay tuned for a 0.1 spec version and a live demo coming soon at the end of April.
We are looking forward to progressing this work further, and will be planning a third sprint to continue the work. Among evolving the STAT concepts of Products, Opportunities, and Orders, we want to explore aligning with other specifications. STAC API is built as extensions to OGC API – Features, as is the OGC API – Connected Systems. Aligning with existing standards helps with the reuse of open-source tooling. We are also interested in bringing more data providers and users into the discussion. Please stop by the Gitter channel or reach out via email to participate in the effort.
We’d like to offer a specific “thank you” to all of the individuals and organizations who contributed to this sprint and made it a success. Some of the key organizations represented were GeoRobotix, BlackSky, Capella, Albedo, Planet, Umbra, Up42, Microsoft, Open Geospatial Consortium, Sparkgeo, Skyfi, and EOI Space.
