Publication Date: 2020-04-27

Approval Date: 2019-11-22

Posted Date: 2019-09-09

Reference number of this document: OGC 19-050

Reference URL for this document: http://www.opengis.net/doc/IP/userguide/19-050

Category: User Guide

Editor: Chen-Yu Hao (Hao), Chia-Cheng Lin (Ricky), Chia-Hui Chen (Rosie), Hsiao-Yuan Yin, Robert Thomas, Terry Idol

Title: OGC Disasters Resilience Pilot User Guide: Landslide - Early Response and Evacuation Under Limited Bandwidth

COPYRIGHT

Copyright © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

Important

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
Note

This document is a user guide created as a deliverable in an OGC Interoperability Initiative as a user guide to the work of that initiative and is not an official position of the OGC membership. There may be additional valid approaches beyond what is described in this user guide.

POINTS OF CONTACT

Name

Organization

Hao, Chen-Yu (Hao)

GIS Research Center, Feng Chia University

Lin, Chia-Cheng (Ricky)

GIS Research Center, Feng Chia University

Chen, Chia-Hui (Rosie)

GIS Research Center, Feng Chia University

Yin, Hsiao-Yuan

Debris Flow Disaster Prevention Center, Soil and Water Conservation Bureau, Taiwan

1. Introduction

Taiwan is prone to typhoons and debris flow disasters. The average annual rainfall is more than 2.5 meters, which is three times the world average rainfall. One notable case was typhoon Morakot which happened in 2009. The rainfall reached 2.5 meters after 80 hours. That’s the average yearly rainfall on the island. During that typhoon, 9,100 people were evacuated. 1,046 escaped from the possible casualties. Unfortunately 673 people could not be saved and passed away. If people want to prevent this kind of event, residents who live near the hazard areas such as potential debris flow torrents need to communicate warnings and evacuation orders sooner and more efficiently. That’s where early response and evacuation under limited bandwidth comes in to play.

This user guide provides guidance for using IoT technologies and OGC SensorThings API to build an early warning mechanism with various systems. It also provides guidance for using Routing API to build an evacuation application under limited bandwidth. These scenarios were stated as the following use cases.

1.1. Use Case 1 - Early responses to potentially impacted residents

Providing early warning system to protect residents who are potentially impacted by landslides and debris flows, so that the residents can receive an early warning and ensure their safety before disasters arise.

1.2. Use Case 2 - Evacuation under limited internet connection

Using Routing API along with GeoPackage and GeoSMS to get a better evacuation route where internet infrastructure is unreliable.

The following chapters describe more details about these use cases.

  • Chapter 2 introduces the simple architecture of the key components and their workflows.

  • Chapter 3 discusses the activities in the use cases, mainly aims at the data flow.

  • Chapter 4 presents special topics such as "right information for the right user", and the detail of the IoT technology in this scenario.

  • Chapter 5 shows the demos of the use cases.

  • Chapter 6 summarizes the conclusions and spotted issues for future opportunities.

2. Simple Architecture

For a better understanding of the use cases, the following diagram explains the key components (see Components diagram).

Components diagram
Figure 1. Components diagram

This diagram includes 4 components in 3 major phases. Phase 1 and phase 2 are for the use case of "Early Response", and phase 3 is for the use case of "Evacuation". The key activities of each phase described as follows.

Phase 1 - Monitoring

The main activities in this phase are collecting data from physical devices. The activities includes the following,

  • Use monitoring sensors to collect real-time data.

  • Connect sensors to IoT platform.

  • Publish sensor data in SensorThings API on IoT platform.

Phase 2 - Analysis and Warning

The key procedures in this phase are data mash-up and data analysis, which are,

  • Mash-up and visualize the collected data, then analyze landslides using rainfall thresholds.

  • If exceeds the threshold(s), the Emergency Operation Center (EOC) will send warnings under its standard operating procedure (SOP).

Phase 3 - Evacuation

This phase describes the technology used for evacuation.

  • Send evacuation warnings to the community in charge.

  • Use OGC Routing API, residents who have installed the evacuation application on their mobile phones can use the routing service to evacuate to the designated shelters.

The data used in these use cases are described as follows.

2.1. Data Providers

The raster and vector data are from various Taiwan’s governmental agencies.

  • Taiwan national map (Taiwan e-Map) from National Land Surveying and Mapping Center (NLSC).

  • Taiwan river data from Water Resource Agency (WRA).

  • Information of monitoring stations from Taiwan’s Soil and Water Conservation Bureau (SWCB).

  • Shelters information from SWCB.

  • Potential debris flow torrents from SWCB.

2.2. Catalog Providers

Warnings will be published by two catalog providers:

2.3. Data Consumers

The use cases define two key data consumers.

  • Residents who live near the hazard areas such as potential debris flow torrents.

  • Administrative staffs of Emergency Operations Center (EOC), who can obtain real-time integrated data and provide an early response to disasters.

3. General Use Cases by User Activity

