2.1.  Terms and definitions

2.1.1. ARD

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

2.1.2. CRS

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

2.1.3. DRI

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

2.1.4. Indicator

Indicator —  An indicator is a realistic and measurable criteria.

2.1.5. Lidar

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

2.1.6. GeoNode

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

2.1.7. GeoPackage

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

2.1.8. GeoServer

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

2.1.9. JSON-LD

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

2.1.10. Radar

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

2.1.11. SAR

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

2.2.  Abbreviated terms

CAMS

Copernicus Atmosphere Monitoring Service

CEOS

Committee on Earth Observation Satellites

CNES

French Space Agency

COG

Cloud Optimized GeoTIFF

CONIDA

National Commission for Aerospace Research and Development’s, Peru

CRED

Centre for Research on the Epidemiology of Disasters

CSA

Canadian Space Agency

DEM

Digital Elevation Model

EGS

Natural Resources Canada’s Emergency Geomatics Service

EMS

Copernicus Emergency Management Service

EO

Earth Observation

EODMS

Natural Resources Canada’s Earth Observation Data Management System

ESA

European Space Agency

ESIP

Earth Science Information Partners

FEMA

Federal Emergency Management Agency

GIS

Geographic Information Systems

GISMO

New York City Geospatial Information Systems & Mapping Organization

HRD

High Resolution Data

INSPIRE

Infrastructure for Spatial Information in the European Community

IRD

Integration Ready Data

JAXA

Japan Aerospace Exploration Agency

JSON_LD

JavaScript Object Notation — Linked Data

NASA

National Aeronautics and Space Administration, US

NCEI

National Centers for Environmental Information, US

NOAA

National Oceanic & Atmospheric Administration, US

NRCan

Natural Resources Canada

NRT

Near Real-Time

OGC

Open Geospatial Consortium

ORL

Operational Readiness Levels

SAR

Synthetic Aperture Radar

SDI

Spatial Data Infrastructure

SEDAC

Socioeconomic Data Applications Center

SST

Sea Surface Temperature

STAC

SpatioTemporal Asset Catalog

USGS

US Geological Survey

WCS

Web Coverage Service

WFS

Web Feature Service

WHO

World Health Organization

WMO

World Meteorological Organization

WMTS

Web Map Tile Service

3.1.  Disasters

Although there are varying definitions as to what constitutes a disaster event, the general consensus is that the number of these disaster events are increasing over time. In September 2021, the World Meteorological Organization (WMO) released ‘The Atlas of Mortality and Economic Losses from Weather, Climate and Water Extremes (1970–2019)’ calculated using data from the Centre for Research on the Epidemiology of Disasters (CRED) [7]. The report describes that over the last 50 years, 50% of all recorded disasters, 45% of related deaths and 74% of related economic losses were due to weather, climate and water related events, translating to 2.06 million deaths, and US$ 3.6 trillion in economic losses [8]. In addition to CRED, the World Health Organization (WHO), Public Health England, and the United Nations Office for Disaster Risk Reduction (UNDRR) also contributed to the report.

The report also indicates that the number of disasters has increased by a factor of five over the 50 year period, although they acknowledge that this is partly due to improved reporting. However, the WMO also noted that the number of weather, climate, and water extremes are increasing and will become more frequent and severe in many parts of the world as a result of climate change.

Looking specifically at 2020, excluding the COVID-19 pandemic, there were 389 disaster events recorded by CRED. These events resulted in 15,080 deaths, impacting 98.4 million people, and creating economic losses of at least US$ 171.3 billion. During the same period, the COVID-19 pandemic resulted in almost two million deaths, 90 million confirmed cases and impacted many more, creating trillions of dollars of economic losses.

CRED, who have maintained a database of these disaster events for over 30 years, and define a disaster as ‘a situation or event that overwhelms local capacity, necessitating a request at national or international level for external assistance; an unforeseen event that causes great damage, destruction and human suffering.’ The figures for 2020 were higher than the average number for the previous decade, which was 368, although slightly lower than the 396 recorded in 2019. For comparison, reports from a global insurance and reinsurance company showed 2020 losses from natural hazards increased by 25% from 2019 [9].

