OGC Disaster Pilot 2021

Dean Hintz
Dean Hintz
  • Updated

FME Version

  • FME 2021.2


Disaster Pilot 2021 - Red River Flood Scenario Pilot Overview

Supporting open standards is a very important part of our vision at Safe Software. This is because open standards are one of the key ways in which the integration and harmonization of data across disparate systems can be made easier. Ultimately this helps support enterprise wide data sharing and automation, and breaks down barriers between data silos. Because of this vision Safe Software has been a long time partner with the OGC and has participated in numerous OGC projects such testbeds, hackathons, workshops and conferences. Over time we have found that participating in OGC pilots is a good way to communicate with others about our support for OGC standards specifically and data integration and automation on the whole. We have also found it a useful context to interact with a diverse and ambitious user community, struggle with tough problems, and feedback improvements to our standards support so we can make FME even better.

The OGC Disaster Pilot 2021 was an opportunity to test end-to-end information flow related to all phases of disaster management, with an emphasis on first responders and other end users. The pilot focussed on 3 principle application scenarios: Flooding in the Red River Valley, Pandemic in Louisiana, and Landslides in Peru.

2011 Red River Flood in Manitoba, Canada

One of the most common types of flooding is river flooding, where the 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. A typical spring thaw occurs from the middle of March across southern portions of the basin and mid or late April across the north.

This Case Study has focused on creating recipes for an idealized data value chain ending with DRIs for the best transportation routes to avoid flood water. The value chain starts with observations of flooding using both river gauge measurements and satellite EO observations. These datasets are combined with mathematical algorithms and a Digital Elevation Model (DEM) which describes the height of the land, to produce two different approaches for the creation of a flooded area ARD.



Model based ARD

This first approach uses the river gauge measurements, and overlays these onto a DEM and then a computer model predicts which areas would be expected to be flooded with those river measurements. Figure 3 shows an the output grid for the area of the Red River Basin where the model technique developed by RSS Hydro has predicted the flooded area using data from 2011.

Area of 2011 flooding, coloured light to dark according to flood day (start to end) overlaid on DEM (shades of grey). Flooding model output from RSS Hydro and DFO.


The above ARD grids of flooded areas are based on historic measurements, but they can be useful indicators of how flooded has occurred in the past, and what the disaster teams can expect if similar water levels or rainfall are experienced again in the future, enabling them to get on the front foot in any response.

Flood Contours IRD with FME

As well as being used directly, the flooded area ARDs move along the data value chain and are used as input data for the next stage which transforms the data into Flood Contour IRD - integration ready data.

This approach has been developed by Safe Software using the FME platform which is a model based spatial data transformation and integration tool. Taking the input ARDs of modelled flood grids and EO ARDs, these are transformed into flood vector contour IRD, where areas with the same water depth are classified. This step is necessary as the transportation routing DRI, which is the next step in this data value chain, requires flood depth estimates to work, not just the area or extents flooded. The flood water is categorized into five depth categories: 0.1 meters, 0.3 meters, 0.5 meters, 1.0 meter and above 2.0 meters.

Given the sensor and computational tools used, both EO and flood model output datasets tend to generate grid observations or time series. However, many analytic and GIS tools more readily work with vector datasets. This is why the ARD to IRD approach for flood impact analysis was designed to convert raster flood depth grids to vector flood contour polygons to better support downstream integration required for the IRD. The figure below shows an example of the workflow used for the FME part of the ARD to IRD / DRI recipe for this flood transportation indicator.


FME approach for converting flood area grid ARDs to flood contour IRD

To improve accessibility, the result was saved as an OGC GeoPackage, which makes it easy to share with other components as well as to use offline. The IRD Flood Contours were then used as input data for the creation of the transportation routing DRI. The figure below shows flood contours in the Red River Valley south of Winnipeg which was used as the input data for the transportation route DRI.

Flood Contour Geopackage showing flooded areas south of Winnipeg by date, as displayed in FME Data Inspector.

To better support online integration, the flood contours were also provided to the HSR.Health GeoNode instance, which makes this data available to other components via OGC services such as WMS and WFS. The figure below shows an example of the flood contours for the Red River Flood from 7th April 2011.

HSR Health Geonode with Flood Contours for Red River flood from 7th April 2011 loaded from FME workflow outputs.

DRI - Decision Ready Indicators for Flood Aware Transportation Routing

The approach for calculating the transportation routing DRI implemented by Skymantics and it uses the flood contours depths to determine what roads are impacted by the flooding, and how deep the water is. The user has the potential to specify what depth of flooding is passable which is important for different vehicles that could be involved; for example, a large lorry or 4X4 would likely be able to handle deeper water than a motorbike or small car. The user enters the starting position and the intended destination, and the routing software works out the best route to take to avoid the flooded routes. This is dynamic software which can be updated as flood water rises or falls to offer the best route at that particular time.

The diagram below demonstrates the process. Top left shows the optimal route between Ste. Agathe and Ile des Chênes, two places in Manitoba that are approximately 30 km apart. Top right shows the flood contours produced in the process above for Winnipeg and surrounding areas. Bottom left is the user specified elements, which in this case allows a maximum flood depth of 0.2 m for public vehicles and 0.4 m for emergency vehicles. Finally, in the bottom right is the new optimized route taking account of the flooding and user requirements.

.Routing DRI. Showing optimal route, flood contours, user variables and revised route. Produced by Semantics.

The routing software uses the flood contours, topography of the area and a road data set to find the roads which would be impacted by the flood, and then determines where the road is passable, passable only by emergency vehicles or impassable. It uses these determinations to create a revised route between the two locations.

This application is important for response teams trying to get to situations, evacuation routes or the delivery of supplies. In addition, it is possible to identify roads that should be closed so that teams can go and close the road and update navigation apps, which should prevent more people using the road and getting stuck in their car in the flood water.


This Case Study has focused on flooding within the Red River Basin, Canada. The Pilot generated several ARD datasets using model predictions, satellite observations and flood contours and then developed series of DRI recipes.  The Pilot then used the recipes created to produce a data value chain focused on the routing of emergency vehicles.

This Case Study has shown that it possible to deliver the value chain to create the example DRI, however it has also identified some issues and limitations around automating the process. The next steps will be to develop this workflow further to move it closer to real time which would be required within a disaster scenario to allow decision makers and field responders to work together.


Red River Flood Impacts Demo

Publicly accessible live demo allowing user to explore flood impacts based on the flood contour time series generated from the Disaster Pilot Red River flood scenario. Note that accessibility times may be limited by server up time.

Note that this pilot was hosted and administered by the OGC and the OGC has rights to all the designs and products that were developed in the context of the pilot, with the exception of previously registered patents and copyrights.

Was this article helpful?



Please sign in to leave a comment.