A version of this article originally appeared in the May/June 2021 issue of GeoConnexion Magazine under the title ‘Lowering The Barrier To Entry.’
For the last few years, OGC has been modernizing our standards to better align with web best-practices and the expectations of developers and consumers alike, resulting in our growing OGC API family of standards. Part of this effort has also been to design our standards to better take advantage of cloud infrastructure, including being able to deploy and share spatial analysis workflows across different cloud providers. This approach will benefit collaboration, transparency, and accessibility of scientific workflows – which are all cornerstones of the “Open Science” movement. I previously touched on these Earth Observation processing packages in the “App Store For Big Data” article in the July/August 2020 issue of Geoconnexion Magazine, which discussed our “Applications-to-the-data” architecture, and the Application Deployment and Execution Service (ADES) APIs.
The DAPA Convenience API
Another part of the effort to simplify Earth Observation data processing and analysis workflows is the development of the OGC Data Access and Processing API (DAPA). Developed as a draft specification during OGC Testbed-16 in 2020, and having been tested in real-world scenarios during our Testbed-17 initiative and EO Apps Pilot, DAPA is a so-called “convenience API” that allows scientists and other geospatial analysts to run several operations on Earth Observation or other data using a single API call, in turn providing the data in a form directly ready for further analysis. This differentiates DAPA from existing APIs such as OGC API – Features or OGC API – Coverages. Where the latter two are data-centric APIs with a focus on data access and subsetting, DAPA is a user-centric API that includes data access with processing. As such, it takes lots of processing burden away from the user.
DAPA does this in a way that is mostly independent of the data location – meaning that the same call can access data stored in a local file, an in-memory structure (such as an xarray), or remotely in the cloud. Ultimately, this means that an end-user can initiate the process on one archive for one set of data, then just change the URL to have the same process(es) run on an entirely different dataset.
For example, with a single DAPA API call, you can say “please give me all the data you have for this specific area and time window, with these fields and as a result of this map algebra.” A data cube is then created on the fly and delivered to you in a form ready for you to work on in your software of choice. And, say you run that on a Landsat archive, you could then use the same API call to reproduce it on, say, a PeruSat-1 archive.
DAPA and ADES fit within a spectrum of different processing APIs available from OGC [click to enlarge]
Reproducibility and Open Science
The reproducibility of the DAPA calls, just like the packagability of the ADES ‘apps,’ makes them ideal for use in support of the Open Science movement. The Open Science movement aims to make scientific research and its dissemination more accessible – by professionals and amateurs alike – and to generate transparent and accessible knowledge that is shared and developed through networks of collaboration. The movement is receiving big support from OGC Strategic Members NASA and ESA, who have also been instrumental in their sponsorship of the development of DAPA and ADES. Indeed, open standards in general, due to their enabling of the interoperability required for collaboration across organizations and disciplines, play a critical role in Open Science, too.
The synergy between OGC’s mission for FAIR (Findable, Accessible, Interoperable, and Reusable) data standards and their benefits to the reproducibility of scientific research has led to the topic of ‘Identifiers for Reproducible Science’ to be explored in this year’s Testbed-18 Initiative. The task shall develop best practices to describe all steps of a scientific workflow, including: input data from various sources such as files, APIs, data cubes; the workflow itself with the involved application(s) and corresponding parameterizations; and output data. By accurately describing the workflows of scientific studies, the studies can then be better reproduced and scrutinized – both hallmarks of the scientific process.
The Open Science movement’s desire to make scientific data and processes accessible by more than just scientists ties in well with OGC’s recent efforts to design standards with a strong end-user-centric perspective, rather than the data-provider centric view that has come to dominate earlier standardization work. This means simplifying and improving not just their form and function, but also their documentation.
User-friendly standards
Rather than reading Standards Documents – which are, by their nature, meticulously defined to reduce room for interpretation and therefore tedious to read – many developers favor an approach that starts with simple documentation and examples. From there, additional features are explored stepwise, with the actual standard document often being the last resource being consulted. As location tech grows outside of the traditional geospatial spheres of expertise, this user-centric view becomes critical if the benefits of widespread standards adoption are to be realized.
With this in mind, work undertaken in Testbed-17 lowered the barrier of entry to implementing and accessing DAPA and other OGC APIs by creating sets of example code for both server- & client-side software, scripts for cloud deployment & installation, and best practice guides. To this end, Testbed-17 delivered the Engineering Report Attracting Developers: Lowering the entry barrier for implementing OGC Web APIs, which provides the knowledge necessary to develop, deploy, and execute standards-based Web APIs to Web developers, following a “How-To” philosophy with lots of hands-on experiments, examples, and instructions. Better yet, by providing scripts that illustrate the deployment and operation of API instances on local machines as well as across different cloud environments, it will make the challenge of mapping software components to cloud infrastructure a smooth experience.
In addition to the documentation, code examples, and implementations meant to make the lives of users easier, OGC has also recruited its first Developer Relations (DevRel) staff member, Joana Simoes. Joana provides an interface between OGC and the developer community, with a specific look at addressing: What do developers need from OGC? Where do they struggle? What materials can we provide to help?
All of these activities have come from OGC’s ambitions to make our standards easier to understand and implement, and to feel more tangible than our earlier work. OGC stands behind its position that standards – through making data Findable, Accessible, Interoperable, and Reusable – unlock tremendous value and power cross-collaborations that offer many benefits to society. By making the standards themselves align with the FAIR principles, we are lowering the barriers to their adoption and spreading their value further.
What do you think OGC can do to help make our standards easier to understand and implement? Let OGC and our DevRel, Joana Simoes, know at ogc.org/contact.
