Designing Satellite Tasking APIs
During a recent workshop on the fringe of this year’s SatSummit, participants discussed how to design APIs that simplify ordering satellite data. Matthew Hanson wrote a summary of the workshop, noting the complexity of decision-making that goes into ordering data and tasking a satellite; arguably one reason why we haven’t seen a production-ready ordering API so far:
It turned out the most interesting discussions were centered around tasking as a process, rather than the details of a transactional API with a data provider. Tasking is really about the negotiation, as Phil Varner (Element 84) put it: a user says “This is what I want” and the provider responds with “This is what I can offer”. The questions that arose were less about detail and more about how users should interact with the provider. How do users want to discover what is feasible? How do they evaluate multiple possible options and request one or more of those options?
And consequently, how the ordering APIs could be designed:
There was a general consensus that users start by making a “feasibility request. Included in the request is usually a spatial Area Of Interest (AOI) and a date/time range, Time of Interest (TOI), and possibly some additional parameters constraining the options. What is returned by the provider is a list of possible results that may vary by total area of coverage, time of acquisition, price, resolution, sun angle, or by virtually any collection parameter.
Rather than the provider trying to make a decision of what the user wants from the available options, this choice should be pushed back to the user.
The user then gets to pick their preferred options and places the order for the product best suited for their needs.
Detailed notes of the event are on GitHub, providing some early and still rough outlines of potential API states and parameters, amongst insights on more high-level discussions.