OGC Engineering Report

OGC Disaster Pilot: Provider Readiness Guide
Dr Samantha Lavender Editor Andrew Lavender Editor
OGC Engineering Report


Document number:21-074
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

I.  Abstract

The OGC Disaster Pilot 2021 initiative brought differing technologies together through multiple participants, allowing the future development of a robust solution with no single-point weaknesses. This Guide supports data providers in preparing and coordinating with others to leverage standards-based cloud computing platforms to support disaster management and response efforts. Geospatial data is acquired from multiple sources, including Earth Observation satellites, and converted to Decision Ready Information and indicators (DRI) from Analysis Ready Data and datasets (ARD) alongside recipes.

II.  Executive Summary

When a disaster strikes, disaster relief drives the need to quickly integrate and analyze real-time data streams from multiple sources to plan responses and monitor the evolving situation. Scalable cloud-based systems can bring sizable resources, but components need to be linked through pre-agreed standards. The OGC is at the center of the geospatial marketplace that allows the exploration and testing of state-of-the-art technologies. Therefore, it can uncover market capacities and capabilities and serve as an accelerator for market research activity while at the same time demonstrating the integration potential native to OGC Innovation Program activities.

The web-based publication of “structured data” can link well-known content with up-to-the-minute situation observations, enabling search engines to raise the importance of disaster-relevant information in search results and help the public stay aware of fast-moving events.

Application Programming Interfaces (APIs) and download-and-go GeoPackages can bring Decision Ready Information and indicators (DRI) directly to field workers’ mobile devices even in resource-constrained, low-connectivity areas. The generation of DRIs is supported by data transformation and preparation technologies, geospatial standards, and data sharing arrangements that bring the correct information at the right time to the right people in the right place. The inputs include Analysis Ready Data and datasets (ARD), which is data in a format that can immediately be integrated with other geospatial data, and applied to recipes that convert these diverse sources into actionable and decision ready information necessary to support disaster managers and responders in their demanding and time sensitive roles.

Within the OGC Disaster Pilot 2021 (termed Pilot), differing technologies were brought together through multiple participants, allowing the future development of a robust solution with no single-point weaknesses. These community activities become ever more important as the ability of technology to provide disaster responders with invaluable information improves.

This Provider Guide supports data providers in preparing and coordinating with others to leverage standards-based cloud computing and real-time data sharing & collaboration platforms in support of disaster management and response efforts. It showcases what was developed and tested in the Pilot, alongside describing the standards that have been explored and integrated.

III.  Keywords

The following are keywords to be used by search engines and document catalogues.

Disasters, Natural Hazards, Landslides, Health, SDI, Analysis Ready Data, ARD, Decision Ready Information, Flood, Indicators, Emergency Response, Health, Pandemic, ogcdoc, OGC document, DP21, ogcdoc, OGC document, Disaster Pilot, Provider Readiness Guide

IV.  Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

V.  Security considerations

No security considerations have been made for this document.

VI.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VII.  Submitters

All questions regarding this document should be directed to the editor or the contributors:

Name Organization Role
Dr Samantha Lavender Pixalytics Ltd Editor
Andrew Lavender Pixalytics Ltd Editor
Antonio San José Satellogic Editor
Ryan Ahola Natural Resources Canada Contributor
Omar Barrilero European Union Satellite Centre Contributor
Paul Churchyard Contributor
Ignacio Nacho Correas Skymantics Contributor
Theo Goetemann GISMO Contributor
Ajay K Gupta Contributor
Dean Hintz Safe Software Contributor
Amy Jeu GISMO Contributor
Dave Jones StormCenter Communications Contributor
Albert Kettner RSS-Hydro Contributor
Alan Leidner Consultant Contributor
Adrian Luna European Union Satellite Centre Contributor
Niall McCarthy Crust Tech Contributor
Guy Schumann RSS-Hydro Contributor
Marie-Françoise Voidrot Open Geospatial Consortium Contributor
Jiin Wenburns GISMO Contributor
Peng Yue Wuhan University Contributor

OGC Disaster Pilot: Provider Readiness Guide

1.  Scope

This Provider Guide supports data providers in preparing and coordinating with others to leverage standards-based cloud computing and real-time data sharing & collaboration platforms in support of disaster management and response efforts. It showcases what was developed and tested in the Pilot, alongside describing the standards that have been explored and integrated. The Pilot has also produced a User Readiness Guide [1].

2.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

2.1.  Terms and definitions

2.1.1. ARD

Analysis Ready Data and datasets — This is raw data that have had some initial processing created in a format that can be immediately integrated with other information and used within a Geographical Information System (GIS).

2.1.2. CRS

