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:

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 © 2020 Open Geospatial Consortium. To obtain additional rights of use, visit


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.


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.




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

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

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 -

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.


What is MQTT?

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

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

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.

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.