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.

EOC integration
Figure 21. Integrate data on an EOC platform

In this pilot, an evacuation application using the OGC Routing API is presented. The goal of the OGC Routing API is to process specifications that can support geographic routing. The evacuation application integrates offline resources such as vector tiles in GeoPackage and an offline routing engine. These offline resources are the key components to ensure the offline routing works under limited internet connection.

The communication between the application and the engine is based on the Routing Exchange model defined in the Routing API.

Evacuation APP
Figure 22. Evacuation application with offline capability

5.1.7. Republication of data

Sensor data is republished in the SensorThings API format. For more details, please read the chapter Special Topics.

5.1.8. Displaying of the data with proper symbology

There are several methods adopted in this scenario to offer an intuitive User Interface (UI) experience. These methods include:

  • Color

    • Warning areas: Yellow and red are used to overlap on the map.

  • Icon

    • Features: Shelters, roadblock and etc.

Shelter icons
Figure 23. Shelter icons

6. Conclusion and Way Forward

This section provides conclusions and identified issues.

6.1. Conclusions

In this user guide, an integrated early warning system and an evacuation application that adapted to various OGC standards such as OGC WMS, WFS, and SensorThings API have been introduced for early response to landslide disasters.

There are two scenarios that have been introduced in this user guide: letting audience get to know the background, data source, and other technical details. The data flow between these phases is described in chapter General Use Cases. The IoT technology has been adopted in this user guide for the purpose of real-time data analysis. More details are described in chapter Special Topics. The OGC standards such as SensorThings API, WMS, and WFS play important roles for data interoperability. A new draft standard such as Routing API can also be adopted for evacuating residents who are potentially impacted by landslides in an online or offline scenario.

These scenarios are not limited to the specific regions. It can be adapted to other areas where the people are impacted by typhoons (hurricanes), extreme precipitations, and hillside disasters especially in Southeast Asian countries.

6.2. Issues and way forward

This user guide also provides a few suggestions and lesson learned for further discussions.

  • Limited communication and power supply

    • Generally, hillside disasters often confront with infrastructure issues such as limited bandwidth, power shortage and inconvenience transportation. These factors will increase the difficulty of information retrieval and communication.

    • The combination of a long-range communication protocol such as LoRA, NB-IoT, and low-power consuming sensor could effectively resolve the environmental limitation for on-site information retrieval in the hillside area.

  • IoT gear maintenance cost

    • Deploy more IoT devices not only can expand the sensing network but also enhance the accuracy of micro-climate analysis. However, the expenses to build and maintain the sensors can be relatively costly which might be another issue for the future discussion.

    • All sunk costs are fixed. However, long-term fixed cost such as communication work need to be carefully estimated.

  • Data accuracy and error handling

    • Most IoT sensors on hillsides are designed for low power consumption. The sensor design is a trade-off of data accuracy and power consumption.

    • Sensors deployed on-site might malfunction. Identify malfunction sensors and correct their value in a software are recommended.

  • Analysis and decision support

    • IoT sensors can be widely deployed for various scenarios and retrieve time-series information and patterns from the on-site areas. However, these can also trigger other issue that undermine the efficiency and accuracy of big data analysis.

    • GeoAI has become a significant interdisciplinary that integrate various technologies, such as geoinformatics, mathematics, geology, geography and methodology. Standards that can well define (self-define/Linked data) algorithms, dataset, training dataset, analysis results, and visualization techs are also merit for further development.

  • On-site investigation supporting

    • Regularly managed and calibrated sensors can increase the data accuracy and their work performances. In Taiwan, a mobile application has been developed for on-site investigators to maintain sensors and manage the collected data.