Coordinate Reference System — coordinate system that is related to the real world by a datum term name (source: ISO 19111)

2.1.3. DRI

Decision Ready Information and indicators — ARDs that have undergone further processing to create information and knowledge in a format that provides specific support for actions and decisions that have to be made about the disaster.

2.1.4. Indicator

Indicator —  An indicator is a realistic and measurable criteria.

2.1.5. Lidar

Light detection and ranging — a common method for acquiring point clouds through aerial, terrestrial, and mobile acquisition methods.

2.1.6. GeoNode

GeoNode — a web-based platform for deploying a GIS.

2.1.7. GeoPackage

GeoPackage — an open, standards-based, compact format for transferring geospatial information.

2.1.8. GeoRSS

GeoRSS — designed as a lightweight, community driven way to extend existing RSS feeds with simple geographic information.

2.1.9. GeoServer

GeoServer — a Java-based server that allows users to view and edit geospatial data. Using open standards set forth by the Open Geospatial Consortium (OGC), GeoServer allows for great flexibility in map creation and data sharing.

2.1.10. JSON-LD

JavaScript Object Notation — Linked Data — a lightweight linked data format based on JSON.

2.1.11. Jupyter Notebooks

Jupyter Notebooks — an open-source web application that allows the creation and sharing of documents that contain live code, equations, visualizations and narrative text.

2.1.12. Radar

Radio detection and ranging — a detection system that uses radio waves to determine the distance (range), angle, or velocity of objects.

2.1.13. REST API

REST API — is a Representational State Transfer Application Programming Interface more commonly known as REST API web service. When a RESTful API is called, the server will transfer a representation of the requested resource’s state to the client system.

2.1.14. SAR

Synthetic Aperture Radar — a type of active data collection where a sensor produces its own energy and then records the amount of that energy reflected back after interacting with the Earth.

2.2.  Abbreviated terms


Amplitude Change Detection


Application Programming Interface


Cloud Optimized GeoTIFF


National Commission for Aerospace Research and Development’s, Peru


Emergency Geomatics Service


El Niño/Southern Oscillation


Earth Observation


Earth Observation Data Management System


Earth Science Information Partners


Extract, Transform and Load


Feature Manipulation Engine (Safe Software)


Geospatial Information System


New York City Geospatial Information System & Mapping Organization


High Resolution Data




JavaScript Object Notation


JavaScript Object Notation — Linked Data


Low Earth Orbit


Multi-Temporal and Coherence


New AstroSat Optical Modular Instrument




National Oceanic and Atmospheric Administration, US


Natural Resources Canada’s




Operational Land Imager


Operational Readiness Levels




RADARSAT Constellation Mission


Spatial Data Infrastructure


Shuttle Radar Topography Mission


Sea Surface Temperature


SpatioTemporal Asset Catalog


Amazon Simple Storage Service


Thermal Infrared Sensor


Volunteered Geographic Information


Web Coverage Service


Web Feature Service


Well-Known Text


Web Map Tile Service

3.  Introduction

The OGC Disaster Pilot 2021 (abbreviated to the “Pilot”) aimed to further improve the ability of key decision-makers and responders to discover, manage, access, qualify, share, and exploit location-based information in support of disaster preparedness and response and multi-hazard risk analysis. Within it, the following key components of a geospatial information flow for disaster management operations were considered:

3.1.  Geospatial Data

Geospatial data can be defined as data that describes objects, events, or features using a location on the Earth’s surface, and the simplest form of presenting such information is on a map. Whilst the earliest maps began with the Babalyonians and Greeks in the 6th Century BC; the use of geospatial data in disasters is a bit more recent. Arguably, one of the first uses was in 1854 when Dr. John Snow mapped, by hand, the deaths from a cholera outbreak in London. Earth Observation (EO) started around the same time as Dr. Snow’s map when Gaspard-Felix Tournachon took photographs of Paris from his balloon in 1858. However, it was a century later with the launch of the Explorer VII satellite in 1959 and TIROS 1 weather satellite in 1960 that satellites were used to make observations of the Earth.

The game-changer, which started the industry, was the launch of NASA’s Earth Resources Technology Satellite in 1972: The first real mapping satellite. It was later renamed to Landsat-1 beginning what has developed, to date, into an almost fifty-year archive of satellite observations of the planet. Other space agencies around the world have also launched EO missions including the European Space Agency (ESA) who are involved with the European Union’s Copernicus program, and the Japanese Space Agency (JAXA) that have the National Security Disaster ALOS-3 optical and ALOS-4 microwave missions, and the Canadian Space Agency (CSA) whose RADARSAT series of satellites support disaster monitoring activities.

