2.1.  Terms and definitions

2.1.1. ARD

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

2.1.2. CRS

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

2.1.3. DRI

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

2.1.4. Indicator

Indicator —  An indicator is a realistic and measurable criteria.

2.1.5. Lidar

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

2.1.6. GeoNode

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

2.1.7. GeoPackage

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

2.1.8. GeoRSS

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

2.1.9. GeoServer

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

2.1.10. JSON-LD

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

2.1.11. Jupyter Notebooks

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

2.1.12. Radar

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

2.1.13. REST API

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

2.1.14. SAR

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

2.2.  Abbreviated terms

ACD

Amplitude Change Detection

API

Application Programming Interface

COG

Cloud Optimized GeoTIFF

CONIDA

National Commission for Aerospace Research and Development’s, Peru

EGS

Emergency Geomatics Service

ENSO

El Niño/Southern Oscillation

EO

Earth Observation

EODMS

Earth Observation Data Management System

ESIP

Earth Science Information Partners

ETL

Extract, Transform and Load

FME

Feature Manipulation Engine (Safe Software)

GIS

Geospatial Information System

GISMO

New York City Geospatial Information System & Mapping Organization

HRD

High Resolution Data

IR

InfraRed

JSON

JavaScript Object Notation

JSON_LD

JavaScript Object Notation — Linked Data

LEO

Low Earth Orbit

MTC

Multi-Temporal and Coherence

NAOMI

New AstroSat Optical Modular Instrument

NIR

Near-InfraRed

NOAA

National Oceanic and Atmospheric Administration, US

NRCan

Natural Resources Canada’s

NRT

Near-Real-Time

OLI

Operational Land Imager

ORLs

Operational Readiness Levels

OSM

OpenStreetMap

RCM

RADARSAT Constellation Mission

SDI

Spatial Data Infrastructure

SRTM

Shuttle Radar Topography Mission

SST

Sea Surface Temperature

STAC

SpatioTemporal Asset Catalog

S3

Amazon Simple Storage Service

TIRS

Thermal Infrared Sensor

VGI

Volunteered Geographic Information

WCS

Web Coverage Service

WFS

Web Feature Service

WKT

Well-Known Text

WMTS

Web Map Tile Service

3.1.  Geospatial Data

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

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

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

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

5.1.  Historic use

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.  Challenges

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

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

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

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

7.1.  Step 1: Understand what the users need

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

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

7.2.  Step 2: Understand and Implement Standards

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.4.  Step 4: Determine The Method For Delivering Outputs

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

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

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

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

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

• GeoNode Platform – GeoNode, developed by GeoSolutions, is a web-based application and GIS platform for displaying spatial information. A GeoNode controlled by 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 Step 2. In addition, it will be necessary to ensure that:

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

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

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

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

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

7.5.  Step 5: Operationalize The Disaster Response

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

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

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

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

7.6.  Step 6: Test

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

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

8.1.  Users & Data

8.1.2.  ARD vs DRI data

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

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

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

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

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

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

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

Figure 2 — Pilot Architecture Overview

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

Sources consider or used within the Pilot include:

• Satellite Earth Observation:

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

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

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

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

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

• Health data:

  • Tracking:

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

    • Large gatherings

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

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

    • Migration of Animals and Insects

  • Measuring:

    • Point-in-time population density

  • Monitoring and monitoring:

    • Evacuation routes, and development of alternate evac routes

    • Health resource utilization within a medical facility

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

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

• Social-political-economic:

  • Administrative boundaries

• Ancillary geospatial:

  • OpenStreetMap (OSM): Buildings and road network.

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

  • Digital Elevation Model (DEM): Shuttle Radar Topography Mission (SRTM) @ 30 m spatial resolution provides global coverage, and several enhanced DEM versions thereof (e.g. 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 Analysis Ready Data (ARD) format, is ingested into cloud-based storage areas from where it can be transformed into Decision-Ready Information and indicators (DRI).

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

9.2.  Principles/Standards

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

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

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

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

  • Processing has utilized Jupyter Notebooks;

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

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

• Visualization:

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

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

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

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

10.1.  Provider Success and Achievements

The successes at this relatively early stage of development include:

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

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

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

  • traffic routing around flooding (Annex B);

  • health supplies availability (Annex C).

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

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

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

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

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

11.2.  Technical requirements

In terms of an extension of the Pilot:

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

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

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

More broadly:

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

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

• Governments support the FAIR principles to improve user readiness

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

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

11.3.  Going beyond the applications to an international approach

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

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

• Preparing for Readiness:

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

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

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

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

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