According to CRED the most common type of disaster in 2020 was flooding with 201 events, 23% higher than the average for the previous decade, followed by storms, landscapes and earthquakes. The geographical spread shows that 41% of disaster events occurred in Asia, with 23% in the Americas, 21% in Africa, 10% in Europe and 5% in Oceania. During 2020, flooding resulted in the deaths of 6,171 people, impacted 32.2 million people and created economic losses of US$ 51.3 billion; storms resulted in the deaths of 1,742 people impacted 45.5 million people and created economic losses of US$ 92.7 billion; landslides resulted in the deaths of 512 people, impacted 200,000 people and caused economic losses of US$100 million.

2021 has also seen significant disaster events with wildfires in various parts of the world, the heat dome over North America, flooding in China and Europe, Hurricane Ida impacting Louisiana in the USA, and the earthquake in Haiti to name a few. For information, by the start of 08 October 2020, there had already been 18 weather/climate disaster events reported by the US National Centers for Environmental Information (NCEI) with losses exceeding $1 billion each, to impact the United States in 2021 [10]. These events included 1 drought event, 2 flooding events, 9 severe storms, 4 tropical cyclones, 1 wildfire, and 1 winter storm. These have resulted in 538 deaths and had significant economic impact on the communities impacted. For comparison, the 1980–2020 annual average is 7.1 events and for the last five years the average is 16.2 events.

The last two years have been challenging for the world, and while these simple numbers give an outline of what has happened in terms of disasters, the pandemic will have also influenced the information in terms of potential underreporting, difficulties in determining the causality of losses, and the multiplying effect of having a disaster during a pandemic, which is likely to exacerbate all types of impact and losses.

While the number of disaster events continues to rise, the WMO report does have an element of hope: That the death toll from the weather, climate and water extremes have fallen significantly over the last 50 years due to the introduction of early warning systems. From 50,000 deaths a year in the 1970s, to 20,000 a year in the 2010s, the world has become better at reducing the number of lives lost to disaster events.

There is still more that can be done and it is important that all types of industries come together and do whatever they can to support the people and communities affected by disasters. This Pilot aims to add value and demonstrate benefits to the continuing effort to save more lives and reduce the impact of disaster events.

4.1.  Gaps With Using Geospatial Data

There are a number of challenges with using geospatial data within a disaster response situation, and most relate to the need to have rapid access to the right information:

• Formats

  • Geospatial datasets often come in a variety of formats, and to integrate this variety often requires some, or all, of the datasets being converted to a format that can be managed within the GIS.

• Time and Spatial Resolution limitations

  • Optical satellite sensors, which operate like cameras or your eyes, cannot see through clouds. This makes it more difficult to get accurate information about what is happening on the ground during floods or storms. Although microwave data can see through the clouds, this is more complicated data to use.

  • Satellite images are often only acquired over an area every few days as the satellite orbits the Earth. Some constellations can capture an image every day. However, this is still only a snapshot each day and not real-time information. For example, a satellite might completely miss a flash flooding event as the water can rise and drop between when the satellite images acquisitions.

  • Satellite images are observations of what has happened. Depending on when the imagery was acquired the actual situation on the ground may be different to what the image shows. This is called data latency.

  • Spatial resolution of satellite images is limited. While some satellites can see items on the ground which are less than a meter in size, others can only see things that are bigger than 15 or 30 meters. This may mean the images may not be able to detect the level of detail on the ground that the disaster responders require.

• Infrastructure Availability

  • Some satellite images such as those from Landsat or Copernicus are free for anyone to use, while others, such as those from commercial sources, are not free or have restrictions placed on their use. Unless there is an agreement in place prior to an event, securing funding and purchasing such images in a disaster is difficult. So some data may not be available. Although there are various Disaster Charters within the industry whereby certain operators may make their data freely available when a disaster occurs, it can still be challenging to get permission to have access to the data.

  • Similarly, the cost of GIS software and licenses may also limit the number of people who can access the data. Available free GIS software can help mitigate this limitation.

• Synthesizing large volumes of data

  • Satellite images and maps are large data files and in disaster situations field responders are likely to be working with poor internet and phone signals. They simply may not be able to download the information they need. Processing the data into smaller files is helpful to overcome this issue.

• Extracting useful information from satellite images is not straightforward and requires a level of subject matter knowledge and expertise.