Satellite remote sensing in disaster management situations took a step forward with the signing of the International Charter: Space and Major Disasters on 22 October 2000 by ESA, the French Space Agency (CNES), and the Canadian Space Agency. Currently, there are 17 contributing members including the US Geological Survey (USGS) and the National Oceanic & Atmospheric Administration (NOAA). This charter is triggered when a disaster situation occurs and makes satellite data available from different space agencies around the world, providing access to a wide range of data by the teams responding and managing the specific disaster. Since its inception, the Charter has been activated for 692 disasters in 127 countries, and during 2020 it was activated 55 times in 33 countries.

Together, satellites and geospatial technologies such as Geospatial Information System (GIS) offer the potential to provide disaster responders with invaluable information. This information can be used to support both the planning and the implementation of the response, through maps and information, directly to the field responders on the ground, an awareness of the current situation. Therefore, providing access to these technologies allows saving lives and helping people respond to disaster events. Unfortunately, whilst the idea is great in principle, several practical issues can prevent these resources’ best use.

4.  Overview

5.  Use of Geospatial Information in Disaster Response

5.1.  Historic use

The application of satellite remote sensing to disaster management support under an international framework began around 2000 when satellite-based Earth Observations (EO) for rapidly assessing disaster situations globally (namely, response support) were started by the International Charter Space and Major Disasters. After 4 years of operations, user feedback was collated (Ito, 2005) and shortcomings highlighted:

  • The average response time was reported as always being better than five days but not seen as being sufficient for real-time monitoring.

  • Even with an integrated EO system, users still could not have access to the data when they wanted it; a combination of Charter activation and insufficient EO systems made real-time monitoring of each disaster not a reality.

  • The data acquired were not always useful as availability was limited by meteorological and geographical factors.

The Emergency Management Service (EMS) of the Copernicus Program is an operational service; there was a precursor R&D activity and it started operationally in April 2012. As reported by Denis (2016) for activations between June 2011 and March 2015, the time from activation to first delivery was around 9.5 hours for data from an archive and 6.5 hours (55% within 3 hours) for a new acquisition. For the Charter, the paper reported delivery for the first crisis image being 1.3 days in 2014, and so this was a reduction on that previously reported by Ito(2005).

JAXA conducted a user survey (Kaku, 2019) after the 2011 Great East Japan Earthquake, between August 2011 and March 2012, and the conclusions included:

  • Numerous general users requested the establishment of a framework to supply satellite images free of charge and quickly in an emergency, which needed to include data providers (space agencies), data analysts (universities, research institutes, etc.), and users (disaster management organizations).

  • Users wanted the data to cover the entire disaster management cycle (preparedness, response, and recovery).

  • International collaboration was seen as essential for disaster management support, particularly in the case of catastrophic disasters.

  • Feedback from users on each disaster event was seen as valuable to data providers; whether it went well or not.

Also, a review from the 2011 US Midwestern Floods (Sivanpillai et al., 2017), supported through the Charter, concluded:

  • To increase the chances of obtaining cloud-free or partially clouded multispectral images, the Charter should request its members to task as many satellites as possible for regions prone to high cloud cover.

  • It was important to optimize the acquisition plans to meet the data needs specific for that activation, e.g. temporally spread acquisitions from multiple missions where a limited number of acquisitions can occur for each mission.

  • The required availability of archived (pre-event) data for interpreting both optical and post-flood Radar imagery. However, it was noted a change in the image can appear different depending on when the pre-flood imagery was acquired, i.e. normal, wet or drought year. Hence, it can be important to use more than one pre-flood image to obtain the average conditions.

  • Emergency management agencies fed back that value-added products such as classified (i.e., thematic) images, were useful and integrated quickly into the decision-making process.

5.2.  Challenges

In summary, this brief review of the use of primarily EO data for disaster response has identified the following challenges that are still considered relevant at the time of this guide:

  • The area impacted by an event, or within which the rescue teams operate, varies considerably from a few square kilometers for local events (landslides, earthquakes, etc.) to thousands of square kilometers for very large area events such as tsunamis, tropical storms, and floods in low-lying areas. Therefore, targeted acquisitions and data availability need to consider the specific disaster event.

  • Delivery of the first crisis product within 24 hours remains a challenging objective, due to the characteristics of the satellites, their orbits, and “true operational revisit” that for optical data would include the impact of cloud cover. However, the increasing focus on launching Radar constellations can provide increasing support alongside geostationary missions where there is not persistent cloud cover.

  • As more countries gain their own EO capability, commercialization is a common theme. Open-access models for lower spatial resolution data have globally gained support through organizations such as the Group on Earth Observations (GEO). As an example, from the start, Copernicus has provided free-to-access optical and Radar data worldwide, with the number of users increasing exponentially. Also, for disaster response, commercial entities will often supply data for free or at a reduced cost through “special arrangements”. However, in order to ensure that end-users receive the maximum benefits, and those data providers are able to distribute and control data in a more efficient and effective manner, there is a need for the harmonization of data license standards (Clark, 2017).