This section provides details on the activities of the use cases. These activities are a flow of manipulating data with add-on values. As described as follows.

3.1. Publication of data

The use cases focus on the data products of

  • Publishing sensor data by OGC SensorThings API on the IoT platform.

  • Publishing landslide warnings on the EOC platform.

3.2. Registration of data

The data registration on either IoT or EOC platforms is described as follows.

  • Sensors must be registered on an IoT platform using MQTT protocol. For more details about IoT and MQTT, please read chapter Special Topics.

  • For raster data such as basemap, the data is registered using OGC WMS; for vector data such as shelter information, the data is registered using OGC WFS.

  • Landslide warnings are registered on the EOC platform after implementing the warning levels analysis.

  • Warnings are also registered on the open data platforms such as https://data.gov.tw.

3.3. Discovering of data

To discover the data on either IoT or EOC platform, the following methods are recommended.

  • For sensor data:

    • Subscribe a channel on an IoT platform via MQTT.

    • Use SensorThings API to list all the available channels.

  • For landslide warnings:

    • Access the official EOC platform.

    • Join the official social media such as Facebook page and LINE messenger.

    • Receive warnings via cell broadcast or loudspeaker in village by community in charge.

    • Access dataset on the official open data platform.

    • Discover warnings via Common Alerting Protocol (CAP) such as https://alerts.ncdr.nat.gov.tw/.

3.4. Downloading of data

To access/download the data, the following method are recommended.

  • For sensor data:

    • Use SensorThings API.

  • For landslide warnings:

    • Access the official website of EOC platform.

    • Register as an external service. The EOC platform will notify the external service(s) when warnings are published.

    • Download the dataset at platfrom of opendata - https://data.gov.tw/dataset/7284.

3.5. Data Integration

The IoT platform integrates various types of sensors. The EOC platform not only integrates the data from IoT platform but also processes raster data and vector data from different agencies, for more details please read Data Providers.

  • Integrate IoT platform with sensors.

  • Integrate EOC platform with data such as rainfall, river data, sensor locations, potential debris flow torrents, etc.

3.6. Republication of data

The IoT platform has capabilites for calculating and converting the data format from the raw sensor data, and republishing sensor data in SensorThings API format. For more details please refer to the chapter of Special Topics.

3.7. Displaying the data with proper symbology

The EOC platform uses different color & icons to represent different warning levels or physical objects on the map. For more details please refer to Scenarios and Tools Demonstration.

3.8. References

4. Special Topics

This section provides descriptions of the specific topics such as illustrate what is the "Right information for the right user" and the IoT technologies used in this scenario.

4.1. Right information for the right user

This scenario aims to provide early warning systems to protect residents who are potentially impacted by landslides, so that the residents can receive an early warning and ensure their safety before disasters arise. Here is the information flow diagram:

  1. Publish raw sensor data on an IoT platform.

  2. Integrate EOC platform with IoT data such as weather forecast and map layers.

  3. The EOC analyzes the integrated real time data and publishes warnings if exceeds the threshold(s).

  4. The EOC sends warnings to the community in charge and the residents who are potentially impacted by landslides and debris flows.

right information for the right user
Figure 2. Information flow diagram about right information for the right user

4.2. IoT connectivity

The internet of things (IoT) in this scenario combines technologies including hardware, communication, cloud computing and etc. The methods/technologies used in this pilot are described as the following image.

IoT Architecture
Figure 3. IoT platform architecture

The architecture shows how MQTT work as well as how can data be republished following to the OGC SensorThings API standard.

Note

What is MQTT?

An ISO standard publish-subscribe-based messaging protocol. It works on top of the TCP/IP protocol suite.

Source: https://en.wikipedia.org/wiki/MQTT

Sensors must be considered low energy and low bandwidth consumption hardware such as Narrowband IoT (NB-IoT) devices. In order to publish sensor data on the platform, communications between sensors and IoT platform are based on RESTful or MQTT(preferred). One NB-IoT device can connect with multiple sensors. A channel can be considered as a physical device, and a node is a sensor. The devices shall support MQTT, which can also be registered on an IoT platform just like the following demo:

Adding a physical device to IoT platform
Figure 4. Adding a physical device on an IoT platform
Note

What is NB-IoT?

Narrowband Internet of Things (NB-IoT) is a Low Power Wide Area Network (LPWAN) radio technology standard developed by 3GPP to enable a wide range of cellular devices and services. NB-IoT focuses specifically on indoor coverage, low cost, long battery life, and high connection density. NB-IoT uses a subset of the LTE standard, but limits the bandwidth to a single narrow-band of 200kHz.

Source: https://en.wikipedia.org/wiki/Narrowband_IoT

Sensor data might need to do format conversion before saving on the platform. The showcased platform supports a feature called "Methods" for pre-processing sensor data. The following demo displays the rainfall data (from node 1) must multiply a weight (said 1.05) before saving on the platform.

Pre-process the data before saving
Figure 5. Pre-process the data before saving

The platform also supports security mechanism using simple API key.

Channel Security
Figure 6. Channel security