• Equally interpreting data from satellites or models can take knowledge and experience. For example, models predict what might happen based on the information they have. This may be very different to what actually happens. It’s important that this element of uncertainty in what models are predicting is understood and communicated.

Put together, all of these issues mean that often 80% of time spent is on accessing and preparing geospatial data for disaster management and response, rather than using it! This includes getting permission to use it, getting it into the right format, correcting errors, getting the computing resources to process it, etc.

Therefore to address these issues, the aim of the Pilot is to provide Analysis Ready Data (ARD) for people who have the skills to use it, together with Decision Ready Indicators (DRI) from which decisions can be made and actions taken. The aim is to provide the right information to the right people at the right time in an easy-to-understand format to enable informed decisions on disaster management and response activities to be made.

7.1.  Step 1: Preparation of Foundation Layers

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

These foundation layers are critical as they form the framework for the ARD and DRI to be displayed, and without these layers, it will be a struggle to analyze, interpret and transform the additional data into decisions and actions. For example, if the indicators show an area of a city is going to be flooded, the response will be very different if that area is a park, a residential area or a hospital.

Care and attention must also be given to the currency, accuracy and intended use of the data acquired. For example, applications such as landslide or flood modelling and impact analysis require high resolution elevation models which may be difficult to acquire depending on the spatial data infrastructure available for a given region.

The Pilot has not specified a particular standard for the Foundation Layers, as there are a number of worldwide standards already available. While they are all different, there is considerable crossover within these standards and many of the layers are very similar. Current example foundation layer standards include:

• United Nations Global Geospatial Information Management Fundamental Geospatial Data Themes which has 14 themes.

• Infrastructure for Spatial Information in the European Community (INSPIRE) Implementing Rules on Interoperability of Spatial Datasets & Services which has 34 data themes in 3 groupings.

• USA National Geospatial Data Assets/Framework Themes which has 18 themes.

In addition, although not a standard, the OGC’s Health Domain Working Group has produced a Health Spatial Data Infrastructure Concept Development Study Engineering Report looking specifically at what Foundation would be useful in a health emergency. This report identified 8 spatial datasets, 12 local government datasets & 7 national datasets which would be useful to have as foundation and background layers.

Using any of these standards as the basis for identifying foundation layers would be a beneficial step, high resolution data (HRD) to improve accuracy. The selection of a preferred standard may be helpful in the future.

One aspect of data preparation that should not be underestimated is the amount of work involved to acquire the source data for a given disaster response effort. A typical response involves a wide range of datasets that must be researched, accessed, filtered to the area of interest, and transformed into a form suitable for the user’s application environment. This process is sometimes called ETL (extract transform and load), and can involve significant effort in terms of data wrangling. Ideally this effort is supported by spatial data infrastructure based on open standards, data services via open Application Programming Interfaces (APIs) and domain specific conventions. More commonly, the reality is more of a mix, so often significant time and effort is required to procure the required datasets and render them into a form that is usable within the user’s disaster response application. The importance of these standards in the context of disaster response is discussed in the next section.

Typically there are a range of tools available to support this data extraction, integration and conversion process. These include both specialized data integration platforms or middleware, and custom applications developed with open source tools and libraries such as GDAL and OGR. For this pilot, the FME spatial data integration platform from Safe Software was used to perform many data extraction and transformation tasks. This included workflows where proprietary source files were read and written to open standards formats such as OGC GeoPackage and GeoJSON [4] for use by other components (see Figure 2). FME was also used to load datasets onto the pilot geoportal: GeoNode, which in turn hosted these datasets for download or delivery via OGC-conformant interfaces such as those implementing the Web Feature Service (WFS) standard (using GeoServer).

Besides basic format conversion, key aspects of any data integration platform is the ability to perform geometry and schema transformation. The native OSM schemas are complex and nested, so FME was used to flatten this into a more relational or GIS friendly structure. Time series raster datasets were converted to vector features and loaded into GeoPackage tables to make them easier to integrate with other GIS workflows within downstream tools. Finally coordinate transformation is usually required to bring the application datasets into a common reference frame.

Figure 2 — FME data integration platform - OSM and GeoJSON to GeoPackage foundation data loader

7.2.  Step 2: Understand and Implement Standards