6.  What Is Readiness?

Readiness is the state of being fully prepared, and in this case, it is the state of being fully prepared to take part in the vision of a disaster response ecosystem as defined and demonstrated through the OGC Disaster Pilot 21 (Pilot).

The aim is to improve the amount and speed of data-driven decisions during the disaster response. This means that once activated, the geospatial data providers within this ecosystem will make a large amount of geospatial data available. However, to make it useful and decision-ready these datasets need to be available, processed, analyzed, visualized, and communicated to field responders in a very short amount of time.

This is not something that can be begun when a disaster occurs from either a data provider or user’s point of view. There will be too many things to resolve such as data formats, license agreements, geospatial systems used, analysis skills, data aggregation and transformation methods, symbols and colors to be used in the visualization, and so on. By the time these are resolved, the disaster situation will be well underway and responses will be happening without the required geospatial data.

To be part of the envisaged Pilot ecosystem, both data providers and users need to be prepared to take part, and this means making a series of agreements. However, this can’t be a set of agreements between individual data providers and users, nor can it be one single solution that everyone has to fit within. Instead, it requires a set of agreed operating approaches and standards such that, for example, the data providers know the format they need to provide the data in and users can immediately integrate that data within the system they are operating. Therefore, these standards will be what will deliver information smoothly and rapidly to enable decisions to be made and actions to be taken. Also, Readiness often means the solution is operational.

Although not developed within this Pilot, one suggestion is to develop a series of Operational Readiness Levels (ORLs), similar to those developed Earth Science Information Partners (ESIP) for making Earth science data more trusted, which will identify the steps and operating standards that both data providers and users will need to take to be able to fully participate.

This next section focuses on provider readiness and the required steps. There is a companion User Guide, which is ‘technology-lite’ and focuses on the user’s perspective.

7.  What Is Provider Readiness?

This guide is for the providers of the raw data, Analysis Ready Data (ARD) and/or Decision Ready Information and indicators (DRI) to ensure maximum usefulness for the users. This section describes the steps that providers should complete to be in a position to fully participate in the Disaster Response ecosystem envisaged by the OGC Disaster Pilot 2021 (Pilot):

7.1.  Step 1: Understand what the users need

This is a two-way conversation as it will be difficult for a user to express their needs if they don’t understand what is possible. Also, to have “user confidence” it is likely this communication needs to be an ongoing process of collaboration to seek the best overall disaster ecosystem effectiveness and performance.

One role for the users is to develop, and maintain, the foundation layers of local geospatial information into which the data from the providers can be integrated. This would include elements such as street maps, building footprints, elevation models, satellite imagery, key buildings such as hospitals, electricity substations, land cover, water bodies, etc.

7.2.  Step 2: Understand and Implement Standards

To be able to rapidly integrate and transform data into useful DRI, it’s necessary to eliminate all the unnecessary challenges of data management. This will include aspects of data formatting, visualization methods, symbols to use on maps, etc. This is critical to cut the time it takes for data to be ready to be used for decisions and actions.

Without standards, the potential for wasted time on data wrangling and preparation is high, and even worse the potential for inefficient, incorrect, or even wrong disaster response decisions the increases.

Within the Pilot, a number of key standards were identified as being important for provider readiness:

  • Publishing structured geospatial data to support web-based searching, e.g. JavaScript Object Notation — Linked Data (JSON-LD)

  • Transition of imagery to formats that support cloud-native geospatial processing, e.g. Cloud Optimized GeoTIFF (COG)

  • Generation of metadata catalogs and self-describing datasets to aid data access and processing, e.g. SpatioTemporal Asset Catalog (STAC) and GeoPackage

  • Platforms to serve the geospatial data and visualize it, e.g. GeoServer and GeoNode, with transmission standards such as Web Coverage Service (WCS), Web Feature Service (WFS), and Web Map Tile Service (WMTS)

7.3.  Step 3: Develop Recipes to support data flow from source through ARD to DRI

Once the user needs and basic understanding of intended standards support are understood, the core of building an operational disaster support system is to develop recipes to support the data value chain. These recipes describe how to extract data from key sources in ARD and then transform these into information — DRI’s — suitable for supporting decision support indicators that responders need to inform their actions and optimize their effectiveness.

