OGC Testbed 13 - Focussing on Mass Migration - 09/05/2018

Every year, OGC runs a research, development, and prototyping initiative called a ‘Testbed,’ the most recent of which - Testbed 13 - wrapped up last December. OGC Testbeds are a key activity of the OGC Innovation Program, and the main means by which the OGC membership, OGC’s testbed sponsors, and OGC’s partner standards organisations have made spatial information an integral part of the world’s information infrastructure.

How the Testbeds Work

Sponsoring organisations put forth geospatial IT problems. OGC staff integrate these requirements into a set of software architectures, and technology providers then receive support and funding to collaboratively research and rapidly develop prototype solutions. Eventually, the results are handed over to the OGC Standards Program where they take the form of consensus-based open standards and best practices.

Testbed 13 took the requirements of 12 sponsors, and, over the course of 9 months, 31 different participant organisations created solutions to 85 work items. These work items formed the core content of a demonstration event held in December 2017 at USGS’ headquarters in Reston, Virginia.

The demonstration was centred around the scenario of ‘mass migration’ and how geospatial technology can help displaced persons return home after conflict has ended.

With 15 newly developed technical outcomes there is simply too much information to cover in a single article, so I’ll only discuss the four most interesting outcomes presented on the day. To learn more about the outcomes of Testbed 13, visit go.myogc.org/T13.

Natural Language Queries

“What is the safest route?” is a simple question: in the context of the Testbed 13 demonstration, the non-expert user wanted to know what would be the safest route for displaced persons to take to Daraa, Syria, from the Zaatari refugee camp in Jordan, after a ceasefire had been declared. This required some forethought from the geospatial experts, as the data and processes used to answer such a question needed to be pre-defined (specifically, placed in an OWS Context Document) and registered in a catalogue, which the client engine could then match to the question asked.

Foresight Needed

Currently, questions like the above find the pre-defined OWS Context Docs using simple keyword/pattern matching, but the eventual goal is to be able to take a natural language query and bring in the required geospatial contexts on-demand.

However, not all the data required to answer such a question are ready-and-available via a web service (eg an OGC Web Feature, Coverage, or Map Service) - quite often, several processing and analytical functions need to be performed on existing data.

As such, we need to find a method to bring in disparate Web Processing Services (WPS), and chain them together in a distributable workflow – using a method that honours access permissions, yet still appears seamless to the non-expert end user – so that we can create the data required to answer the question posed. Which brings us to the next outcome of Testbed 13...

Creating a Secure Data Workflow

Using Business Process Model Notation (BPMN), it is now possible to chain together the separate WPS to create a spatial data workflow, and in turn make that workflow available behind another single WPS, which can then be registered (and discovered) in a catalogue.

Of course, each of these WPS sit within different security environments, so Testbed 13 was able to demonstrate a method (using OAuth and OpenID Connect) to mediate a user’s identity and handle all the security aspects on their behalf - making a secure interaction possible without requiring frequent, separate logins. This helps with the ‘shareability’ of the workflow, too, as nobody without the appropriate authority will be able to access any WPS that they shouldn’t be able to, even if they ‘install’ a workflow that uses it.

Apps in the Cloud

Testbed 13 demonstrated a way that an expert user can create a geospatial processing application that can be packaged into a container (Docker, in this case) and registered on a hub. Expert and non-expert users alike can browse the hub for applications suiting their requirements, and then deploy them onto any cloud infrastructure and at any scale.

This involves two components, both of which are WPSs: one is the ‘App Store’, where you register your new app and users can discover it, and the other is the ‘Cloud Engine’ that does the actual deployment and execution of the app in the cloud. The ‘Cloud Engine’ has to be created specifically for the cloud infrastructure that it will be deployed on, after which it is distributable just like an ‘app’.


The idea behind the last outcome is that there are a multitude of users that could benefit from the data generated by ensembles of complex models - such as climate models - but who don’t have the scientific training to know how to interact with the models directly, nor the need to access them at the scales that they cover. The example used during the demo was of a farmer that wants to know how their crop yield will change over the next decade, given different climate change scenarios.

Understanding how the climate will change over the course of time involves using an ensemble of different models to produce a number of different outputs, with different likelihoods of occurence. However, a non-scientist doesn’t have the technical training, nor the desire, to interact with ensembles of forecasting models like this. This user needs to access only a subset of the climate data relevant to their farm, and ingest it into their local GIS to be overlayed with their own data.

As such, this outcome was focussed on using Web Coverage Services (WCS) for efficient subsetting (both spatially and temporally) of large datasets - specifically the optimisation and provisioning of climate change data. This subsetting of data occurs in such a way that the non-scientist can do simple parameterisation (such as different possible rainfall scenarios) even though in the background such a query may require outputs of much more complex models (climate change, seasonal variation, etc) in order to generate the desired result.

Making complex climate data available to non-climate scientists has huge potential impact because it allows geospatial users like political scientists or human geographers to ask questions such as “what will happen to the 6 million people in this area when the climate starts to turn their agricultural lands to desert?” without having to deal with the terabytes of NetCDF or WCS data that climate models produce and rely on.

This article was published in Geomatics World May/June 2018

Last updated: 23/05/2018