To be able to rapidly integrate and transform data into useful decision-ready information, it’s necessary to eliminate all the unnecessary challenges of data management. This will include aspects of data formatting, visualization methods, symbols to use on maps, etc. This is critical to cut the time it takes for data to be ready to be used for decisions and actions. The use of standards will enable these processes to happen effectively and efficiently.

Without such 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. The standards will also help non-technical decision makers, who require trusted data to be used to drive decision making, but cannot find what they need, due to the varied and complex semantics of hazards and disasters.

Within the Pilot, a number of key standards were identified as being important for user readiness. These are described below with technical examples of such standards.

• Ensure that data and imagery use formats that can be easily used, integrated and visualized by any GIS, such as Cloud Optimized GeoTIFF (COG).

• Ensure that when publishing geospatial data, it is done in a structured way to best support web-based searching. For example, using JavaScript Object Notation — Linked Data (JSON-LD).

• Generation of catalogs and self-describing data sets which will help users find and understand the accessing and processing of data, for example, GeoPackage and SpatioTemporal Asset Catalog (STAC) [5].

• Platforms which visualize and communicate information should do so using standard formats such as Web Coverage Service (WCS)[6], Web Feature Service (WFS)[2] and Web Map Tile Service (WMTS)[3]. These standards also make the data much more shareable across platforms

7.3.  Step 3: Utilize and Implement Indicators and Supporting Indicator Recipes

Once the required foundation data layers are assembled, the next step is to determine what decision ready indicators are required to support disaster managers and responders in the field. As described above, DRI are built on a foundation of ARD, and enriched by the context of foundation data described in Step 1 above. There can also be Integration Ready Data (IRD), which is an intermediate step between ARD and DRI, that could include flood extents and disease density.

While data providers may publish a set of primary ARD, IRD or DRI, often there is the need for the disaster response users to take this primary information and develop secondary indicators more closely calibrated to day to day needs of their disaster response mission.

For example, the data provider may publish disaster extents (flood or fire extent) plus areas for evacuation or submerged roads. The disaster response user with some GIS skills may need to take this information and develop more precise information as to what areas to evacuate first (hospitals and high density residential), what areas to protect (critical infrastructure) or what routes may be passable for specific types of emergency vehicles. Also disaster managers often benefit from composite indicators and dashboards that combine a range of indicators and IRD to build a more comprehensive operational picture of the overall disaster and corresponding response efforts.

The Provider Guide describes in more detail the data value chain that was developed in the context of this pilot to take source datasets, process them into ARD, IRD and ultimately DRI to drive the outputs described below. Recipes describe the specific procedure for combining source foundation layers, dynamic observations related to the disaster context and analyzing this to produce ARD, IRD and DRI. However, even from a user perspective, the datasets published by data providers can often be seen just as a starting point.

For this pilot, several key indicators and associated recipes were developed related to flood severity, landslide risk and pandemic impacts. For example, for the flood scenario, flood model grid outputs from RSS Hydro were processed into vector flood contours using FME and stored in GeoPackage IRD. Skymantics was then able to take this IRD and compute indicators about transportation routes taking into account flood depth not just extents. In addition, users could utilize this same flood depth data to generate other related indicators, such as areas to prioritize for evacuation.

Key to this is the understanding that often one indicator may be used to support other indicators downstream. Also, the development of effective indicators and supporting IRD often require frequent feedback from users, and responsiveness from data providers, to ensure that the data and information being provided is suitable and tuned to the needs of the end users. Finally, any recipe implementation should use approaches that promote reuse and automation to the extent possible. In this way rapidly evolving disasters can be met with timely indicator updates and associated response actions. A model based, reuse and automation orientation also makes it more practical for tools and recipes to be applied to new contexts. In this way, the disaster response community as a whole can benefit from the development of these indicator-based tools and systems. Note that ARD, IRD and DRI in the context of this pilot are described in more detail in the Clause 8, and in the adjoining annexes.

7.4.  Step 4: Determine the Method For Delivering Outputs

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

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

The key element is that the user organization has a solution where they can upload the decision-ready indicators for users to access. There is no single answer to this question and the preferred solution will depend on the organization’s infrastructure, financial pressures, technical skills, etc.

Within the Pilot several external platforms were tested including:

• GeoCollaborate – This platform, developed by StormCenter Communications offers an option for a cross-platform real-time collaborative environment led by a subject matter expert, engaging with a series of followers who are actually receiving the data on any platform or device. This offers the potential for many people to interact with the same shared information at the same time leading to faster situational awareness and decision making accordingly. The solution can connect any device with an internet connection and a browser, allowing the user to see and interact with the information in real time while also enabling leaders to hand-off control so additional datasets can be shared or turned off. Since the data is not downloaded and saved on everyone’s device it can be used by people on the on-ground with limited bandwidth. GeoCollaborate is not screen sharing but delivers actual cross platform geospatial interoperability to any number of participants wherever they are located. GeoCollaborate can access data from any portal, hub, geoplatform, server or share uploaded data across all follower’s web maps.

Figure 3 shows a screenshot from a GeoCollaborate instance with the leader’s screen on the left, and the follower’s on the right. The image itself is sharing data for Rimac River in Peru, and includes a flood extent and clinic location datasets produced by HSR.health via their geoplatform in real-time.

Figure 3 — Data for Rimac River in Peru including flood extent and clinic locations produced by HSR.Health, visualized via GeoCollaborate

• GeoNode Platform – The second approach is to use GeoNode developed by GeoSolutions which is a web-based application and GIS platform for displaying spatial information. In this case, the GeoNode instance supplied by GeoSolutions is controlled by HSR.health who can use it to display various data layers which have been accessed using open standards, and similarly it can equally export data to other platforms. Figure 4 is an example from this platform.

Figure 4 — Example Medical Supply Needs Index Supply Routes with and without a flood event during 2017.

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

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

• All possible users have, and know, any username and passwords or similar, required to access the external system.

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

It is acknowledged that similar points will be relevant to in-house solutions. The key element is that the chosen platform itself should support the data standards which will be used by the data providers to ensure that the indicator and data sets will be portable between platforms.

7.5.  Step 5: Operationalize the Disaster Response

Simply setting up a disaster response system is not sufficient, everyone involved needs to understand what sort of decisions will need to be taken for a disaster, and therefore what information, indicators or triggers the disaster response team will want. Readiness means that the solution is operational.

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

Users will need to consider the indicators available to them and determine whether they are sufficient, whether important indicators are missing, any key local issues that need to be addressed, etc. While some generic indicators will be common across geographical areas, it is possible that specific locations will need additional indicators or data. Any gaps will need to be discussed with the data providers to find a solution to provide the information needed.

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

7.6.  Step 6: Test

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

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

8.1.  Raw Data

This section summarizes the key raw data sources that have been used within the Pilot.

8.2.  Analysis Ready Datasets (ARD)

As described earlier, the raw data is processed by providers to create ARD’s, which can be interrogated and integrated with other datasets, and visualized within a GIS. This processing will achieve a variety of aspects including removing errors and applying corrections for accuracy; compiling, classifying and combining information into a better dataset; transforming the data by applying mathematical formulas to the data to develop a derived dataset, and implementing standards on the data to improve its ability to be integrated, etc.

As highlighted earlier, some of the ARD’s will be specific to the type of disaster involved, and the three Case Studies in the appendix to this guide will give details of the specific ARD’s used in those cases. Some examples of the ARD’s used within the Pilot include:

• Land Use and Land Cover maps identify how the land is being used.

• Water maps from EO showing where floodwater is.

• Flood risk models indicate what areas have flooded in the past or could be flooded in the future.

• Pandemic Transmission Risk Index that identifies the current risk of the spread of COVID-19.

• Leveraging the responses to the voice-activated surveys using Artificial Intelligence to pull together the common themes and information to help prioritize the needs from the public or first responders, and categorize what to send and where to send it.

8.3.  Decision Ready Indicators (DRI)

DRI are created using a set recipe which pulls together one, or more, ARDs to create an indicator of action and/or decision in relation to a disaster situation. The use of a recipe is to ensure that consistency is achieved for the DRI, to give confidence to the people using them to make decisions that the information can be relied upon.

The recipes will combine one or more specific datasets and have various rules for action applied to resulting output, and some decisions will also have a risk assessment or similar element attached.

Although recipes and indicators may vary from disaster to disaster, by establishing them within a consistent framework that includes their applicability timescale (short-term predictions and impacts to medium and long-term predictions) and type/geospatial extent of the disaster, there will be a commonality.

Some example DRIs include:

• Flooding over roads can determine the roads to restrict access to or close, or can help decide safe routes for evacuation or medical supply delivery routes.

• Flooding around buildings can help decide which buildings need to be evacuated.

• Medical Supply Needs Index shows the need for medical supplies based upon the spread of a pandemic and the number of healthcare workers, supply utilization and burn rate.

Further details on DRIs can be found in the individual Case Studies, which specify the individual indicators developed within the Pilot.

10.1.  Standards

To deliver the envisaged solution both Providers and Users need to implement and use agreed-upon technical standards to allow the rapid sharing, processing, integration and visualization of data. Standards have been used within the Pilot, but a number of areas where further agreements may be required have been identified:

• Agreeing to minimum content within the Foundation Layer framework.

• Agreeing to standard symbols, colors and consistent identification of features on imagery and maps.

• Agreeing to a process to identify what can be trusted data within the solution, including what is good enough.

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

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

10.2.  Data, Analysis Ready Datasets & Decision Ready Indicators

The Pilot focused on three disaster scenarios and has developed some ARD and DRI for those scenarios. This work needs to be expanded in terms of both individual disaster types and the interaction between disasters and other events. In addition, a number of ideas were not fully tested or completed and would benefit from further investigation. Therefore, suggested next steps are:

• Looking at more disaster scenarios such as hurricanes, wildfires, drought, and food security.

• The ARD and DRI solutions developed within the Pilot need to be tested beyond the three Case Study areas to understand whether they are applicable worldwide or whether adjustments need to be made to enable them to operate internationally.

• Looking at the interaction between disasters and other events:

  • Impact that climate change is going to have on the future of disaster scenarios.

  • Human impact on disaster scenarios, for example, the different responses for varying depths of flood water.

  • Interplay between disasters and the immediate, subsequent and long-term impact on the health of the affected population.

  • Potential for zoonotic crossover where pathogens move from animals to humans.

• Creation of a Health-Disaster Vulnerability Index that conveys the situation on the ground.

• Further investigation on the integration of EO and Health data. While initial concept modelling was undertaken during the Pilot, integrating the data was not fully achieved.

• Developing a better catalogue of satellite EO data and understanding the data that is available, including both temporal and spatial resolutions.

• The Pilot used EO data which are observations together with models that are predictions. The next stage would be to consider moving into forecasting.

• Consider engagement with the Insurance industry on an open standards approach to bring their data into the overall solution.

10.3.  Technical

The Participants successfully delivered prototypes and achieved many successes. However, there is still a lot of technical progress that needs to be made. The suggested next steps include:

• The value and importance of Spatial Data Infrastructure (SDI) and establishing National SDI’s to support disaster readiness.

• Agreeing to an approach on the front-end visualization and/or data sharing tools in terms of preferred or required capabilities, using either open source, commercial or existing options, etc. This is not about defining a single technology solution for users, but ensuring that the minimum requirements are set out to enable them to receive, process, visualize and share information effectively.

• Go beyond the Pilot and search out other technologies that may already exist to enable environments like real-time data sharing and collaboration across platforms, and give users the opportunity to leverage these within any future vision.

10.4.  Preparing for Readiness

The Pilot has been clear that in order for data to flow efficiently between providers and users extemporaneously everyone involved needs to be ready to participate before any disaster scenario strikes, and this requires a number of procedures, processes and agreements to be established for users. The following are suggested as useful next steps in moving towards readiness:

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

• Governments support the FAIR principles to improve user readiness

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

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

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

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

• Training for decision makers such that they can understand what the data is telling them, so that they know what questions to ask before making decisions and to be confident about making decisions based on the information they receive.

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

Finally, on readiness, the Pilot identified a number of procedural suggestions for local or national Governments that could be beneficial when responding to a disaster. While these are not fully within the mandate of OGC to develop, it would be worth engaging officials in discussions to progress aspects such as:

• Establish an after-action review process for any geospatial data used within a disaster scenario, to highlight what specific datasets were used to improve understanding of what key elements of information are needed for decision making.

• Looking at how best to use the expanding population of remotely piloted drones. Satellite EO data has limitations that could be supplemented by drones, but there needs to be a clear plan so that drone operators don’t fly into restricted airspace or interfere with official efforts. Instead, they should be officially approved and registered as remotely piloted drones who could then provide valuable data.