A number of tools can be used to implement these recipes in a way that are readily interchangeable and reusable in different contexts. One approach is the use of open-source web-based scripted tools like Jupyter Notebooks, often involving Python and other languages such as Java or R. Another approach explored is to use model-based spatial Extract, Transform and Load (ETL) tools to support data integration and automation. Either approach can support rapid recipe development to generate the data products necessary to support disaster responders, and examples of both approaches were tested in the context of this disaster pilot.

An example of working through the process of understanding what is needed are the discussions within the ARD and DRI working groups, with the OpenStreetMap (OSM) conversion undertaken by Safe Software using FME:

  • Areas of interest extents or polygons were shared in GeoJSON format. This allowed everyone to be sure they were talking about the same geographical extent.

  • Basemap data was extracted from OSM and shared via a GeoPackage as foundation layers were not available from users at the start of the Pilot. Although this may sound like a trivial exercise, it was not because:

    • There is an interpretation process when extracting information from OSM and ‘flattening’ it for use in GIS.

    • A further complexity was that the original OSM data uses geodetic coordinates and EPSG:4326 as the defined Coordinate Reference System (CRS), where Latitude is specified before Longitude, while a GeoPackage defines co-ordinates according to the OGC Well-Known Text (WKT) standard of x,y,z,t that will override any CRS axis order.

7.4.  Step 4: Determine The Method For Delivering Outputs

Receiving a large amount of data, and then analyzing, processing, and visualizing the data is only the first half of the work. The second half is getting the outputs of that work to the people managing the disaster response, including the field responders on the ground via their mobile phones or similar devices.

There are a variety of solutions for this and the Pilot is not recommending one, nor is it suggesting that the solution would be based around a single technology. Instead by establishing a set of required standards for data sharing, it will enable data to be interoperable and reusable across any platform. Solutions could be provided open source, commercial, or even using existing internal infrastructure.

The key element is that the user organization has a solution where they can upload the decision-ready indicators for users to access.

There is no single answer and the preferred solution will depend on the organization’s infrastructure, financial pressures, technical skills, etc. Within the Pilot, several external platforms were tested, including:

  • Geocolloborate – a platform developed by StormCenter Communications under the U.S. Federal SBIR program, which offers an option for an expert to lead the analysis and sharing of trusted data, with a series of followers receiving the data in real-time on the same screen. This approach offers the potential for a lot of people to interact with the same information at the same time leading to collaborative decision-making with the latest data available, some of which could be updated in real-time.

  • GeoNode Platform – GeoNode, developed by GeoSolutions, is a web-based application and GIS platform for displaying spatial information. A GeoNode controlled by has been used to display various data layers that were then accessible using open standards.

If an external platform is chosen, it is important to ensure that it can comply and adhere to the Standards highlighted in Step 2. In addition, it will be necessary to ensure that:

  • Licenses have been agreed with the external provider for the use of the platform, including sufficient licenses are available for everyone who might need access to data during a disaster.

  • All possible users have and know any username and passwords required to access the external system. In addition, this could also include additional security to allow only certain users to see specific datasets — this approach was tested through encrypted GeoPackages.

  • All possible users have received training in the use of the system for disasters.

It is acknowledged that similar points will be relevant to in-house solutions.

The key element is that the chosen platform itself should support the data standards which will be used by the data providers to ensure that the indicator and data sets will be portable between platforms.

7.5.  Step 5: Operationalize The Disaster Response

Simply setting up a disaster response system is not sufficient, as everyone involved needs to understand what sort of decisions will need to be taken. In summary, what information, indicators or triggers the disaster response team will want.

Whilst the data provider can provide a lot of relevant, useful, and helpful information, it will be important to understand the indicators that are most relevant for a disaster. It will also require local knowledge and understanding to interpret the indicators and take decisions and actions. For example, if a flood is occurring, then some of the indicators required might include area impacted, water depth, speed of water rise, potential future areas impacted, land cover, location of hospitals, safe evacuation, and access routes, etc. Within the Case Studies, in the annexes to this Guide, the Pilot showcases three potential disaster scenarios with examples of the type of indicators that might be relevant for those situations.

Users need to consider the indicators and determine whether they are sufficient, or whether important indicators are missing, any key local issues that need to be addressed, etc. Whilst generic indicators will be common across disaster types and regions, it is still possible that specific locations will need additional indicators or data.

Finally, it will be important for the users of the indicators to understand what their impact will be, what specific decision trees will be enacted when an indicator reaches a certain level, for example, in a flood at what point is an evacuation order issued. This will be necessary to give the decision-makers confidence in data-driven decisions and knowing how they should respond.

7.6.  Step 6: Test