Users can navigate the results on the dashboard after the data has been published on the platform.

Channel Dashboard
Figure 7. Channel dashboard

The platform also supports IFTTT-like mechanism. A feature called "Rules" can help to create chains of actions. For instance, the following demo shows if the rainfall exceeds 10mm, then the platform will automatically send a message to a mail list of stakeholders.

Rules and Actions
Figure 8. Define rules and actions
Note

What is IFTTT?

If This Then That, also known as IFTTT, is a free web-based service to create chains of simple conditional statements, called applets. An applet is triggered by changes that occur within other web services such as Gmail, Facebook, Telegram, Instagram, or Pinterest.

Source: https://en.wikipedia.org/wiki/IFTTT

The platform allows publishing sensor data via various methods such as OGC SensorThings API without extra configurations.

SensorThings API
Figure 9. Publish sensor data via SensorThings API

5. Scenarios and Tools Demonstration

This section provides a detailed description of the scenario(s) and the description of the tools used in the demonstration.

5.1. Landslide

In chapter Simple Architecture, several systems were introduced including IoT platform, EOC platform, and Evacuation application. In this chapter, this user guide further describes who is the target audience, and the demo the screenshots of the systems in the landslides scenario.

5.1.1. Target Audiences

For each systems mentioned in the landslides scenario, the target audience is defined as follows.

  • In the IoT platform

    • EOC administrative staffs - Decision-makers who can obtain real-time integrated data and provide an early response to disasters.

    • Sensor owners - Owners who have registered sensors on the platform.

  • In the EOC platform

    • EOC administrative staffs - Decision-makers who integrate dataset and analyze the integrated real time data then publish warnings if exceeds the threshold(s).

  • In the evacuation application

    • Potentially impacted residents - Residents who live near the hazard areas can use the evacuation app on mobile phone while evacuating.

5.1.2. Publication of data

This section demos the data products that all these systems published.

  • Sensor data via SensorThings API

    • Raw sensor data is saved on an IoT platform and published in OGC SensorThings API format.

SensorThings API
Figure 10. Publish in the SensorThings API

  • Landslide warnings

    • Two levels of warnings: Yellow and red

      • Yellow: Exceeds 90% of the threshold.

      • Red: Equals to or greater than the threshold.

Warnings on the map
Figure 11. Publish on official website
Cellbroadcast
Figure 12. Publish through cell broadcast; image contents: "Warning - [Debris flow alerts] The yellow warning alert has been published for Taoyuan Village, Yangping Township, Taitung County, be aware of debris flow. Soil and Water Conservation Bureau"
5.1.2.1. In-situ Data

Instruments such as rain gauge, water level meter, geophone, wire sensor, soil water moisture sensor and CCD camera are employed for monitoring landslides.

In-situ devices
Figure 13. In-situ devices
5.1.2.2. Model Data

Models of SensorThings (for IoT platform) and Routing Exchange Model (for Evacuation application) are employed in this scenario. These models play important roles in the use cases.

SensorThings API data model

An IoT device or system is modelled as a Thing. A Thing has an arbitrary number of Locations (including 0 Locations) and an arbitrary number of Datastreams (including 0 Datastreams). Each Datastream observes one ObservedProperty with one Sensor and has many Observations collected by the Sensor. Each Observation observes one particular FeatureOfInterest. The O&M based model allows SensorThings to accommodate heterogeneous IoT devices and the data collected by the devices.

SensorThings API Model
Figure 14. SensorThings API model illustrated in ER diagram
Note

OGC SensorThings API specification

http://www.opengeospatial.org/standards/sensorthings
Routing Exchange Model

a 'Route' is represented as a GeoJSON feature collection and is a minimal model for Routing API implementers to exchange routing information.

Routing Exchange Model
Figure 15. Routing exchange model defined on SWAGGER HUB
Note

Routing API draft specification

https://app.swaggerhub.com/apis/cportele/wps-routing-api/1.0.0#/
5.1.2.3. Remote Sensing Data

In this scenario, the EOC platform uses NLSC Orthophoto as the base map.

5.1.3. Registration of data

The following methods describe how the data were registered on the various systems.

  • Sensors must be registered on an IoT platform using MQTT protocol. For more details, please read chapter Special Topics.

  • Warnings also need to be registered on an open data platform such as https://data.gov.tw.

Open Data
Figure 16. Taiwan open data registration

5.1.4. Discovering of data

Data can be discovered on the following platforms:

5.1.5. Downloading of data

To access the sensor data, using the SensorThings API is recommended.

SensorThings API
Figure 17. SensorThings API

To access the warning data, using SWCB open data or Taiwan open data.

SWCB Open Data
Figure 18. SWCB open data
Debris Flow Open Data
Figure 19. Taiwan open data

5.1.6. Data Integration

The IoT platform integrates various types of sensors.

Dashboard of Sensors
Figure 20. Integrate sensor data and display on a dashboard

The EOC platform integrates data such as IoT data, weather forecast, shelters and etc.