I. Abstract
Disasters are geographic events and, therefore, geospatial information, tools, and applications have the potential to support the management of, and response to, disaster scenarios to save lives and limit damage.
The use of geospatial data varies significantly across disaster and emergency communities, making the exploitation of geospatial information across a community more difficult. The issue is particularly noticeable when sharing between different organizations involved in disaster response.
This difficulty can be mitigated by establishing the right processes to enable data to be shared smoothly and efficiently within a disaster and emergency community. To do this requires the right partnerships, policies, standards, architecture, and technologies to be in place before the disaster strikes. Having such a set-up will enable the technological and human capabilities to quickly find, access, share, integrate, and visualize a range of actionable geospatial information, and provide this rapidly to disaster response managers and first responders.
For over 20 years, the Open Geospatial Consortium (OGC) has been working on the challenges of information sharing for emergency and disaster planning, management, and response. In Disaster Pilot 23 (DP23) the aims were to:
develop flexible, scalable, timely and resilient information data workflows to support critical disaster management decisions, enabling stakeholder collaboration; and
provide applications and visualization tools to promote the wider understanding of how geospatial data can support emergency and disaster communities.
The Disaster Pilot Provider Guide describes the technical requirements, data structures, and operational standards required to implement the data flows or tools developed in DP23 and Disaster Pilot 21 (DP21) where participants have worked on disaster scenarios relating to the following.
Droughts
Wildland Fires
Flooding
Landslides
Health & Earth Observation Data for Pandemic Response
Case Studies have focused on the hazards of drought in Manitoba, Canada; wildland fires in the western United States; flooding in the Red River basin, Canada; landslides and flooding in Peru; and pandemic response in Louisiana, United States. The participants have developed a series of data specific workflows to generate either Analysis Ready Datasets (ARD) or Decision Ready Indicators (DRI) alongside a number of tools and applications to support data discovery, collection, or visualization.
Annex A describes the tools and applications developed within the Pilots along with technical details and the benefits offered similar to the data flows. The Guide finishes with details of future possibilities and where the Disaster Pilot initiatives could focus next. Annexes B to E give descriptions of the data flows developed, including technical details of input data, processing and transformations undertaken, standards applied, and outputs produced with details of the aspect of disaster management or response supported, benefits offered, and the type of decisions assisted with.
The Provider Guide is one of three Guides produced within DP23 together with the User Guide and the Operational Capacity Guide. While the Guides are separate individual documents, the Provider and User Guides work together, mirroring each other in terms of structure. The Operational Capacity Guide is a stand-alone document effectively underpinning the other two.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
Disasters, Natural Hazards, Analysis Ready Data, ARD, Decision Ready Indicators, DRI, Drought, Wildland Fire, Flooding, Landslides, Pandemic, Emergency Response, geospatial, ogcdoc, OGC document, DP23, DP21, Disaster Pilot, Provider Readiness Guide
III. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Pixalytics Ltd
IV. Submitters
All questions regarding this document should be directed to the editors or the contributors.
| Name | Organization | Role |
|---|---|---|
| Andrew Lavender | Pixalytics Ltd | Editor |
| Sam Lavender | Pixalytics Ltd | Editor |
| Ryan Ahola | Natural Resources Canada | Contributor |
| Stefano Bagli | GECOsistema | Contributor |
| Omar Barrilero | European Union Satellite Centre | Contributor |
| Dave Borges | NASA | Contributor |
| Harrison Cho | USGS-GeoPathways | Contributor |
| Paul Churchyard | HSR.health | Contributor |
| Rhett Collier | Duality | Contributor |
| Antonio Correas | Skymantics | Contributor |
| Katharina Demmich | 52 North | Contributor |
| Patrick Dion | Ecere | Contributor |
| Rich Frazier | USGS-GeoPathways | Contributor |
| Theo Goetemann | Basil Labs | Contributor |
| Ajay K Gupta | HSR.health | Contributor |
| Omar Heriba | USGS-GeoPathways | Contributor |
| Dean Hintz | Safe Software | Contributor |
| Josh Hussey | Compusult Limited | Contributor |
| Jérôme Jacovella-St-Louis | Ecere | Contributor |
| Amy Jeu | Geospatial Information Systems and Mapping Organization | Contributor |
| Dave Jones | StormCenter Communications | Contributor |
| Brennan Jordan | USGS-GeoPathways | Contributor |
| Travis Kehler | Duality | Contributor |
| Albert Kettner | RSS-Hydro | Contributor |
| Alan Leidner | Geospatial Information Systems and Mapping Organization | Contributor |
| Adrian Luna | European Union Satellite Centre | Contributor |
| Jason MacDonald | Compusult Limited | Contributor |
| Niall McCarthy | Crust Tech | Contributor |
| Vaishnavi Raghavajosyula | USGS-GeoPathways | Contributor |
| Carl Reed | Carl Reed and Associates | Contributor |
| Sara Sadri | UN University | Contributor |
| Johannes Schnell | 52 North | Contributor |
| Guy Schumann | RSS-Hydro | Contributor |
| Sumit Sen | IIT Bombay | Contributor |
| Sunil Shah | Duality | Contributor |
| Harsha Somaya | USGS-GeoPathways | Contributor |
| John Christian Swanson | USGS-GeoPathways | Contributor |
| Ian Tobia | USGS-GeoPathways | Contributor |
| Marie-Françoise Voidrot | Open Geospatial Consortium | Contributor |
| Jiin Wenburns | GISMO | Contributor |
| Colin Withers | Compusult Limited | Contributor |
| Peng Yue | Wuhan University | Contributor |
1. Introduction
Disasters are geographic events in specific locations that impact the people, economy, and society in those and surrounding areas — often tens, or even hundreds, of miles away. For this reason, geospatial information has been shown to be effective in supporting both the understanding of, and the response to, disaster scenarios.
Geospatial tools and applications have the potential to save lives and limit damage, and the world is becoming better at using these resources. Unfortunately, the ability to manage, access, share, use, reuse, and exploit geospatial information and applications is often limited. This can be, in particular, between organizations as the right processes have not been established for these processes to happen smoothly and efficiently within disaster and emergency communities. Establishing such processes requires partnerships, policies, standards, architecture, and technologies to be in place before the disaster strikes.
For over 20 years the Open Geospatial Consortium (OGC) has been working on the challenges of information sharing for emergency and disaster planning, management, and response. The Disaster Pilot activities are part of the OGC Collaborative Solutions and Innovation Program (COSI) with the aim to address the gap, and provide support and guidance on how disasters and emergency communities can enhance sharing and use of geospatial information and applications.
Disaster Pilot 23 (DP23) is the latest in a series of initiatives focussed on:
developing flexible, scalable, timely, and resilient information workflows to support critical disaster management decisions enabling stakeholder collaboration; and
providing applications and visualization tools to promote the wider understanding of how geospatial data can support emergency and disaster communities.
This Provider Guide aims to provide data collectors, processors, and publishers with detailed technical requirements, data structures, and operational standards required to develop and offer data workflows and tools within the ecosystem of the OGC Disaster Pilot initiatives. The Guide also supports in the preparation and coordination needed to leverage standards-based cloud computing and real-time data sharing and collaboration platforms in support of disaster management and response efforts.
In addition, the Provider Guide gives emergency management, together with any other supporting stakeholders, information technology support functions and technical details to understand how to implement any of the workflows or tools developed in disaster and emergency user communities.
Geospatial information offers huge potential resources to enable disaster and emergency communities to enhance planning, prediction, and response to disaster events, helping save more lives and reducing the impact of disasters on communities.
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
raw data that have had some initial processing, created in a format that can be immediately integrated with other information and used within a Geographic 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
realistic and measurable criteria
2.1.5. Lidar
light detection and ranging ALTERNATIVE
common method for acquiring point clouds through aerial, terrestrial, and mobile acquisition methods
2.1.6. GeoNode
web-based platform for deploying a GIS
2.1.7. GeoPackage
open, standards-based, compact format for transferring geospatial information
2.1.8. GeoRSS
designed as a lightweight, community driven way to extend existing RSS feeds with simple geographic information
2.1.9. GeoServer
Java-based server that allows users to view and edit geospatial data
Note 1 to entry: 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. Geospatial Data
data that include information related to a location, that can be used to map objects, events, and anything else with a specific geographic location
2.1.11. JSON-LD
JavaScript Object Notation — Linked Data ALTERNATIVE
lightweight linked data format based on JSON
2.1.12. Jupyter Notebooks
open-source web application that allows the creation and sharing of documents that contain live code, equations, visualizations, and narrative text
2.1.13. Radar
radio detection and ranging ALTERNATIVE
detection system that uses radio waves to determine the distance (range), angle, or velocity of objects
2.1.14. REST API
Representational State Transfer Application Programming Interface
Note 1 to entry: Commonly known as REST API web service.
Note 2 to entry: When a RESTful API is called, the server will transfer a representation of the requested resource’s state to the client system.
2.1.15. SAR; Synthetic Aperture Radar
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
ACD
Amplitude Change Detection
AI
Artificial Intelligence
AMSR-E
Advanced Microwave Scanning Radiometer for EOS
API
Application Programming Interface
AR
Augmented Reality
ARD
Analysis Ready Data
ASMR-2
Advanced Microwave Scanning Radiometer 2
AWS
Amazon Web Services
BCSD
Bias corrected and spatially downscaled
C3S
Copernicus Climate Change Service
CAMS
Copernicus Atmosphere Monitoring Service
CDI
Combined Drought Indicator
CDS
Climate Data Store
CEMS
Copernicus Emergency Management Service
CNES
French Space Agency
COG
Cloud Optimized GeoTIFF
CONIDA
National Commission for Aerospace Research and Development’s, Peru
COSI
OGC Collaborative Solutions & Innovation Program
CQL2
Common Query Language
CRS
Coordinate Reference System
CSA
Canadian Space Agency
CSW
OGC Catalog Service for the Web
DARSIM
Disaster Augmented Reality Simulation Table
DEM
Digital Elevation Model
DP21
Disaster Pilot 21
DP23
Disaster Pilot 23
DRI
Decision Ready Indicator
DT
Digital Twin
DTES
Digital Twin Encapsulation Standard
ECMWF
European Centre for Medium-Range Weather Forecasts
EDR
Environmental Data Retrieval
ENSO
El Niño/Southern Oscillation
EO
Earth Observation
ESA
European Space Agency
ESIP
Earth Science Information Partners
ETL
Extract, Transform and Load
FAIR
Findability, Accessibility, Interoperability, and Reuse of digital asset
FAPAR
Fraction of absorbed light by the plants
FME
Feature Manipulation Engine (Safe Software)
GDO
Copernicus Global Drought Observatory
GEPS
Global Ensemble Predication Service
GIS
Geographic Information System
GISMO
New York City Geospatial Information System & Mapping Organization
GPM
Global Precipitation Measurement Mission
ICU
Intensive Care Unit
IR
InfraRed
JAXA
Japan Aerospace Exploration Agency
JSON
JavaScript Object Notation
JSON_LD
JavaScript Object Notation — Linked Data
LEO
Low Earth Orbit
LSTM
Long Short-Term Memory
MAE
Mean Absolute Error
MAPE
Mean Absolute Percentage Error
ML
Machine Learning
MRLC
Multi-Resolution Land Characteristics
MSC
Meteorological Service of Canada
MTC
Multi-Temporal and Coherence
NAOMI
New AstroSat Optical Modular Instrument
NDVI
Normalized Difference Vegetation Index
NetCDF
Network Common Data Form
NIR
Near-InfraRed
NLCD
US National Land Cover Database
NNet
Neural Network
NOAA
US National Oceanic and Atmospheric Administration
NRCan
Natural Resources Canada’s
NRT
Near-Real-Time
OGC
Open Geospatial Consortium
OLI
Operational Land Imager
ORLs
Operational Readiness Levels
OSM
OpenStreetMap
PDSI
Palmer Drought Severity Index
PHC
Public Health Center
PPE
Personal Protective equipment
RCM
RADARSAT Constellation Mission
RMSE
Root Mean Squared Error
S3
Amazon Simple Storage Service
SAR
Synthetic Aperture Radar
SatCen
European Union Satellite Centre
SDI
Spatial Data Infrastructure
SMA
Soil Moisture Anomaly
SPDI
Standardized Palmer Drought Index
SPEI
Standardized Precipitation Evapotranspiration index
SPI
Standardized Precipitation Index
SPoG
Single Pane of Glass
SRTM
Shuttle Radar Topography Mission
SST
Sea Surface Temperature
STAC
SpatioTemporal Asset Catalog
TIRS
Thermal Infrared Sensor
TRMM
Tropical Rainfall Measuring Mission
UAV
Uncrewed Aerial Vehicles
USGS
US Geological Survey
VGI
Volunteered Geographic Information
VIIRS
Visible Infrared Imaging Radiometer Suite
VR
Virtual Reality
WCS
Web Coverage Service
WFS
Web Feature Service
WHO
World Health Organization
WKT
Well-Known Text
WMS
Web Map Service
WMTS
Web Map Tile Service
WPS
Web Processing Service
WUI
Wildland-Urban Interface
XR
Extended Reality
3. Relationship Between Guides
The Provider Guide is one of a trilogy of Guides being developed through Disaster Pilot 2023 (DP23) alongside the User Guide and the Operational Capacity Guide. These three guides are shown in Figure 1.
Figure 1 — Three Guides
The details of the three Guides are as follows.
Provider Guide
Audience: Existing and potential, data and technical application providers, data collectors, processors, publishers, emergency management information technology support functions, together with other supporting stakeholders.
Purpose: To describe the detailed technical requirements, data structures, and operational standards providers need to implement to integrate the data flows or tools developed in DP23 to enable data or applications to be operationalized by disaster and emergency user communities.
User Guide
Audience: First responders, commanders, decision-makers, and associated people interested in using the data in practice and encouraging culture change to realize the potential value of having available data to support disaster and emergency planning and response.
Purpose: To provide a non-technical showcase of the workflows and tools demonstrating what is possible and what opportunities there are for disaster and emergency management communities to use these solutions to support and enhance disaster planning, management, and response.
Operational Capacity Guide
Audience: Disaster and emergency management administrators, operational managers, and policy makers, together with emergency management teams.
Purpose: Stand-alone document, providing an outline of the strategic actions required for any disaster or emergency management team wishing to establish, enhance, or improve the team’s geospatial readiness, delivering a robust and effective geospatial function to respond to disaster events including emergency management program funding functions and information technology support functions.
The Guides work together, with each individual Guide focusing on the key information for each Guide’s specific audience and providing signposting to further details should it be required. Figure 2 gives an overall structure for the Guides.
Figure 2 — Detailed Guides relationship.
4. Use of Geospatial Information in Disaster Response
Disaster management is generally understood to consist of four phases: mitigation, preparedness, response, and recovery. Mitigation describes activities aimed at reducing the occurrence of emergency situations, preparedness focuses on active preparation, response is the acute phase occurring during and after the event, and recovery covers a wide range of processes that support getting back to a state of acceptable operation. While all phases are interrelated and important, the response and recovery phrases are often viewed as the most critical in terms of saving lives. The timely provision of geospatial information can greatly help in the decision-making process, save lives, and aid those affected.
4.1. Geospatial Data
Geospatial data can be defined as data that describe objects, events, or features using locations on the Earth’s surface. The simplest form of presenting such information is a map. Whilst the earliest maps began with the Babylonians 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.
The term geospatial data covers a lot of different sources of data which have spatial references, meaning the data have geographical references, which give the data locations. There are many types of geospatial data, and all could offer benefits in a disaster scenario depending on the circumstances. Examples of the types of geospatial data that could be available include the following.
Satellite data — can include optical, thermal, radar or lidar data
Airborne imagery/photography — could be collected by aircraft, helicopters, or drones and can also include optical, thermal, radar, or lidar data
Oblique angle photography
Building or Computer Aided Design drawings
3D Renderings
Citizen Science data – namely, data collected by first responders or general citizens, usually on handheld devices, giving precise snapshots of what is happening at specific locations.
The type of disaster, the location, or the information required, will determine which data sources may be helpful. However, it is unlikely that one single data source will answer all the questions about the disaster. The way problems are often solved is through the integration of multiple data sources, and it is these combinations of datasets and looking at the data in different ways that give additional insights.
Together, geospatial data and technologies such as Geographic Information System (GIS) offer the potential to provide first 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, improving awareness of the current situation. Therefore, providing access to these technologies allows saving lives and helping people respond to disaster events. The following look at some of the more common types of geospatial data in more detail.
4.1.1. Satellite Data
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 that satellites were used to make observations of the Earth. The first real mapping satellite was NASA’s Earth Resources Technology Satellite launched in 1972, later renamed to Landsat-1. To date, Landsat offers a 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) which is involved with the European Union’s Copernicus program, the Japanese Space Agency (JAXA) that has 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.
While there are now lots of satellite datasets and products, both commercial and governmental, there are also some programs focused solely on supporting disaster and emergency scenarios, such as the following.
International Charter: Space and Major Disasters was signed on 22 October 2000 by ESA, the French Space Agency (CNES), and the CSA. 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 providers around the world, giving the teams responding and managing the specific disaster access to a wide range of data. Since its inception, the Charter has been activated for over 800 disasters in 127 countries; during 2022 it was activated 51 times.
Copernicus Emergency Management Service (CEMS) is a European focused service that provides Disaster and Emergency communities with geospatial information to inform decision making. CEMS constantly monitors Europe to forecast, analyze, and provide information for resilience strategies. The datasets are created using satellite, in situ (ground), and model data, and offers on-demand maps, time-series, or other relevant information to better manage disaster risk.
4.1.2. Airborne Imagery or Photography
Aircraft are often requisitioned as a core lifeline after disasters occur, as the aircraft are used to drop supplies and/or rescue survivors. As a result, passenger aircraft may be an alternative remote sensing platform in emergency response due to the high revisit rate, dense coverage, and low cost, i.e., photographs from the people on the aircraft. A more operational use, for example, could be for wildfire detection and monitoring, with thermal sensors being particularly useful. The initial characterization of the fire’s properties (e.g., location, size, proximity to water or inhabited areas) is critical to mounting an initial response.
Uncrewed Aerial Vehicles (UAVs), often termed drones, can also provide local situational understanding in terms of what is currently happening and/or the immediate aftermath.
Looking towards the near-term future, High Altitude Pseudo Satellites (termed HAPS) which are high altitude balloons, or constellations of micro-satellites, will increasingly offer sensor-dependent persistent coverage.
4.1.3. Citizen Science Data
Sensors can also be found in smartphones and other devices, plus social media offers potential to collect data. As a result, any person, device, or sensor is a potential data generator and can create complex datasets, termed Big Data. The location of the sensor is expressed in a standard and readily understood form, such as latitude-longitude, street address, or position in some coordinate system. But these data may also include indirect information about location or unstructured data, where methods and tools for extracting the required information are needed. Also, although mobile applications can be a key element in improving situational awareness, a post-event observation may not provide important information on the pre-event structures and so different sources for pre- and post- event awareness must be combined. Also, any new technological ‘solution’ would tend not be used during a disaster unless the stakeholder community had already adopted and trained with the solution pre-event.
4.1.4. Real time sensor data
While citizen science data tends to be intentionally submitted, mobile devices and other systems can collect data more automatically. Producing a continuous stream of data which can be leveraged to observe patterns and detect anomalies, and in turn detected patterns can help drive hazard indicators. These data can be collected from sensors, instruments, or devices in the environment (Internet of Things IoT).
4.1.5. Model Data
While real time sensors give a better situational awareness of what is happening in the world today, models provide a better understanding of what could be happening given a range of assumptions. These assumptions are used to feed a model calibrated to behave in ways that approximate to some aspect the natural world. Increasingly, the importance of incorporating the results of climate models to gain a better understanding of future possibilities and hazards associated with climate change is being realized.
4.1.6. Challenges of Using Geospatial Data
While the idea of using geospatial data within disaster and emergency situations is positive, there are several practical issues that can prevent the data being used to the greatest advantage. These challenges include the following.
For First Responders
Geospatial maps and data can be useful to give situational awareness, but are not comparable to having experienced boots on the ground determining what needs to be done.
Sharing data is challenging for first responders:
lack of mobile coverage and service is a big issue; and
data often have to be shared physically, such as via AirDrop on Apple devices.
Speed of update is critical in fast moving situations.
Offline options for data management and visualization are vital in rural areas.
For Operational Managers:
Data acquired are not always useful as availability can be limited by meteorological and geographical factors.
Emergency management agencies want value-added products such as decision support information, thematic data/images, etc., as these can be quickly integrated into the decision-making process.
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. So, data need to be at a spatial resolution that can help and support decision making.
Tendency to go with the tried and tested approach for data sharing and mapping applications, and a conservative approach to trying new technology.
For Data and GIS Analysts
Obtaining, downloading, and integrating data into local GIS systems can take too long, i.e., before the data are useful for disaster response.
Increases in the amount of data potentially available can be overwhelming and can inhibit the ability to efficiently manage, use, and share data.
For Satellite data operators/value adders
Satellite data response time is often not considered rapid enough for real-time monitoring.
Delivery of first crisis satellite products within 23 hours remains challenging, due to the characteristics of the satellites, their orbits, cloud cover, and “true operational” revisit time.
The lack of a framework to quickly supply satellite images free of charge in an emergency, which needs to include data providers (space agencies and commercial organization), data analysts (universities, research institutes, etc.), and users (disaster management organizations), can make it difficult to obtain data where credit card or financial approval is needed. These issues are partly addressed through international efforts, but activities need to continue to improve satellite data to fulfill the potential for the data to be used throughout the value chain.
For Citizen Science Data
Social media data have improved the efficiency and scope of disaster information communication, but at the same time, social media data also bring some misinformation. Therefore, filtering and cleaning is an important part of the disaster information and representation process. Also, social media companies are starting to monetize data and other offerings and so access may no longer be free.
Social engagement and participation in data sharing and reliable information are lacking in developing disaster GIS maps and 3D representation.
5. How To Use This Guide?
The OGC Disaster Pilot 2023 (DP23) technical solution built on the success and outcomes of Disaster Pilot 2021 (described in Clause 7.2) and other OGC Collaborative Solutions and Innovation Program (COSI) initiatives.
This Guide is for existing and potential data and technical application providers, data collectors, processors, publishers, emergency management information technology support personnel, and other supporting stakeholders.
This Guide gives the detailed technical requirements of each of the tools and data workflows, together with links to persistent demonstrators showing the operating details and the benefits available to disaster and emergency communities. This information should give enough detail to enable the tools and workflows to be operated, and also give tool developers the standards needed to participate in this ecosystem.
5.1. Tools to Support Use of Geospatial Data
Within Annex A there are a series of potential tools that can help disaster and emergency communities to gather, find, and visualize data for any type of disaster. For each tool there are:
a description of the tool, and what it can offer;
details of the benefits the tool offers, how it can support decision making, and the job roles of who would use this tool; and
details of how to find the online demonstrations for the tool and any collaborations undertaken as part of DP23.
5.2. Data Workflows to Support Disaster Management & Response
A series of specific data workflows have been developed by DP23 & DP21 participants covering the following.
Droughts in Annex B
Wildfires in Annex C
Flooding, including landslide and pandemic impacts, in Annex D
Integration of Health & Earth Observation Data for Pandemic Response in Annex E
These data workflows will produce either Analysis Ready Datasets or a Decision Ready Indicator, which are described in more detail below.
Each of the data workflows within the Annexes include the following.
Introduction to the workflow and the risk or issue it aims to support.
Indicator recipe, which describes the input data used, the processing and transformations undertaken, the output data produced, and details on the technical requirements and standards used by the workflow.
Details of the benefits the workflow offers, the types of decisions it can support by these data, and the job roles that would use the output.
Details of how to find the online demonstrations for tool and any collaborations undertaken as part of DP23.
5.2.1. Types of Users
The Pilot has identified the following four user groups.
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.
Disaster Response Planners or Managers who lead the disaster readiness and response activities for the responding organizations.
Field Responders who are on the ground responding to the disaster and reporting to the responding organizations.
Affected public and communities who want direction and guidance on what to do.
Each of these user groups requires different types of data or information, at different levels, and presented in different ways.
5.2.2. Data Set Types
The data workflows take raw data (which could be any form of geospatial data such as geographic data, satellite, or airborne data) fixed gauges or instruments, demographic and social data, health data, field observations, or citizen science data, and then undertake some processing to create one of two types of datasets; either an Analysis Ready Dataset or a Decision Ready Indicator as shown in Figure 3.
Figure 3 — Relationship between ARD to DRI, courtesy of Josh Lieberman (OGC).
Analysis Ready Datasets (ARD)
Analysis Ready Datasets are raw geospatial data to which initial processing has been undertaken to create a dataset in a format that can be immediately integrated with other information and used within a Geographic Information System (GIS) and can be interrogated by people with the right skills to gain greater insight. These data can be either visualized or further analyzed, interrogated, and/or combined with local knowledge to create information upon which decisions can be made.
+ ARD is most likely to be used by Data Analysts but could also be used by Disaster Response Planners and Managers.
Decision Ready Indicators (DRI)
Decision Ready Indicators are 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.
+ This information will be useful for Disaster Response Planners and Managers, Field Responders, and the 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: Although these are the two main types of data envisioned throughout the Pilot it was acknowledged that datasets 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 DRIs. The type of dataset offered by each participant should include a clear indicator recipe and/or output type in the Annexes.
6. What is Provider Readiness?
Readiness is the state of being fully prepared and in this case, it is the state of being fully prepared to provide information to support a disaster response activity. More specifically, in terms of the OGC Disaster Pilot activities, Readiness is determining what is needed for developed tools and workflows to be operationalized by a disaster and emergency community ecosystem.
The overarching aim of DP23 was to develop flexible, scalable, timely, and resilient information workflows, together with applications and visualization tools to promote a wider understanding of how geospatial data can support emergency and disaster communities and critical disaster management decisions. To be part of the envisaged Pilot ecosystem, both data providers and users need to be prepared to take part, which means making a series of agreements. However, this cannot simply 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 need to know the format the data needs to be provided in that users can immediately integrate within the data system being operated.
Ideally, this activity would be undertaken before a disaster occurs, as starting this process once a disaster is underway will simply take time and slow down getting the geospatial data to the people that can put it to use to support the response. The elements that need to be agreed run from license agreements through to data formats, geospatial systems used, analysis skills, data aggregation and transformation methods, and even the symbols and colors to be used in the visualization, and so on.
This section of the Guide describes the four steps that providers should complete in order to be in a position to achieve readiness and fully participate in the disaster response ecosystem.
6.1. Step 1: Understand and Implement Common Standards
As discussed, the driving force of these initiatives is to enhance the access, sharing, use, reuse, and exploitation of geospatial information and applications across, and between, organizations within disaster and emergency communities. Common standards are fundamental, as are the underpinning foundations that are needed to support data interoperability.
Using agreed technical standards alongside common data formats will ease the process of integrating data, not only within the disaster and emergency community, but also across boundaries, which will also help any new data providers wanting to offer new datasets to be clear as to what the requirements would be for any new data flows.
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 increases.
6.1.1. FAIR Principles
OGC promotes, and encourages, the FAIR principles for data management to improve the Findability, Accessibility, Interoperability, and Reuse of digital assets; these are as follows.
Findable
The first step in (re)using data is to find them. Metadata and data should be easy to find for both humans and computers. Machine-readable metadata are essential for automatic discovery of datasets and services, so this is an essential component of the FAIRification process.
Accessible
Once the user finds the required data, she/he/they need to know how the data can be accessed, possibly including authentication and authorization.
Interoperable
The data usually needs to be integrated with other data. In addition, the data need to interoperate with applications or workflows for analysis, storage, and processing.
Reusable
The ultimate goal of FAIR is to optimize the reuse of data. To achieve this, metadata and data should be well-described so that both can be replicated and/or combined in different settings.
6.1.2. Geospatial Standards Within Disaster Pilot 23
The geospatial standards for each of the elements from data discovery to visualization include the following.
Discovery
Service(s) and associated application(s) support near-real-time registration, search, and discovery of Analysis Ready Datasets (ARD) and Decision-Ready Information and indicators (DRI), alongside contextual social-political-health datasets and local observations within impacted areas. This element includes implementations of OGC API Standards that provide structured geospatial data to support web-based searching with JavaScript Object Notation — Linked Data (JSON-LD) and include generation of metadata catalogs and self-describing datasets to aid data access and processing, e.g., SpatioTemporal Asset Catalog (STAC) and GeoPackage.
Data Storage and Processing in the Cloud:
Cloud-based storage, processing, and service elements 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 STAC
Processing has utilized Jupyter Notebooks
Storage formats included the transition of imagery to formats that support cloud-native geospatial processing, e.g., 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)
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)
Having these pre-agreed and understood in advance can ensure consistency and an efficient processing/delivery of the needed disaster-related information.
6.2. Step 2: Develop Dataset Recipes or Tools to support the access, sharing, use, reuse, and exploitation of geospatial data
To be part of the OGC Disaster Pilot ecosystem, providers need to develop a value chain as shown in Figure 7, whether this is a non-proprietary tool to help access, share, or visualize data, or the development of an indicator recipe to create either an ARD or a DRI value chain that produces a dataset that can be used directly, or combined with other information in a GIS.
Examples of the tools and indicators developed by Pilot participants can be seen in the Annexes to this Guide, with details of the indicator recipes, collaboration possibilities, and persistent demonstrators.
A number of tools can be used to implement these recipes in a way that is 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 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 Disaster Pilot activities.
An example of working through the process of understanding what is needed were the discussions within the ARD and DRI working groups in Disaster Pilot 21, with the OpenStreetMap (OSM) conversion undertaken by Safe Software using FME as follows.
Areas of interest extents or polygons were shared in GeoJSON format allowing all participants to be sure discussions were about the same geographical extent.
Basemap data was extracted from OSM and shared via a GeoPackage as foundation layers. Although this may sound like a trivial exercise, it was not because:
there was an interpretation process when extracting information from OSM and ‘flattening’ it for use in a GIS; and
a further complexity was that the original OSM data use geodetic coordinates and the Coordinate Reference System (CRS) ‘EPSG:4326’, 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, i.e., longitude would come first.
In DP23, a similar focus was placed on the climate projections from models that are often distributed in formats such as NetCDF (Network Common Data Form), a community standard for sharing scientific data. NetCDF has advantages such as being self-describing and appendable with climate community agreed standards such as the CF Metadata Conventions. However, it can be difficult to use/understand alongside data being stored in large files. One solution is to create virtual Zarr interfaces (a format designed for cloud storage and access) while another is to just extract the data of interest and reformat the data into a simpler format, e.g., serving point/polygon data via a Features server.
6.3. Step 3: 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 so the Pilots do not recommend one, nor do the Pilots suggest that the solution would be based around a single technology. Instead, using a set of standards for data sharing, as described in Clause 6.1 will enable data to be interoperable and reusable across any platform. Solutions could be provided that are open source, commercial, or even using existing internal infrastructures.
The key element is that the receiving organization has a solution where the decision-ready indicators can be uploaded for users to access. The preferred solution will depend on the organization’s infrastructure, financial pressures, technical skills, etc.
Within the Pilots, several external platforms were tested, including the following.
Immersive Indicator Visualizations
Immersive Indicator Visualizations were developed by USGS-GeoPathway which offers ARD and DRI to enhance comprehension of drought and wildfire management across varied spatial-temporal scales. It has two elements: Disaster Augmented Reality Simulation Table (DARSIM) — DARSIM modernizes traditional simulation tables, replacing bulky sand models with a portable, data-integrated solution, designed in response to wildland firefighter needs; and Single Pane of Glass (SPoG) — The SPoG provides a unified view of multiple data sources, promoting synchronized decision-making using DRIs and ARD.
Geocolloborate
Geocolloborate is 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 HSR.health 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 Clause 6.1. In addition, it will be necessary to ensure the following.
Licenses have been agreed with the external provider for the use of the platform, including sufficient licenses being 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.
6.4. Step 4: Operationalize the Disaster Response Tool or Workflow
Step two focused on developing datasets workflows, applications, and visualization tools, but to prevent these tools from being proof-of-concept examples or a short-lived demonstration, the tools need to be able to be operationalized to promote the wider understanding of how geospatial data can support emergency and disaster communities.
Providers need to maintain persistent demonstrators of applicable data workflows or tools, and offer disaster and emergency communities the opportunity to test workflows and tools in controlled environments to experience how the workflows and tools work. In the Annexes to this Guide are descriptions of all the data workflows and tools which should give an understanding about what the provider is offering, but it is the use of the tool or workflow in practice or within disaster exercises that will determine whether it works for that community, whether changes are needed, or whether it is a success.
Finally, it will be important for the users of the datasets, indicators, and tools to understand what the impact will be, and what specific decision trees will be enacted when an indicator reaches a certain level. For example, in a flood or wildfire situation, 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.
In summary, the workflows and tools need to be established for the long term, not just for the project, otherwise there is no point in any of the disaster and emergency communities testing and using workflows and tools, if the communities cannot be sure the workflows and tools will be available when a disaster situation strikes.
Although not developed within the Pilots, one suggestion was to develop a series of Operational Readiness Levels (ORLs), similar to those developed by 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.
7. Descriptions of Case Study Areas and Hazards
The vision of the Disaster Pilot 2023 (DP23) initiative revolved around bringing the technological pieces together and increasing stakeholder engagement, in order to reduce the preparation time and accelerate the ability to transform data from observations into decisions. To achieve this goal required bridging the divides between providers, responders, and other stakeholders, forming a connected ecosystem of data and technologies, and developing the capacity to produce Decision Ready Indicator (DRI) products that answer decision makers’ questions almost as fast as the questions can be posed.
Previous work delineated multiple phases of cycles of activity within disaster management, see Figure 4, all of which depend on getting the right information to the right people at the right time.
Figure 4 — Cycles of activity
Within the longer-term, risk management and emergency management cycles are shorter term incident response phases for which the ability to move fast and adapt is particularly important. Disaster Pilot 2021 (DP21), found in Clause 7.2, focused on supporting these shorter-term activities such as the following.
Risk and vulnerability assessment and preparation
Threat prediction from hazards
Severity assessment of disaster occurrences
Impact awareness
Response and mitigation
DP2023 expanded its focus to activities across a wider range of timescales, such as adaptation and planning, because drought and wildland fires occur on very different timescales, and there is a need to support the balancing of resources between immediate and longer-term needs. This balancing is also relevant to resilience in the face of broader climate change effects.
In developing tools and workflows, the DP23 & DP21 participants have used several case study areas and hazards as the basis for demonstrators. In DP23, it was Manitoba in Canada and the south western United States, while DP21 focused on the Red River Basin in Canada and the United States, the Rimac and Puira Rivers in Peru, and Louisiana in the United States.
7.1. 2023 Disaster Pilot
Details of the case study areas and the hazards for DP23 include the following.
7.1.1. Manitoba: Drought Hazards
Manitoba in Canada has been used in DP23 as the case study area looking at hazards associated with drought. Specifically, the area covered is the provincial boundary of Manitoba, covering an area from 49 to 52 degrees North.
Canada’s Changing Climate Report projected a substantial increase in the number of hot days for the region, highlighting the potential increased risk of droughts which will affect many aspects of Manitoba’s landscape. Droughts not only affect agriculture. Water-sensitive areas, such as power generation, fisheries, forestry, drinking water supplies, wildfires, manufacturing, recreation, wildlife, and aquatic ecosystems, can also be severely affected due to recurring droughts (Manitoba Green Plan, 2020).
For example, in Manitoba, from 1988 to 1990 and 2002 to 2003, drought in the Churchill/Nelson River Basin reduced agricultural production to 60% below average, caused an $80M CAD loss in reduced hydropower exports, a massive loss of wetland habitat, and an increased incidence of disease (Manitoba Green Plan, 2020). A 2012 drought caused wildfires to break out near the communities of Badger and Vita, leading to the declaration of local states of emergency. Manitoba’s recent extreme drought of 2021-22 throughout most agricultural regions reduced hydropower exports by $400M CAD (Manitoba Hydro, 2021) and decreased crop yield by 37%, equivalent to an estimated $100M CAD in revenue, and caused the loss of an estimated 270 jobs.
The individual workflows for this Case Study can be found in Annex B.
7.1.2. Southwestern United States: Wildfire hazards
There are three southwestern states selected as the case study areas for wildland fires.
Utah
Fish Lake with a 50-mile radius.
Fish Lake is a high alpine lake in south-central Utah, which lies within the Fishlake National Forest. The lake is five miles long and one mile wide and the surrounding forest covers 1.5 million acres. The forest is home to Pando, a huge cluster of 40,000 aspen trees covering over 100 acres, that all share the same root system. Fishlake National Forest was the site of Utah’s largest wildfire of 2023, which began with a lightning strike and burnt almost 8,000 acres during August.
Brian Head with a 25-mile radius.
Brian Head is a small town in Iron County, Utah, with a population of around 100 people. It sits at 3,000 meters above sea level and is the highest elevation town in Utah. Given the town’s altitude, it has an alpine climate with cold winters and annual snowfall of around 9 meters, while the summer provides frequent thunder storms from the monsoons. Brian Head sits within the Dixie National Forest, which covers almost 2 million acres. The vegetation in the Dixie National Forest ranges from desert-type plants at lower altitudes, through to pine and juniper, and finally aspen and coniferous trees at the higher altitudes.
Parley’s Summit with a 25-mile radius.
Parley’s Summit is a mountain pass at the top of Parley’s Canyon, to the east of Salt Lake City in Utah. The summit has an elevation of 2,170 meters and is the highest elevation point of the I-80 highway in the state. In 2021, a wildfire burned almost 550 acres in the Canyon and led to thousands of evacuations.
Arizona
Tucson with a 25-mile radius.
Tucson is the second largest city in Arizona and has a population of over a half a million people. It is situated between Saguaro National Park to the east and west, and the Coronado National Forest to north and south. Tucson is surrounded by five minor mountain ranges and has a hot desert climate, with the summer average daily high temperatures between 98 and 102°F. The wildland fire risk in Tucson, on the most dangerous fire weather days, is very high and expected to increase with climate change.
Sedona with a 50-mile radius.
Sedona is a small city in the north of Arizona, within the Verde Valley region. The city sits within the boundaries of the Coconino National Forest and borders four wilderness areas and two state parks. Sedona is surrounded by 1.8 million acres of mostly coniferous woodland and has a semi-arid climate with mild winters and hot summers where the average temperatures approach 100°F during July. Increasing temperatures coupled with low levels of precipitation mean the forest is ideal fuel for any wildfires. In early 2023 lightning caused the Miller Fire, which covered around 30 acres before being bought under control.
California
South Lake Tahoe with a 25-mile radius.
South Lake Tahoe is the most populated city in El Dorado County, California, and is based within the Lake Tahoe basin. The city itself covers a total area of 43 square kilometers and lies along the southern edge of Lake Tahoe in the Sierra Nevada mountains surrounded by forest wilderness areas. South Lake Tahoe has a climate featuring chilly winters, and summers with warm to hot days and cool nights with very low humidity. The city can have temperatures reaching up to 90°F in July and August. The June 2007 Angora Wildfire was the worst forest fire in Lake Tahoe history, which burned more than 3,000 acres destroying more than 250 homes and a large area of forest. Since then, the Tahoe Fire and Fuels Team has treated tens of thousands of acres of forest around Lake Tahoe and is using forest management to reduce the threat of catastrophic wildfires. In 2021, the Caldor Fire went around the populated areas due to the treated forest and firefighting effort.
The individual workflows for this Case Study can be found in Annex C.
7.2. 2021 Disaster Pilot
Details of the case study areas and the hazards for DP21 include the following.
7.2.1. Rimac and Piura Rivers: Landslide & Flooding Hazards
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 Niño 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, severe floods can occur, which in turn can cause mudslides called huaycos. Figure 5 shows an index that indicates the El Niño phases in red and La Nina phases in blue.
Figure 5 — ENSO index with red indicating El Niño periods, Multivariate ENSO Index Version 2 courtesy of NOAA, USA
As an example of the relationship between ENSO and flooding, El Niño brought rains that caused severe flooding in 1982-1983 and again in 1998 but then, for several years, droughts and extreme heat were the main worries for these communities. Then the flooding returned again in 2002-2003 and 2017-2019. In 2017, ten times the usual amount of rain fell on Peru’s coast, swelling rivers, which caused widespread flooding and triggered huge landslides that tore through communities (Collyns, 2017).
The individual workflows for this Case Study can be found in Annex D.1.
7.2.2. Red River Basin: Flooding hazards
One of the most common types of flooding is river flooding, where the river (or rivers) overflow due to high rainfall or rapid melt upstream that causes the river to expand beyond its banks. The Red River flows north from Northeast South Dakota and West Central Minnesota into Manitoba Canada, and eventually out into Hudson Bay. The relatively flat slope of the Red River valley means that the river flow is slow, allowing water runoff from the land to backfill into tributaries, particularly when the downstream river channel remains frozen. In addition, localized ice jams may impede the water flow, resulting in higher river levels.
Therefore, conditions that determine the magnitude of a spring flood include (Anatomy of a Red River Spring Flood):
the freeze/melt cycle;
early spring rains increase melting of the snow pack or late spring snow storms add to the existing snowpack;
the actual snow pack depth and water equivalency;
frost depth;
ground soil moisture content; and
river ice conditions.
A typical spring thaw occurs from the middle of March across southern portions of the basin and mid or late April across the north.
An unusually wet fall and winter, combined with spring melting, drove the water levels up in April 2020. Figure 6 shows the April 2020/2021 water level comparison for the City of Winnipeg’s main gauge (James Avenue).
Figure 6 — Red River water level April 2020/2021 comparison, Winnipeg river levels
Winnipeg does have a 48 km floodway (long excavated channel) to reduce flooding within the city, but the floodway can only be opened when there are no ice jams. The floodway successfully protected Winnipeg from flooding during the high-water levels of 2020, and it is estimated the floodway resulted in around 930 million m3 of water being diverted around the City of Winnipeg (Manitoba, 2020 — PDF).
Unfortunately, ice jam events impacting the lower reaches of the Red River, between Winnipeg and Lake Winnipeg, have increased in both severity and frequency over the last century, a trend which is expected to continue and worsen in the future (Lindenschmidt, 2010).
The individual workflows for this Case Study can be found in Annex D.2.
7.2.3. Integration of Health and Earth Observation (EO) data and services for pandemic response in Louisiana in the United States
The State of Louisiana is located on the coast of the Gulf of Mexico, between Texas and Mississippi and covers a geographical area of just over 43,000 square miles. Louisiana is divided into 64 individual parishes and was estimated to be home to over 4,600,000 people in 2019 (US Census, 2019). Almost 16% of the population are over the age of 65, and just over 23% of the population are under the age of 18. Like the rest of the planet, Louisiana has suffered with COVID-19. By the middle of October 2021, over 750,000 cases of COVID-19 had been confirmed in the State, with over 14,000 deaths reported to date.
The climate within Louisiana is considered to be subtropical, and the physical geography of the area includes the Mississippi floodplain, coastal marshes, Red River Valley, terraces, and hills. Louisiana’s largest city, New Orleans, lying five feet below sea levels and protected by natural levees, is prone to flooding and hurricanes. During the pandemic, the area was hit by its second-most damaging and intense Hurricane, Ida, the most damaging being 2005’s Hurricane Katrina that flooded 80% of New Orleans.
The individual workflows for this Case Study can be found in Annex E.
7.2.4. Technical Architecture for Disaster Pilot 21
The technical solution aimed to bring together multiple providers into an ecosystem that transformed input data into actionable information by developing prototypical components and services. These components aimed to utilize modern cloud architectures and next-generation technologies to optimize collaborative workflows and scale solutions rapidly. An overview of the architecture for the Pilot is shown in Figure 7.
Figure 7 — Pilot architecture overview
At the top of Figure 7 are the data sources, which included 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 considered or used within the Pilot included the following.
Satellite Earth Observation
_Copernicus Sentinel Missions is 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. Since the Pilot, Sentinel-1B was lost.
_Landsat-8 is 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 was a Satellogic constellation that consisted of 17 commercial NewSat satellites in sun-synchronous Low Earth Orbit (LEO).
_PeruSat-1 is a 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 band 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 includes three RCM (RADARSAT Constellation Mission) satellites that 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 evacuation 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
Census micro data
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., http://hydro.iis.u-tokyo.ac.jp/~yamadai/MERIT_Hydro/), 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 ARD format, were ingested into cloud-based storage areas from where the data could be transformed into DRI. Users interacted through Mobile and Web/Desktop Applications (Apps), shown in the boxes at the bottom, which interacted with the DRI through a Registry and Search Catalog and GeoPackages. In addition, users provided Volunteered Geographic Information (VGI) into the overall ecosystem to support real-time insights into what was happening.
A key output was recognition and acknowledgment of the need to address:
stakeholder collaboration on data-to-decision workflows,
readiness, resilience, and timeliness of data collection and processing to support critical disaster management decisions;
flexible and scalable deployment of workflows and applications necessary to support disaster practitioners in their day-to-day and minute-to-minute responsibilities; and
publication and visualization tools to promote a broader understanding of the wide range of scales in both geography and time over which coordinated actions are needed for disaster resilience.
8. Collaborating With Workflow and Tool Developers
As described in Clause 6.2, a key focus for this Pilot was the development of data workflows and tools that can be operationalized by emergency and disaster communities.
The Pilot tried to enhance interoperability of critical connections where a lack of interoperability is particularly likely to derail data sharing. Figure 8 illustrates several pivotal points within a data to decision pipeline involving ARD and DRI, together with the feedback loops.
Figure 8 — Pivotal points of interoperability between distinct components of a data-to-decision pipeline
Within the Pilot activities, the developed workflows and tools often involved collaboration between participants, including:
using the outputs of one workflow/tool as an input to a different workflow or tool; and
collaborating with each other to try and use tools developed to help users find, access or visualize the data workflows that were developed.
As described in Annex A, Annex B, and Annex C, participants in the Disaster Pilot 23 aimed to provide persistent demonstrators to allow the disaster and emergency communities the opportunity to test workflows and tools in controlled environments to experience how the workflows and tools work. The participants will be happy to assist and support any community that needs further information on data workflow or tools, and the contact details for each participant will either be in the Guide and/or within the persistent demonstrators.
9. Next Steps & Recommendations for Future Disaster Pilot Initiatives
The Disaster Pilot initiatives made considerable steps towards improving the understanding, accessibility, and demonstration of what is possible with geospatial data for disaster and emergency communities. However, there was still a significant way to travel to ensure communities utilize and benefit from geospatial data solutions.
The following areas were highlighted as worth further exploration during future Pilots.
9.1. User Centric Approach
Greater involvement from the first responder and emergency manager stakeholders in defining the themes and deliverables would help the work have a more user centric approach, and ensure work undertaken directly addresses stakeholder needs. Pilots must begin with stakeholder’s wants and needs, an issue which was highlighted both in Disaster Pilot 23 (DP23) and in the associated Climate Resilience Initiative.
During DP23 a talk was given by an active firefighter who highlighted the geospatial data flows that would be must useful:
better detection of new wildland fires;
near real time information regarding what a wildland fire is doing, including the identification of hotspots through thermal detection, and anticipated wind direction and strength predictions; and
providing offline delivery of information within rural locations.
Interestingly, none of the DP23 participants were actively working on any of these data flows. The challenge for future Disaster Pilots is that participants are often focused on what is possible technically, demonstrating the cutting edge of geospatial data and/or their current area of interest and expertise rather than what users want and need.
A similar conclusion was reached by the first OGC Climate Resilience Pilot whose recommendations include to ‘design OGC Pilots with activities addressing potential stakeholders … to understand their requirements and access data products and tools related to their needs’.
While working with users needs is critical, it should be alongside continuing to look to the future and pushing the boundaries on the use of geospatial data.
9.1.1. Recommendations
Increase the involvement of first responder and emergency manager stakeholder community before the start of OGC Pilots to help define themes and deliverables to ensure the Pilots meet the stakeholder community’s wants and needs.
Ensure Pilots retain work to push the boundaries of the use geospatial data in the areas the users require help and support.
9.2. Artificial Intelligence & Machine Learning
Artificial Intelligence (AI) and Machine Learning (ML) are rapidly developing technologies and both need to be brought into future Pilots for development and assessment activities.
For example, simply during this Pilot, a number of developments were reported in the use of AI & ML for wildfires as follows.
Historically, Californian firefighters relied on a network of mountain top cameras and spotters to detect wildfires. In 2023, the firefighters were training an AI system to do the monitoring. In early results, the AI has delivered a faster indication of a fire around 40% of the time, improving response times, and identified fires where no 911 calls were ever made. Currently, the program still requires people to make sure the AI is detecting smoke and not something else. This work began in June 2023, and is expected to be rolled out across all 21 command centers later this year.
In Australia, fire agencies require fire updates every two minutes, especially for remote incidents, to improve situational awareness. The current XPRIZE Wildfire innovation contest aims to give firefighters a resilient advantage in accurate fast detection using AI.
One of the DP23 participants, HSR.health, is working on a solution to develop training data for a ML solution focused on the early identification of wildland fires and fuel sources by using NASA satellite data.
OGC approved the standard for OGC Training Data Markup Language for Artificial Intelligence (TrainingDML-AI) Part 1, which defines the conceptual model for standardized geospatial training data for ML which is used to train, validate, and test AI/ML models.
These examples show a small sample of current activities within one specific disaster scenario. It is important that Disaster Pilot initiatives keep up with this advancing trend, and work should cover areas such as those listed below which is not an exhaustive list.
Development of AI/ML solutions using various data from the diverse data sets available
Creation of high quality disaster-specific ML training data sets to enable providers to test their solutions and enable comparisons to be made
Provide an assessment of the accuracy of different data sets to determine which ones are most useful and beneficial
9.2.1. Recommendations
Include AI/ML activities as part of future Disaster Pilots, including solution development, training data sets, and an assessment and comparison of solutions.
9.3. Operationalizing Geospatial Data
The use of geospatial data to support decision making varies within disaster and emergency communities, with many communities currently using minimal geospatial data, tools, and applications. Some first responders need to meet face-to-face to enable the sharing of information, as robust technical solutions are not available.
From such a low starting point, it may be difficult to convince disaster and emergency decision makers to implement a disaster specific Analysis Ready Data and datasets (ARD) or Decision Ready Information and indicators (DRI) as a first foray into operationalizing and using geospatial data. Therefore, there needs to be a focus on developing geospatial capacity and quick wins for the benefits of geospatial data.
Cutting edge geospatial applications, tools, and data flows are interesting, but the goal of the Disaster Pilot initiatives needs to be the real time operationalization of the data flows and tools developed. Otherwise, the Pilots are simply demonstrators and are not providing real-life benefits. Quick wins might not be cutting edge, but would provide a stepping stone to operationalizing other data flows and tools.
Another opportunity would be greater use of real-time sensor data within future Pilots. Producing indicators providing a real time view of the current disaster situation, hazards, or risks would offer an alternative way of operationalizing the work. This would sit alongside the existing practices used by the first responding community and may highlight the advantages and benefits of geospatial data and information. Any real time sensors should leverage OGC sensor web enablement standards such as SensorThings API to make the data services involved modular, interchangeable, and readily consumable by downstream applications.
Similarly, the Operational Capacity Guide received positive feedback from the Manitoba Emergency Community which was keen to use it to develop and enhance the geospatial readiness of Manitoba communities. Further work on specific elements within this Guide — such as developing example Geospatial Operating Procedures templates or providing a Geospatial Disaster Guide for Emergency Managers — could provide a useful and positive step in furthering the use of geospatial data.
9.3.1. Recommendations
Working with first responders and emergency managers in the stakeholder community to identify quick wins for geospatial data and ensure these form part of the deliverables for future Pilots
Encourage the inclusion of real time, sensor-based indicators, and/or dashboards in future Pilots
Promote the use of OGC SWE — sensor web enablement standards for sensor communications and OGC APIs for the publication of indicators
Continue working on the specific elements of the Operational Capacity Guide to provide further support to help disaster and emergency communities to improve their geospatial readiness
9.4. Disaster and Climate Resilience
The frequency and severity of disasters are increasing as climate change causes weather and climate variations to become more extreme. Using climate services to inform indicators such as drought in terms of what future possibilities may be expected is going to be increasingly valuable. The ability to add the future dimension to forecast scenarios to better understand both possible threats and mitigation options will support improved resilience.
To fully exploit the opportunity of using climate services, the data need to be made more accessible and available to the disaster and emergency planners and managers who can use it. Two current approaches that show promise, although there may be others, are publishing data cubes via open standards (OGC APIs) and making ARD available in something approaching a gaming environment. Getting this information to those directly responsible for managing and mitigating natural hazards should help to better mitigate the issues and find practical solutions at the local level.
Future Disaster Pilots will benefit from having more direct integration between indicators and climate variables and services with the intention of bringing together the Disaster & Climate Pilots enabling this.
9.4.1. Recommendations
Ensure some type of climate services or variables are made available early in the Pilot to participants building indicators and data workflows to promote future climate projections becoming part of the outputs alongside the past/present/real-time perspective. Ideally, future looking indicators should support multiple scenarios, so that a variety of climate scenarios can be assessed.
Ensure climate services are available via open standards such as OGC APIs.
Further development of the concept of ARD in terms of climate services. ARD in terms of observations or measurements is well understood, but it is less defined for forecasting and future looking datasets due to the various potential scenarios available. Making climate ARD more easily understandable, accessible, and usable for disaster and emergency planners and managers will be critical in developing datasets and indicators that will offer future benefits.
Developing climate DRI’s will also benefit from more engagement with local and domain experts to help interpret and visualize potential climate impacts, including better engagement with indigenous peoples who, given their traditional knowledge, are often the leading local experts in terms of what local resources are most valuable and potentially vulnerable. This will be particularly important in terms of helping define the business rules of the indicators, i.e., if flooding is getting more severe, by how much does the timing of the evacuation order need to be altered. The challenge will be to ensure that indicators are not developed in such a way that the indicators are so locally tuned to only be valuable in one specific area.
9.5. Standing on the Shoulders of OGC Work
One of the strengths of OGC initiatives is the ability to build on and develop existing work to enhance, develop, or improve the work, whether the development of standards or Innovation Programs. However, it might be possible to develop this further.
Each Disaster Pilot has individually produced excellent work, but there is still a philosophical approach where each Pilot starts again from scratch. While previous documents and engineering reports are used, the specific data flows and tools are often left behind. While it is understandable that new ideas and disaster scenario’s are examined, providing continuity and availability of previous work would be valuable as well.
This Pilot aims to deliver persistent demonstrators from each of participants, as described in the Annexes, which is a positive step. This can go further, with a series of catalogs/registries listing developed data flows; supported by relevant documentation. The data flows themselves should be available and maintained for the long term and applications and tools should be available (license and fees dependent).
This is not to say previous work should not be further developed. For example, if catalogs can be improved then the catalogs should be. However, does each Pilot need to start by establishing a catalog?
Similarly, the Disaster Pilots could do more to support the development of standards, particularly in terms of supporting the development of standards such as those relating to ADR and DRI, testing standards with implementations, or establishing disaster-specific training data.
There is an opportunity for the establishment of an OGC based disaster planning and response ecosystem providing disaster and emergency communities with a plethora of ARD/DRI data flows, applications, and tools to support the communities’ activities. This would provide multiple benefits, including the following.
Disaster and emergency communities would have a place to go to see a wide variety of data flows and tools that could support the communities. The tools would have a level of authority, being based on OGC standards.
Providers looking to enter the ecosystem would have examples to review to understand what is required.
OGC Standards used in Disaster Pilot activities would have greater visibility.
Future OGC Disaster Pilots would have a place where the work the Pilots develop can be showcased and offered to disaster and emergency communities for future benefit.
As highlighted earlier, there is a need to make geospatial data and tools more accessible for disaster and emergency communities. The communities may not begin to use the data and tools today, but who knows what the communities will do tomorrow? It is certain that if the tools are not easily accessible, the tools will not be used.
9.5.1. Recommendations
Establish a long term persistent OGC disaster ecosystem where current, past, and future geospatial data flows and tools to support disaster planning and response can be made easily available and accessible to communities and organizations who might want to operationalize them.
Explore how persistent demonstrators can provide examples of how to use already available services, including the use of indicator displays and visualizations.
Involve the OGC Disaster Pilots in a greater manner in supporting the development and implementation of OGC Standards.
Annex A
(normative)
Tools Developed
There are many types of emergency disaster events and the tools described in this Annex can provide support to a range of events. The tools cover the following.
Gathering data
There are two examples of citizen science projects that use apps on smartphones to gather information for disaster planning or responding to an event in progress.
Finding datasets
The number of geospatial datasets available can vary. Some events will have a lot of datasets, while others may be more limited. Emergency Managers need quick and straightforward methods of finding what datasets may be able to help in terms of disaster planning or responding to unfolding events. Below are tools that offer catalogs and registry functions that could help identify available datasets.
Visualizing data
Taking advantage of the developing technology in terms of augmented reality, as shown below, can offer new ways for first responders and emergency managers to look at situations in a different way and can offer new insights.
It should be noted that data generated by a disaster event itself from sensors, observations, etc., exceed the data generated through normal day-to-day business by a degree of magnitude. Sorting through this massive quantity of data, a significant proportion of which will be from new, or less familiar sources, means that data catalogs and registry services are critical for helping to find and access the right data at the right time.
The tools developed by the Disaster Pilot 23 (DP23) participants are a follows.
Annex A.1.1 Registry & Catalog Functions developed by Compusult
Annex A.1.2 Climate Data Catalog, Data Service & Registry Tool developed by Safe Software
Annex A.1.3 Geospatial Data Registry Services developed by USGS-GeoPathways
Annex A.1.4 Emergency Location & Language Application developed by GISMO-Basil Labs
Annex A.1.5 FLORA Wildfire Mobile App developed by USGS-GeoPathways
Annex A.1.6 Wildfire & Drought Immersive Indicator Visualizations developed by USGS-GeoPathways
Annex A.1.7 GeoCollaborate Tool Visualization developed by StormCenter
The detailed technical information about each of these tools can be seen below:
A.1. Data/Workflow Service Registry and Discovery Tools
A.1.1. Catalog Services Developed by Compusult
A.1.1.1. Introduction
Compusult has enhanced its catalog to support OGC API records and other OGC APIs.
The Compusult Web Enterprise Suite application provides a means to carry out scenarios that include adaptation and planning in wildland fire situations, using the available data and workflows designed by all participants.
A.1.1.2. Description
A.1.1.2.1. Input Data
Files
The area of interest (bbox) and datetime parameter can be used to select only a subset of the records in the collection (the records that are in the bounding box or time interval). The bbox parameter matches all records in the collection that are not associated with a location, as well. The datetime parameter matches all records in the collection that are not associated with a time stamp or interval.
The limit parameter may be used to control the subset of the selected records that should be returned in the response, the page size. Each page may include information about the number of selected and returned records (numberMatched and numberReturned), as well as links to support paging (link relation next).
bbox
Only records that have a geometry that intersects the bounding box are selected. The bounding box is provided as four or six numbers, depending on whether the coordinate reference system includes a vertical axis (height or depth):
Lower-left corner, coordinate axis 1
Lower-left corner, coordinate axis 2
Minimum value, coordinate axis 3 (optional)
Upper-right corner, coordinate axis 1
Upper-right corner, coordinate axis 2
Maximum value, coordinate axis 3 (optional)
The coordinate reference system of the values is WGS 84 long/lat unless a different coordinate reference system is specified in the parameter bbox-crs.
For WGS 84 longitude/latitude, the values were, in most cases, the sequence of minimum longitude, minimum latitude, maximum longitude and maximum latitude.
However, in cases where the box spans the antemeridian, the first value (west-most box edge) was larger than the third value (east-most box edge).
If the vertical axis was included, the third and the sixth number were the bottom and the top of the 3-dimensional bounding box.
If a record had multiple spatial geometry properties, it was the decision of the server whether only a single spatial geometry property was used to determine the extent or all relevant geometries.
filter
Filters features in the collection using the query expression in the parameter value. Filter expressions are written in the Common Query Language (CQL2), which is a candidate OGC standard. The current API implements the draft version from February 2022, which is a release candidate. The language for this query parameter is CQL2 Text (filter-lang=cql2-text).
CQL2 text expressions are similar to SQL expressions and also support spatial, temporal, and array predicates. All property references must be queryables of the collection and must be declared in the Queryables sub-resource of the collection.
filter-crs
Specify which of the supported CRSs to use to encode geometric values in a filter expression (parameter ‘filter’). Default is WGS84 longitude/latitude.
filter-lang
Language of the query expression in the ‘filter’ parameter. Supported are ‘cql2-text’ (default) and ‘cql2-json’, specified in the OGC candidate standard ‘Common Query Language (CQL2)’. ‘cql2-text’ is an SQL-like text encoding for filter expressions that also supports spatial, temporal and array predicates. ‘cql2-json’ is a JSON encoding of that grammar, suitable for use as part of a JSON object that represents a query. The use of ‘cql2-text’ is recommended for filter expressions in the ‘filter’ parameter.
limit
The optional limit parameter limits the number of items that are presented in the response document. Items are only counted that are on the first level of the collection in the response document. Nested objects contained within the explicitly requested items shall not be counted.
properties
The properties that should be included for each feature. The parameter value is a comma-separated list of property names.
sort by
Specifies a comma-separated list of property names by which the response shall be sorted. If the property name is preceded by a plus () sign it indicates an ascending sort for that property. If the property name is preceded by a minus (-) sign it indicates a descending sort for that property. If the property is not preceded by a plus or minus, then the default sort order implied is ascending ().
Example Query of the CSW Catalog is https://ogc.compusult.com/wes/webservices/wescatalog/record/collections/CSW/items?f=json&lang=en&bbox=49,-144,68,-54&limit=10&offset=0
A.1.1.2.2. Output Data
The response was a JSON document consisting of records in the collection. The records included in the response were determined by the server based on the query parameters of the request. To support access to larger collections without overloading the client, the API supported paged access with links to the next page if more records were selected than the page size.
A.1.1.2.3. Technical Requirements & Standards
The WES Catalog is an OGC-based integrated services registry/catalog and repository. The application provided comprehensive, standards-based catalog creation and management modules, enabling data and service discovery, publishing, access, and maintenance.
WES Catalog was initially implemented using the OGC Catalog Service for the Web (CSW) standard and was recently upgraded to support the new OGC draft specification OGC API — Records. Backward compatibility has been maintained so that clients that only support CSW are still able to interact with the REST service. The application has a configurable metadata harvest process that will automatically ingest service metadata from remote services, servers, and other applications/catalogs. WES Catalog easily manages metadata about services (e.g., WMS, WFS, WCS, and WPS) OGC APIs (Features, EDR, Processes, Coverages, Tiles, and Maps), and repository items (e.g., XML documents, text documents, images, and sound) contained in the catalog.
The Web Enterprise Suite client has been enhanced to provide visualization in both 2D and 3D of the following OGC API standards:
OGC API Features
OGC API Coverages
OGC API Processes
OGC API EDR
WES Catalog supports multiple OGC API standards, each of which can be published and discovered via Catalog Services: CS-W and OGC API – Records for discoverable registries of geospatial data:
OGC API – Common
OGC API – Features — Part 1: Core and Part 2
OGC API – Environmental Data Retrieval (EDR)
OGC API – Processes
OGC API – Coverages
OGC API – Records
OGC API – Styles
OGC API – Maps
OGC API – Tiles
OGC SensorThings API
An OGC API Process will allow users to submit services and files to the catalog. The OGC API Records currently supports access to collections:
CSW Catalog
A.1.1.3. Benefits
Compusult’s catalog, with the support of OGC API records and processes, allowed external users to have access to register, search, and discover products and services.
This improved access and sharing of data and services, provided easy-to-use GUI and REST interfaces to publish, discover, and use data services using standards-based APIs for interoperability.
A.1.1.4. Collaborations
Compusult’s catalog was made available to all participants to contribute and share data. Content from other participants was harvested into the catalog and an account provided to others to allow them to query for data.
A.1.2. Climate Data Catalog, Data Service, and Registry Tool Developed by Safe Software
A.1.2.1. Description
Safe Software’s Climate Data Catalog, Data Service, and Registry component is implemented using the FME platform to support cataloging, referencing, and access to climate model data and related web services and metadata. The service also makes climate model data cubes available as FAIR Analysis Ready datasets (ARD) for search, access, downstream analysis, and decision support. In addition, the service has the capacity to incorporate base map, earth observation, and a wide range of other datasets. Whatever the type of natural disaster, whether fire, flood, drought, or other hazards, increasingly the severity of natural disasters is exacerbated by the effects of climate change. The challenge to manage and mitigate these effects poses difficulties for spatial and temporal data integration. One challenge is translating the outputs of global climate models into specific impacts at the local level.
The FME spatial data integration and automation platform, produced by Safe Software, can help explore options for bridging this gap given its ability to read datasets produced by climate models such as NetCDF or OGC WCS and then filter, aggregate, interpolate, and transform the data as needed. The platform is configured using no code data transformation models that can bridge the gaps between disparate systems using its support for hundreds of different spatial and nonspatial data formats and services. FME can also inter-relate climate data with higher resolution local data, and then output the data to whatever format or service is most appropriate for a given application domain or user community. This component supports the consumption of climate model output data cubes such as NetCDF or ZARR, transforming the data into a relational spatial database and making the database available by OGC API services.
Safe’s data service component has a particular emphasis on incorporating and serving climate model output ARD, which is essential to support disaster management in the changing world. While ARD has traditionally been applied in the context of earth observation data, ARD approaches can be equally applied to the development of data products related to climate scenario time series making the data products easier to consume for a wider range of applications and users.
This data service component also explored approaches to support data search and cataloging. The metadata harvest component allows users to provide a dataset in the form of a url or uploaded file. The service then auto-generates an ISO 19115 spatial metadata which can then be used to support cataloging. Safe Software has also implemented a basic OGC Records API service which provides a metadata catalog of Safe Software’s climate ARD services and lists the various items available via our services.
A.1.2.2. Description
A.1.2.2.1. Analysis Ready Data (ARD) Service
The challenge was to take climate model results and use them to feed forecast and impact models related to the hazards of interest such as drought, fire, or flood. This workflow transforms climate services data cubes such as NetCDF to a form of ARD — analysis ready data — more easily consumable by GIS applications, via publication of this via vector themes on OGC API Feature services. The underlying goal related to the wider pilot architecture is to feed the data value chain from raw source data — in this case climate model data cubes, through to ARD in order to feed a variety of DRI or decision and impact indicator workflows.
Figure A.1 — High level component FME workflow from climate data cube NetCDF to spatial database geopackage to OGC API Feature service GeoJSON
In terms of processing, this component takes the climate scenario model results from climate data services and transforms this into ARD. Making this data available via commonly accessible open standards is key to making this crucial data more widely accessible and usable by those who are likely to be affected by potential impacts.
In this example, the climate model data cube below was downloaded as NetCDF v4 using NetCDF conventions CF v1.4 with 960 bands representing monthly time steps. This was downloaded from Environment Canada, using the Environment and Climate Change Canada Climate Extraction tool.
Figure A.2 — Source NetCDF data cube from Environment Canada’s climate data extraction tool shown in FME
The data are then converted into a relational form and stored in a spatial database — in this case OGC Geopackage — shown in the FME NetCDF to Geopackage workflow below:
Figure A.3 — Mid level component FME workflow from climate data cube NetCDF to spatial database - Geopackage
Then, a spatial database to GeoSON workflow is used to make the data available by an easily accessible via an OGC API Feature service shown below:
Figure A.4 — Mid level component FME workflow from climate data cube NetCDF to spatial database - Geopackage
Note that the Geopackage to GeoJSON workflow is published to FME Flow / FME Server which in turn is hosted on the FME Hosted environment (FME Cloud) that runs on AWS — Amazon Web Services. This allows a workflow developed on the desktop using FME Form to run as a continuously accessible web service — in this case configured to support the OGC API Features protocol. One key aspect of this is parsing the OGC API feature requests and translating the parameters from them into database queries. This ensures that the feature queries only process the data actually needed to fulfill the request and is key to scaling performance given that the database stores several million records of point data.
For the selected climate scenarios, this supported the analysis of estimated drought risk impacts over time via simple feature queries that could be translated to SQL queries on the underlying spatial database and also fed drought related environmental factors to other DP23 indicator components such as Pixalytics drought model for more refined drought risk analysis. For the purposes of DP23, it was recognized that more complex indicators such as drought risk are likely driven by multiple environmental and physical factors. As such, the initial goal was to select and provide primary climate variable data such as precipitation and temperature that would be useful for deriving drought risks in combination with other inputs. The ARD data flow extracted total precipitation and mean temperature per month and made this available as OGC API features of time series points streamed as GeoJSON. These climate scenario primary drought data were provided for the province of Manitoba study area and was the dataset consumed by the Pixalytics drought model component. For more information on this refer to the Annex B impact and indicator components.
The data service also allows end users to use an OGC API client to access the climate data using queries and retrieve the environmental variables and statistics for their specific geographic extent and time period of interest. The service itself supports a range of query parameters which can allow users to explore various value ranges and extremes inherent in the climate scenario projections. Multiple environmental variables such as temperature, precipitation, and change in precipitation relative to historic values are available on the time series points. Users can then ask questions to look for times and places of concern relative to specific natural hazards such as drought, fire, heat, or flood.
As an example, the following OGC API Features client request can be made to the service: “Find all time step points over the next 40 years for southern Manitoba where projections indicate > 25% dryer and mean monthly temperature > 23C.” The OGC API Features Query Parameters would be:
Start Year: 2020
End Year: 2060
BBox: -100.0,49.0,-96.0,50.5
Limit: 2,000,000
MinPeriodValue: 0 (PrecipDelta)
MaxPeriodValue: 0.75 (PrecipDelta)
MinTemp: 23C (Min Mean Monthly Temp)
This would produce the out below, displayed in Safe Software’s Data Inspector client using the OGC API Features reader. This result shows climate model points derived from the RCP4.5 business as usual scenario that result from the query above. That is, these points from August 2048 and 2058 represent the hot and dry areas and times that satisfy the query above and could constitute increased drought and fire risk. The ultimate goal is to make climate model outputs more accessible in a form and structure easy to consume by those used to working with GIS tools.
Figure A.5 — OGC API Features response to above query: 63 temporal points with associated temperature and precipitation values, as shown in FME Data Inspector client.
A.1.2.2.2. Metadata Harvest Service
The Metadata harvest service allows users to provide datasets or data service links which it then reads and automatically extracts key properties and information metadata. This metadata can be supplied to data catalogs to enable the metadata to be discovered by users searching for data. In particular, the Metadata Harvest workflow reads the source data and dynamically extracts properties such as table and field names, extents, ids, and time stamps and then fills out an ISO 19115 template with those values.
The metadata harvest process has the following steps:
Read feature type name
Capture cumulative extents for all feature type records
Extract all feature type attribute names
Generate time stamp and unique id
Write properties to ISO 19115 metadata template
Figure A.6 — Metadata harvest FME workflow
This workflow is a standalone service. In the future it would be good to integrate this workflow with the OGC API services currently available. For example, when publishing new datasets to an OGC API Features service and registering the datasets with an OGC API Records service, this metadata harvest service could be used to auto-generate a description which could include the feature types and properties contained in the dataset.
This metadata harvest service could also be enhanced to add support for coordinate systems, auto-detect date fields to extract temporal range, and perhaps detect other data types, ranges, and statistical information.
Figure A.7 — User form for specifying dataset service link or dataset upload to harvest metadata from. This can also be invoked via an API call.
Figure A.8 — Metadata result harvested from user specified data service showing the data extents.
A.1.2.2.3. OGC API Records Service
Safe Software implemented a basic, experimental OGC API Records service which provided metadata on the climate data services and datasets delivered by the ARD component described above. The service was a basic implementation in that it simply provided the standard landing page, collection, conformance, and item information depending on the REST request made by the Records client allowing other components in DP23 to interrogate the catalog service and use the resulting metadata to assess and query other feature data services.
Figure A.9 — Safe’s OGC API Records Service: landing page on the left, and item collection page on the right
Safe’s OGC API Records Service is a read-only catalog service that serves to publish metadata on the datasets and services Safe Software has contributed to DP23. It should also be emphasized that this is an experimental limited implementation of the OGC API Records standard that only implements a selected subset of the methods described in the standard sufficient to offer the basic catalog and collection information mentioned above.
As limited as this implementation was, it did illustrate the way in an FME workflow can be designed to implement message handling in order to support a REST API such as this one based on OGC API Records. A typical FME workflow or transformation pipeline is designed to translate from one dataset type to another, such as CAD to GIS. This implementation showed that FME workflows can also be designed to handle message pipelines such as those associated with an OGC API. Instead of a source dataset, the input was simply a client request message. The data transformation workflow became a message handling workflow, which ultimately produced a response message instead of a response dataset. When run on FME Form on the desktop this simply reads one input URL or JSON message and outputs another, writing to an output text file. When published to FME Form (Server) this results in a service that continually monitors an endpoint, accepts GET or POST messages, and produces the appropriate JSON responses via a data streaming service.
Figure A.10 — FME message handling workflow published to FME Flow
In the case of the OGC API Features workflow, a get capabilities or collection request produced the collection JSON response listing the available layers that include embedded get feature request URLs. When the API client selected a specific dataset and layer, a get feature request associated with that called a specific FME workflow which was configured to query the requested data based on the user request parameters. This Geopackage to GeoJSON FME workflow then streamed GeoJSON features back to the client. So it was possible to have a message driven FME workflow published to FME Flow (FME Server), which ultimately streamed features back to the client based on the parameters of the initial request message. The ultimate goal was to make climate model outputs more easily accessible in a form and structure easy to consume by those used to working with GIS tools.
Also, by using OGC API interfaces, the data services were provided with sufficient parameterization such that end users could compose queries in order to retrieve the environmental variables and statistics for the specific spatial and temporal ranges of interest. In this way a query against potentially gigabytes of time series data may generate a query response of a few kilobytes of environmental variable point data that satisfies the composite query.
For example, consider the query looking for all time step points where mean monthly temp > 23.5C and precipitation has dropped > 25%. The initial implementation would require posing 2 queries: 1) mean monthly temperature is > 23C and 2) precipitation dropped more than 25%. Each of these queries might yield tens of thousands of points or more, and combining them would require joining the results of both queries together by location and time, which can be very process intensive. By appending these environmental variables by time step point, a composite query can filter on both value ranges at the same time and produce only a few hundred points as the result with no client side joins required. The principle here is to let the database do the work which keeps the client side traffic much lighter.
A.1.2.3. Benefits
The data services developed by Safe Software for DP23 provide a range of crucial capabilities to disaster responders, managers, planners, and analysts. The ARD data service allows planners and analysts to combine historical and current natural hazard risk assessments with models of future risk in order to better evaluate the resilience of their infrastructure and mitigation strategies. Composite query capabilities allow users to interrogate a combination of environmental variables for different value ranges and changes relative to past norms using OGC APIs meaning that analysts can experiment with different business rules and tolerances to explore trends in the data that may correspond to increased natural hazard risks over time, whether for heat waves, drought, flood, or fire.
Specifically, this ARD data pipeline is able to consume climate model outputs and use the outputs to feed forecast and impact models related to the hazards of interest such as drought, fire, or flood. The workflow transforms climate services data cubes such as NetCDF or ZARR to a form of ARD — analysis ready data — more easily consumable by GIS applications, via publication of this via vector themes on OGC API Feature services. The underlying goal is to feed the data value chain from raw source data — in this case climate model data cubes — through to ARD in order to feed DRI or decision and impact indicator workflows.
Because of the automated nature of the underlying FME workflows, it was also relatively easy to process different climate scenario inputs from data cube to geopackage, to support a range of scenario analyses downstream. The ability to evaluate a range of climate scenarios from low to mid to high emissions is crucial to testing the resilience of communities. Ultimately the goal of incorporating climate model outputs in disaster management planning is not so much to predict the specific level and type of natural hazards at a particular place and time, but rather to better understand the range and probabilities of hazard risks that can be expected, and what overall trends are likely.
Disaster planners can use the ARD service associated with a climate model future projections service to query for temperature and precipitation anomalies in order to give the planners a better understanding of environmental extremes that might be expected in the future. One key capability is to allow users to directly interact with and interrogate climate projection data, so that the users can see what type of environmental variable value ranges might be expected in the future and what trends to be aware of.
Note that the FME Data Inspector tool shown above also supports consumption of more than 500 spatial and non spatial data formats and services including more than 30 OGC standards, other open standards such as Open Street Map, as well as vendor proprietary standards. This includes a wide range of data types from metadata catalogs (CSW, STAC, OGC APIs) to tabular or databases and CAD / GIS to satellite imagery and 3D point clouds. This can help disaster analysts rapidly review any available data in a rapid response situation and quickly determine which datasets are most useful to support assessment and response efforts.
The metadata harvest service was useful to support auto-generation of metadata records which in turn can streamline the process for publishing and updating dataset metadata to data catalog services. One of the biggest challenges with any disaster response effort is which sources provide the most relevant data for the appropriate temporal and spatial context. Accurate and up to date metadata makes this search process a lot easier.
Finally, the OGC API Records service provided metadata on the climate data services and datasets delivered by the ARD component allowing users to interrogate the catalog service and use the resulting metadata to assess and query other feature data services.
A.1.2.4. Collaborations
Safe Software’s climate scenario drought impact component generated output as an OGC API Features service, delivering GeoJSON point features with associated climate properties. This enabled any other DP23 participant to consume this climate time series data for use in DRI components. In particular, properties include monthly mean temperature, total precipitation, and change in precipitation compared to the historical baseline (mean precipitation from 1950 to 1980 for that same location). This allows any end user to submit queries to the climate drought variable service. These data can then be used to drive downstream drought analysis or as a rough estimate of general drought risk. For example, Pixalytics was able to query for precipitation estimates for specific locations and feed that into near future drought model runs. In this way, Pixalytics wa able to compile a continuous summary of observed and projected drought severity for specific locations in Manitoba from approximately 2020 to 2024.
Further information on Safe Software’s contributions to OGC Disaster & Climate Pilots can be found at https://community.safe.com/s/article/OGC-Disaster-and-Climate-Resilience-Pilots
Safe Software’s persistent demonstrators for the services can be found at:
OGC API Features Service (accessible 9am — 5pm EDT, M-F)
OGC API Records Service (accessible 9am — 5pm EDT, M-F)
A.1.3. Geospatial Data Registry Services Developed by USGS/GeoPathways
A.1.3.1. Introduction
USGS/GeoPathways created a catalog, workspace, and workflow to index datasets, information, and apps. This supports researchers, citizen scientists, and policy makers in developing workflows for decision-ready disaster resilience indicators.
A.1.3.2. Description
There are a series of registries and one catalog in this community of resources. These are as follows.
Terria Disaster Risk Resilience Registry (Open Source) — This uses the web-based TerriaJS application to provide 3D visualizations of disaster-related datasets, for fire, drought, and more, with terrain elevation context.
ArcGIS Disaster Risk Resilience Registry (Proprietary) — This Esri ArcGIS Hubsite includes apps, data catalogs, and external resource links on disaster risk and resilience. This includes:
Knowledge Hub — This is a digital repository within ArcGIS Experience Builder containing explanations, multimedia, and key disaster information. Accessible via the 2023 GeoPathways Disaster Risk Resilience Hub, it features an ArcGIS 123 Survey for collecting and defining wildfire terms, apps, tools, and data. As the project grows, the aim is to expand the repository, allowing external contributions.
Extended Reality Immersive Spatial Market Catalog — A web-based ArcGIS Dashboard showcasing key metrics on the world’s best virtual reality and augmented reality headsets and can be used by anyone interested in metaverse technology to determine which extended reality (XR) headset will work best, including country, price, and company. Metrics can be sorted by various data types.
https://ogc-dp23.voyagersearch.com/navigo/search?disp=D187992491DF&view=card&filter=true&basemap=ESRI%20Street%20Map&q=&sort=score%20desc [Voyager Search Disaster Risk Resilience Registry] (Hybrid)
This web-based application by Voyager Search provides an indexed registry of disaster-related datasets. It facilitates the visualization of data across various map viewer software and enables the integration of AI/ML workflow models with indexed data. Voyager’s advanced indexing encompasses millions of datasets from commercial, organizational, and government data. Voyager’s software includes a powerful search function, exposing API data without complicated API requests. Voyager doesn’t store data but reveals endpoints and uses metadata for optimal searchability and data accessibility. Voyagers efficient API connector framework processes entire government and organizational data APIs in minutes for quick data extraction, enrichment, transformation, and deliverability.
+ As part of the partnership with Voyager Search, work was undertaken on indexing and testing Esri’s Living Atlas and USGS models with workflows that detect, extract, and assess ARD. Workflows were critical to automate repeated tasks that would increase overall efficiency as well as reduce the risk of data errors. Moreover, models operating on indexed data generate fresh data that are automatically integrated into the registry, thereby expanding the volume of data accessible to users.
A.1.3.3. Benefits
Users will receive updates on tech capabilities, response strategies, breaking news, and relief resources. The dashboard dynamically updates metrics based on selected queries or locations. It links each data record to a geographical location, enhancing analysis of XR hardware and allowing DP23 participants to share workflow information.
A.1.3.4. Collaborations
To develop these resources USGS/GeoPathways worked with USGS, US Forest Service, Federal Geographic Data Committee, NASA, ESRI, AmeriGEOSS, NOAA, GeoPathways Peru, Google, USDA, Microsoft, and Voyager Search.
Further information and demonstrations of this work can be found at:
A.1.4. Emergency Location and Language Application developed by GISMO-Basil Labs
A.1.4.1. Introduction
The Emergency Location and Language Application (Ella) is a mobile crowdsourcing survey and reporting application that aims to give a client the opportunity to design a survey script to collect information direct from individual citizens via a smartphone. The goal is that Ella would supplement the 9-1-1 system when it was overwhelmed and important information was being missed.
A.1.4.2. Description
Ella was designed to capture information and use it for a variety of outputs that could be quickly reviewed by the response community and made available to responders in the field. Ella can also provide up-to-the-minute status reports of conditions within the disaster zone, and — unlike the way 9-1-1 is utilized — could be modified and redeployed whenever there were changes in the nature of the disaster.
Data are inputted via users filling out surveys that administrators create. Administrators have options to add text, voice, dot placement on map, and geolocation questions. Voice questions are transcribed and translated into English, and all responses are viewable in charts and maps on the platform in the “Summary” section. If the administrator wishes, topic word bins can be created to classify text and voice responses into specific categories. Administrators can export data in CSV format as well as generate API keys to access data via REST API. Regarding geolocation, administrators can select one of two options: collecting the general geolocation via IP address of the respondent’s device, or precise geolocation via mobile phone geolocation access.
Operational capabilities that can be designed into Ella to be captured through a smartphone include the following.
Rapid survey design using application template: Ella can be designed so that non-programmers can rapidly modify a survey, or quickly create wholly new surveys through the use of simple pull down menus. The surveys can offer:
Multiple choice questions;
Location Capture by GPS via satellite and/or cell tower triangulation;
Photo and/or video capture to highlight input (can be multiples); and
Voice Capture — transcribe voice notes into written text in language spoken, and translation services into a common language.
Analytics and the use of artificial intelligence tools to identify key words and common themes, and levels of urgency if utilized when 9-1-1 systems are overloaded or unavailable.
Ability to re-issue surveys as the situation on the ground changes, or when a data refresh is required.
Collect information and intelligence from people within a disaster zone or other area of interest.
Support communications between first responders in the field, disaster response managers, and people caught within a disaster zone: Ella can allow response managers to transmit guidance to all those within a disaster area, or to specialized groups such as those evacuating using vehicles or those identified to be in immediate threat.
Support communications between different teams of responders dispatched to the same or adjoining areas for improved coordination.
A.1.4.2.1. Manitoba Ella (M-Ella)
A specific version of Ella tool was developed for the Manitoba Case Study for DP23.
At the request of the Manitoba team, Ella was aimed at capturing information about businesses that were affected by drought, with a specific interest in understanding the effects of drought on business revenue and employment. The Manitoba Drought Survey aimed to capture key information about the effects of drought on Manitoba businesses by structured questions, photos, voiced responses, and generalized location. Team Manitoba hopes to use this information to document both quantitatively and qualitatively the effects of drought on local businesses and employment to better inform the government about local needs and to design improved support services. It is hoped that the M-Ella application will also be adapted to a wide variety of survey and information exchange needs, each with its own benefits profile.
Figure A.11 — Example mock-ups of the Manitoba-Ella survey
The draft M-Ella Drought survey can be examined in detail here.
At the request of Manitoba, for privacy, respondents were requested to choose their location by one of a list of Forward Sortation Areas instead of using the GPS capabilities of the smartphone.
Photo(s) were requested of natural areas that were important to the business being surveyed.
Voice responses were requested relating to:
factors contributing to changes in revenue noted in previous structured questions;
explanation of the importance of natural water to business; and
description of business changes due to drought.
Use of voice translation and AI: Voice responses would be translated into English and converted into text. The responses would then be analyzed by AI for common words and themes which could then be grouped by business type, postal location, and other factors.
A.1.4.3. Technical standards and infrastructure
The platform survey responses are accessible via REST API for individuals who wish to view and explore the data in other platforms. For individuals who are not interested in external viewing, all data are viewable in the “Summary” tab of the platform, allowing individuals to quickly explore responses in real-time without external software.
To access the survey creation page (administrators) as well as the surveys themselves (respondents), internet access is required. Surveys are mobile responsive and can be accessed via desktop or mobile. All user information and data are housed in Firebase (the exception being the pilot in Canada, in which the data are housed on a server instance that is geographically located in Canada).
There are some constraints and considerations for use of the Ella tool.
Persistent Communications: For Ella to be effective in collecting data, it requires wireless communications which can be a challenge in a disaster situation as telecommunication infrastructures can be limited or destroyed.
Smartphone Battery Life: Similarly, if disaster areas do not have access to electric power due to the disruption, there could be limitations to using the phones without recharge facilities.
Standardized Smartphone Capabilities: It would be important to make sure that all smartphones adhere to standards which would ensure that the data collected would be compatible and easily integrated for analysis.
A.1.4.4. Benefits
The Ella application was designed to be user friendly and easily modifiable by non-technical personnel. Individuals who are comfortable using smartphones for conversations, texting, and photographing should have no difficulty becoming comfortable with the application. Ella applications should be easy to use by citizens caught within a disaster area, responder teams within a disaster area, by disaster managers at operations centers, or from vehicles. User friendly dashboards and analytics can be designed for use both by citizens and by responders, while more technical personnel can be provided with more sophisticated outputs.
There are many ways of using an Ella-type applications to track individuals and groups of citizens threatened by a disaster event and leverage response teams and resources to protect them, whether the individuals or groups remain at home, traveled to a safe place, or are still on the road. Information can be regularly re-calibrated if there is a significant shift in fire direction and speed of spread. Other newly arising conditions impacting safety can also be included.
All individuals within the disaster zone, responding to the disaster, or managing the disaster, can make use of the information and communications enabled by an Ella-type application. Conducting pre-event exercises will be essential to ensure that Ella can be used with maximum effectiveness. Separate Ella groups can be formed among specialized teams of responders including medical personnel, fire fighters, and those responsible for coordinating evacuation.
A.1.4.5. Collaborations
The GISMO/Basil Ella Team was in touch with a number of other DP23 participants including:
USGS GeoPathways Team to discuss the citizen science solutions they were both developing within DP23;
HSR.health Team to explore the potential of using Ella to support measuring population vulnerabilities to fire and smoke conditions; and
StormCenter’s GeoCollaborate although not a participant in DP23, discussions continued with StormCenter as StormCenter offers tools useful for the sorting, combining, analysis, and distribution of data and data products across the entire response community including citizens caught within the disaster area.
Information about Basil Labs can be obtained from their website. NYC GISMO can be contacted by emailing Alan Leidner at leidnera@nyc.rr.com.
A.1.5. Wildfire Mobile App Developed by USGS/GeoPathways
A.1.5.1. Introduction
Combining in-situ data and EO through citizen science, this mobile app collects field data, refining EO validation for wildfire-prone areas. This enhances decision-making using machine learning for wildfire mitigation.
A.1.5.2. Description
The FLORA Wildfire Mobile App integrates crowdsourced and EO data to understand wildfire vulnerability. The cross-platform application invites users, like hikers and homeowners, to provide on-the-ground imagery of vegetation.
Figure A.12 — Example of how the FLORA Wildfire mobile app operates
Processing the input imagery data, the app identifies potential wildfire fuel based on the 0-5 scale provided by the National Fire Danger Rating System.
Users send imagery through Esri’s ArcGIS QuickCapture for further processing in Amazon Web Services, where the partner’s APIs, i.e., Pl@ntNet, PlantID, and Trefle.io, are all used to calculate the fire rating.
Once the vegetation is processed, the tree imagery is pipelined to community-supported OpenStreetMaps (OSM) as tree nodes insides changesets to better visualize the real world.
Figure A.13 — Sample screenshots of the front end of the FLORA Wildfire mobile app
Set for late 2023, this event will be hosted virtually and invites community data input, augmenting wildfire risk data. Users will use OpenStreetMap US Task Manager for the mapping projects and will navigate to machine-identified areas, capturing photos assessing fire risk. These photos will be processed through a cloud-based machine learning model which evaluates ignition risks.
For accuracy, the app uses the NASA MODIS sensor and ArcGIS geolocation, designating areas for citizen documentation.
A.1.5.3. Benefits
This approach refines decision models by merging satellite and ground data. Validated data assist professionals in targeted wildfire mitigation during droughts, guiding actions, and safe zone identification.
A.1.5.4. Collaborations
To develop these resources USGS/GeoPathways worked with US Forest Service, Federal Geographic Data Committee, NASA, ESRI, AmeriGEOSS, NOAA, GeoPathways Peru, Google, USDA, Microsoft, Voyager Search, Pl@ntNet, PlantID, and Trefle.io.
The links to the app and event described here are:
A.1.6. Wildland Fire and Drought Immersive Indicator Visualizations Developed by USGS/GeoPathways
Work on this component is at an early stage and this section outlines what is planned to be delivered.
A.1.6.1. Description
This deliverable offers ARD and DRI to enhance comprehension of drought and wildfire management across varied spatial-temporal scales. It has the two following elements.
Disaster Augmented Reality Simulation Table (DARSIM) — DARSIM modernizes traditional simulation tables, replacing bulky sand models with a portable, data-integrated solution, designed in response to wildland firefighter needs.