As with all disaster, resilience, or business continuity plans, preparing and developing the documents is not enough. The approach needs to be tested to practice the process of generating and receiving analysis-ready datasets, using/developing the decision-ready indicators, making decisions, initiating actions, and communicating those actions to people on the ground.

Geospatial data use should be incorporated into large-scale disaster response test events. However, it is acknowledged that large scale test events are complex and occur infrequently, therefore it would also be beneficial to work with some data providers to undertake small tabletop ‘data only’ tests for both providers and users to practice triggering, receiving, analyzing, and visualizing data and indicators.

8.  Proposed Approach & Methodology

The idealized overall solution envisaged by the OGC Disaster Pilot (Pilot) is that when a disaster event occurs, the user will log onto the Disaster Portal via either a computer or mobile, and search for the information that they want or need from the latest datasets that are available.

This best available data of the type requested will be provided to the user in the most useful or selected, format. This might be:

Whilst this is the idealized solution, practically there is a long way to go to have this solution available to everyone across the world.

Therefore, the Pilot is starting the process of developing an operational prototype to demonstrate how this might work with three hazards in selected areas, to better understand what is possible, where the challenges are and how to take this forward.

8.1.  Users & Data

8.1.1.  Types of users

The Pilot has identified four user groups:

  1. Data Analysts working for the responding organizations providing insights and information for the disaster planners or field responders. These may include data analysts, GIS analysts, and logisticians.

  2. Disaster Response Planners or Managers who lead the disaster readiness and response activities for the responding organizations.

  3. Field Responders who are on the ground responding to the disaster and reporting to the responding organizations.

  4. Affected public and communities who want direction and guidance on what they should do.

Each of these user groups requires different types of data or information, at different levels and presented in different ways.

8.1.2.  ARD vs DRI data

The Pilot envisages two main types of data/information being produced and supplied to the users:

  • Analysis Ready Data (ARD): This data is observations about what is happening in a format that can be immediately integrated with other geoinformation and used within a Geospatial Information System (GIS). These datasets can be interrogated by people with the right skills to gain greater insight, having already undergone some processing to remove errors, get the data in the right format, etc. It includes satellite data, together with in-situ data and data from other sources, and would be supplied as a dataset. It is most likely to be used by the Data Analysts but could also be used by Disaster Response Planners and Managers.

  • Decision Ready Information/Indicators (DRI) – These are ARDs that have undergone further processing to create information and knowledge in a format that provides specific support for actions and decisions to be made in relation to the disaster. This information will be useful for Disaster Response Planners and Managers, Field Responders and Affected Public, and will be able to be used without any specialist knowledge, skills or software. DRI datasets may also be useful to Data Analysts in order to build composite or multi-stage indicators.

Note that although these are the two main types of data envisioned here, throughout the course of the pilot there were discussions around what stages of data might exist between ARD and DRI. For example, some datasets may be considered to be actionable observations: more refined and richer than basic ARD, but without the clearly defined rules or parameters as to what action should be taken, that would be necessary to consider them DRI. In support, a diagram was developed to show the relationship between ARD to DRI; see Figure 1.


Figure 1 — Relationship between ARD to DRI, courtesy of Josh Lieberman.

8.1.3.  Recipes and Indicators

Although recipes and indicators vary from disaster to disaster, they can be set up within a structure that includes their applicability timescale (short-term predictions and impacts to medium and long-term predictions) and type/geospatial extent of the disaster.

Example recipes include those related to:

  • Predicting future flooding: Using Earth Observation (EO) and modeled data to provide the current ocean state and weather conditions in support of predicting the onset of flooding due to heavy rainfall; see Annex A for further details.

  • The blockage of roads by floodwater: EO and modeling data is used to extract/predict the floodwater extent, and then used to determine which and to what depth roads are affected, which is then used to influence the routing of traffic; see Annex B for further details.

  • Availability of health supplies: Use of geospatial health data to predict a Pandemic Mortality Risk Index and Medical Supply Needs Index; see Annex C for further details.

9.  Technical Solution

9.1.  Proposed technical solution – data, cloud, processing, registry, visualization and serving to users

The OGC Disaster Pilot (Pilot) technical solution aimed to bring together multiple providers into an ecosystem that transforms input data into actionable information by developing prototypical components and services. These components should utilize modern cloud architectures and next-generation technologies to optimize collaborative workflows and scale solutions rapidly. An overview of the architecture envisioned for the Pilot is shown in Figure 2.


Figure 2 — Pilot Architecture Overview

At the top of Figure 2 are the data sources, which include Earth Observation (EO) and social-political-economic data alongside ancillary geospatial sources. The sources of data were seen as both being free-to-access and paid-for, and the availability could be restricted depending on the source and sensitivity of the data.

Sources consider or used within the Pilot include:

  • Satellite Earth Observation:

    • Copernicus Sentinel Missions: Operated by the European Union, with data acquired by constellations of global missions focused on specific technologies. For example, Copernicus Sentinel-1 are two Radar missions (A&B) that operate at the C-band frequency.

    • Landsat-8: A high resolution (30 m spatial resolution) mission that carries the Operational Land Imager (OLI) and the Thermal Infrared Sensor (TIRS) instruments. Landsat 9 is the most recently launched Landsat satellite, but was not launched in time for the Pilot.

    • NewSat: Satellogic constellation currently consists of 17 commercial NewSat satellites in sun-synchronous Low Earth Orbit (LEO).

    • PeruSat-1: National Commission for Aerospace Research and Development’s (CONIDA) small (~ 430 kg) satellite launched in September 2016, which carries NAOMI (New AstroSat Optical Modular Instrument) that has a panchromatic and four multispectral wavebands: Blue, green red, and Near-InfraRed (NIR). The panchromatic band has a spatial resolution of 0.7 at nadir, while the multispectral bands have a spatial resolution of 2.5 m at nadir.

    • RADARSAT: The three RCM (RADARSAT Constellation Mission) satellites operate at the C-band frequency, with a spatial resolution from 1 to 100 m depending on the acquisition mode.

  • Health data:

    • Tracking:

      • Locations of interest e.g., specific and black markets.

      • Large gatherings

      • People and items going into and out of any facility to access disease spread risk.

      • Land Use Change e.g., change in air quality, coastline, the water table, access to water, deforestation, animal, insect, human habitats, and many others.

      • Migration of Animals and Insects

    • Measuring:

      • Point-in-time population density

    • Monitoring and monitoring:

      • Evacuation routes, and development of alternate evac routes

      • Health resource utilization within a medical facility

      • Volume of traffic at discrete points in transportation infrastructure, e.g. bridges, key intersections, train/light rail stations, etc.

    • Assess distance, travel time between population centers & medical facilities (based on traffic, land cover, storm, etc.)

  • Social-political-economic:

    • Administrative boundaries

  • Ancillary geospatial:

    • OpenStreetMap (OSM): Buildings and road network.

    • Meteorological Data: For example, storm tracking alongside information on weather conditions such as precipitation and wind speed.

    • Digital Elevation Model (DEM): Shuttle Radar Topography Mission (SRTM) @ 30 m spatial resolution provides global coverage, and several enhanced DEM versions thereof (e.g., while airborne Lidar data can provide sub-meter resolution locally.

    • Other in situ observations such as stream gauge data.

The input data, ideally in an Analysis Ready Data (ARD) format, is ingested into cloud-based storage areas from where it can be transformed into Decision-Ready Information and indicators (DRI).

Users interact through Mobile and Web/Desktop Applications (Apps), shown in the boxes at the bottom, which are interacting with the DRI through a Registry & Search Catalog and GeoPackages. In addition, users provide Volunteered Geographic Information (VGI) into the overall ecosystem to support real-time insights into what is happening.

9.2.  Principles/Standards

The principles/standards for each of the elements from discovery to visualization included:

  • Discovery: Service(s) and associated application(s) supporting near-real-time registration, search, and discovery of ARD sources and DRI products, alongside contextual social-political-health datasets and local observations within impacted areas. This element includes implementations of OGC API Standards that provide such information with JavaScript Object Notation — Linked Data (JSON-LD).

  • Data Storage and Processing in the Cloud: Cloud-based storage, processing, and service elements to support the loading, preparation, and access to individual satellite-based datasets alongside complementary geospatial datasets. Then, further application elements are deployed near to source datasets and support agile, rapid, and scalable generation of decision-ready (e.g. indicator) information products.

    • Registry and Search Catalog generation has utilized SpatioTemporal Asset Catalog (STAC);

    • Processing has utilized Jupyter Notebooks;

    • Storage formats included Cloud Optimized GeoTIFF (COG) and GeoPackage.

    • Storage locations such as Amazon Simple Storage Service (S3).

  • Visualization:

    • Mobile client applications able to discover, request, and download DRI products as GeoPackages in support of disaster response field personnel, operations, and decision making during connected-disconnected operations.

    • Web/desktop client applications able to interact with cloud-based server components to access both ARD and DRI products for analysis and visualization by analysts and decision-makers.

    • Delivery standards for these clients include GeoRSS, Web Coverage Service (WCS), Web Feature Service (WFS), and Web Map Tile Service (WMTS).

Having these pre-agreed and understood in advance can ensure consistency and an efficient processing/delivery of the needed disaster-related information.

10.  Outcome and Results

The OGC Disaster Pilot (Pilot) focused on bringing scenarios together through multiple participants working together rather than a single participant providing the whole solution. Therefore, a significant amount of time was spent discussing different approaches and collaboratively working on the scenarios. Also, there have been difficulties in quickly bringing on-board the required cloud resources and hence making the underlying cloud infrastructure available to all participants.

The example scenarios highlighted in the annex located case studies showcase how multiple participants, and technologies, contributed to an initial assessment of:

These Case Studies start by providing the context and then describe what the Pilot has achieved.

10.1.  Provider Success and Achievements

The successes at this relatively early stage of development include:

  • Recipes developed to go from Analysis Ready Data (ARD) to Decision Ready Information and indicators (DRI) for:

    • prediction of El Niño related flooding (Annex A);

    • analysis of flooding scenarios based on historic, real time or forecast stream gauge data (Annex B)

    • traffic routing around flooding (Annex B);

    • health supplies availability (Annex C).

  • Supply of user gathered survey results via an RSS feed using GeoRSS (Annex A);

  • Integration of ARD and DRI outputs into a Medical Supply Needs Index that’s hosted within a GeoNode platform (Annex C);

11.  Next Steps Recommendations

11.1.  What needs to be done to make this available in real-time for disaster support?

At present, the Pilot has started the process of bringing providers together. The Case Studies focused on historical data rather than real-time support, which meant more data and information was available. Therefore, further work needs to be taken to improve the technical setup, e.g., APIs or other computer-to-computer interfaces need to be set up rather than manually transferring data from one provider to another. This approach was being accomplished towards the end of the Pilot and further work for the ecosystem of providers to function smoothly and handle near-real-time data.

Then, as discussed in Clause 7 large scale disaster response test events need to be conducted to stress-test the setup and see where the points of weakness are.

11.2.  Technical requirements

In terms of an extension of the Pilot:

  • Having the required cloud-computing infrastructure and input datasets available at the start, or within a short period of time, so this element does not slow down the collaborative activities.

  • Agreeing a minimum viable product that the end-users wish to see so that the minimum specifications or any component can then be formulated.

  • Agreeing on metadata to consistently describe the datasets and recipes.

More broadly:

  • Communities work to establish clear indicators to ensure the responsive data, products and services are mobilized in advance of an event. The landslide community has established ISO standards to support this. The flood, health, fire etc. should consider doing the same.

  • Data sharing agreements are in place in advance to support user readiness.

  • Governments support the FAIR principles to improve user readiness

  • Additional investments be made by governments in capacity development activities that support knowledge and technical transfer to improve user readiness

  • Community work together to develop ARD standards that support interoperability and bring together in-situ and remote sensing data.

11.3.  Going beyond the applications to an international approach

  • The developed recipes need testing for a large range of examples, and further recipes need development.

  • Consider how observations and predictions can be brought together to form time consistent datasets.

  • Preparing for Readiness:

    • Establishing data sharing agreements between the Providers and Users, including the concept of any liability, onward sharing, and use. This is a critical issue and proved a difficulty even within the Pilot.

    • Establishing a set of Operational Readiness Levels for both Providers and Users, so that they can demonstrate to each other that they are ready to participate in the disaster response ecosystem.

    • Refining the roles required both on the Provider and User side, together with the skill set those people require.

    • Practice! A disaster scenario should not be the first time data is shared. Provider data handlers need to practice responding quickly to receiving data requests to find the correct data, process and supply it. User data handlers need to practice receiving datasets integrating, visualizing, and disseminating it.

    • Improved engagement with the disaster response decision-makers and field responders, which is something the Pilot struggled with, to understand the information they believe they want and need.

Annex A
Case Study 1: Rimac and Piura rivers

A.1.  Landslide/flooding hazards and pandemic impacts within the Rimac and Piura river basins in Peru

A.1.1.  Rimac and Piura river basin flooding hazards, including the 2021 flood

Peru’s Piura region in the north and the Rimac river basin near Lima are both impacted by difficult to predict El Niño related flooding. The El Niño/Southern Oscillation (ENSO) is a naturally occurring phenomenon in the tropical Pacific coupled ocean-atmosphere system that alternates between warm and cold phases called El Nino and La Nina, respectively.

The Piura climate is arid but can experience very heavy rainfall associated with the high nearby Sea Surface Temperature (SST) during El Niño phases. When heavy rain occurs it can cause severe floods, which in turn can cause mudslides called huaycos.

Figure A.1 shows an index that indicates the El Niño phases in red and La Nina phases in blue.