Integration of Heterogeneous Sensor Systems for Disaster Responses in Smart Cities: Flooding as an Example

Abstract

Smart cities represent a new perspective on modern urban development. They involve an information infrastructure environment with application intelligence to improve operational efficiency and welfare effectively. However, understanding how to overcome the barriers of data fragmentation and heterogeneity to exploit the strengths of existing resources and create integration effects remains a key challenge in smart city development. This research focuses on the effective management of heterogeneous sensor systems across different domains to improve quick disaster responses. Metadata serve as the core of this proposed framework, which is designed to not only describe the common and unique characteristics of various IoT-based devices and services, but also to provide necessary information to support the searching, requesting, and updating of required sensors and observation, as well as responding to the upcoming disaster. A workflow consisting of four list types was proposed and used to guide the response procedure. This research specifically aims to enable heterogeneous sensor systems available to all public or private stakeholders to be integrated in a collaborative fashion. While a flooding response was chosen for demonstration in this research, the proposed standard-based framework can be further promoted for other types of smart city applications, not limited to disaster response. The study’s results and implications underscore the importance of effective management of heterogeneous sensor systems and the role of metadata in enabling disaster responses in smart cities.

1. Introduction

In the short 20-year period from 2000 to 2019, there were 7348 recorded major disasters worldwide, claiming 1.23 million lives, affecting 4.2 billion people, and costing USD 2.97 trillion in economic losses [1]. In recent years, people have become surprised by extreme weather events. For example, flash floods in Indonesia in January 2020 caused at least 66 deaths and 60,000 evacuations when 400 mm of rain fell overnight, causing the Ciliwung and Cisadane Rivers to overflow [2]. Disasters, whether human or natural, often result in substantial economic losses. Prompt response mechanisms are a major challenge for disaster agencies, particularly when dealing with emergency situations under tremendous time pressure [3].

According to Iliashenko et al. [4], in 2018, approximately 55% of the world’s population lived in cities and consumed two-thirds of the world’s energy. This figure is expected to increase by 68% by 2050. Although urbanization may provide a higher quality of life, it also causes problems such as congestion, pollution, and public safety. This development necessitates improved planning for education, environmental protection, accessibility, housing, and citizen welfare. Originating from the United States in 2008 with IBM’s “Smart Planet” project, smart cities have since led to a new wave of urban development around the world [5]. Reza and Azmi [6] suggested that smart cities must be highly instrumented, interconnected, and intelligent to realize the optimal allocation of resources and efficient city management through information. Csukás and Szabó [7] defined a smart city as a strategic portfolio of intelligent systems based on the vision and direction of urban planning to achieve the goals of low carbon dioxide emissions, ecological responsibility, sustainability, and livability. Sun et al. [8] argued that smart cities must make full use of information, communication software, and hardware technologies to maximize the efficiency of city operations, minimize the required energy consumption, and integrate them into various situations such as people’s homes, administrative services, business operations, and energy use. Yang et al. [9] suggested that a smart city must have two levels: the first level is that it should be people-centered and user-friendly and the second is that the city should have deeper urban informatization to enhance its economic efficiency via technological innovation and urban resources. Because all smart city applications require correct data, it is necessary to enhance the capacity of cross-domain digital information, develop innovative modes of operation through the analysis and integration of data, and meet citizens’ expectations [10]. In addition to static information, strategies must be developed to improve the timeliness and quality of collected information. It is advantageous to promote effective data exchange and sharing mechanisms to meet real-time response demands (e.g., smart transportation and smart disaster prevention). Thus, early warning mechanisms can be developed to deal with unexpected situations in a timely and appropriate manner [11].

The emergence of the Internet of Things (IoT) has considerably facilitated the development of smart cities, particularly with recent increases in sensor chip bandwidth, computing power, and the number of mobile devices. Numerous models that rely heavily on human-to-human or human-to-machine interactions are expected to replace machine-to-machine interactions [12]. The monitoring task in each area is conducted via sensors that can exchange data in real time to keep track of changes in their neighborhoods [13,14]. With such real-time advantages, smart disaster monitoring systems [15] can overcome the limitations of relying on human resources and enhance automated early warnings and responses. To take full advantage of IoT-based architecture, disaster management frameworks that integrate GIS and IoT typically include four layers. The sensory layer is located at the bottom of the overall architecture and is mainly used for sensing and tasking IoT devices to accomplish required tasks [16]. The network and data communication layers are developed for data transmission, which includes various heterogeneous wireless network protocols that operate through the connection of network services such that observation information can be transmitted over the Internet [17]. The decision support layer was developed to support decision making with components of metadata, cataloguing, and data visualization. Its task is to develop a mechanism between the data layers and applications from a management perspective to effectively manage available resources [18]. Finally, the application layer includes various smart city solutions based on user requirements. It uses available technologies to integrate relevant resources and subsequent processes, and supports the planning of the decision-making application layer [19].

While the four-layer framework can be applied in practice to the development of stand-alone disaster prevention and response systems for individual agencies, development cannot be limited to a single-system mindset when cross-domain resources must be integrated, especially for complex operational mechanisms such as smart cities. This study examines the sharing and application of heterogeneous sensor systems to facilitate the development of disaster-response mechanisms. Metadata service, as the core of the proposed approach, were proposed to describe the common and unique characteristics of various types of devices and services. A response workflow was developed to search, request, update, and respond to continuously changing disaster situations. While many current studies have focused on the response process or prediction models for disasters, the framework in this research proposes a generic standardized metadata-driven approach that can be applied to locate and master the integration of heterogeneous sensor systems to facilitate cross-domain applications in smart cities.

The remainder of this paper is organized into four sections. Section 2 reviews and analyzes the issues related to smart disaster management during flood disasters. Section 3 proposes an operational model based on a metadata-driven emergency response system from a standardization perspective. Section 4 presents an example of flooding to demonstrate the feasibility of the proposed framework. Finally, Section 5 concludes the paper with the main findings and future research directions.

2. Related Work

Smart disaster management encompasses various subjects, such as sensor systems, communication infrastructure, data analysis and processing, decision support, emergency response, institutional collaboration, public education, risk assessment and mitigation, and infrastructure management. From a data perspective, smart and traditional disaster management differ in terms of their approach to resource sharing and integration among different units, as well as the use of information and communication technology. Effective disaster management requires seamless coordination and collaboration among different stakeholders, including government agencies, emergency responders, and the public, to address the technical, organizational, and societal aspects of disaster response [20,21]. With the increasing maturity of information and communication technology, smart disaster management solutions have begun to leverage the Internet of Things (IoT) architecture to improve traditional human-centered disaster procedures through real-time observation transmission from sensors deployed in different locations [22,23,24]. Smart technology enables communication of disaster information to potentially affected units and individuals to respond to threats and reduce losses [25,26,27]. Therefore, the integration of heterogeneous sensor systems with automated and efficient response logic is considered a key factor in the success of smart disaster management.

Smart disaster management is essential to mitigate the risks and impacts of disasters. This requires an intelligent disaster-response mechanism that can effectively use real-time disaster information from multiple sources for preparedness, monitoring, early warning, notifications, and response [28]. The introduction of a standardization strategy can transform scattered disaster information data into a meaningful dataset for further processing [29,30]. Shared platforms and standard data protocols further achieve interoperability [31,32] and improve decision-making efficiency [33]. GIS-based visualizations with novel map interfaces and dashboards have tremendously improved the presentation and assessment of disaster information [34]. Finally, disaster information, such as location, time of occurrence, duration, and damage, are stored in a historical disaster database, which is an important reference for future disaster prevention [35,36]. The most important aspect of this new generation of disaster management systems is the effective use of information collected by sensors to provide relevant personnel with information for improving the efficiency and accuracy of decision making.

Smart disaster management research has leveraged advanced technologies, such as IoT and machine learning, to improve disaster management operations. The five major strategies are summarized as follows. First, GIS technology was introduced to accomplish real-time monitoring, data management, and geospatial analysis of disaster information. Nguyen et al. [37] developed a spatial decision support system for real-time flood early warning in Vietnam’s Vu Gia-Thu Bon River basin that integrates real-time hydrometeorological monitoring, IoT communication infrastructure, simulation and prediction models, WebGIS, and an SMS inundation warning module to predict inundation events. Chang et al. [38] developed a smart river management system that utilizes IoT sensors and data analysis to support decision makers with real-time water condition data and disaster notifications. Rezvani et al. [39] reviewed the literature on the use of asset and disaster risk management approaches and GIS-based decision support tools to enhance urban resilience. Second, IoT devices serve as a communication infrastructure for collecting real-time data from sensors and facilitate the development of monitoring systems. Aljohani et al. [40] proposed a general framework for managing natural disasters using the IoT and machine learning. Third, simulation and prediction models were used to forecast potential disaster events and create early warning systems. Keung et al. [41] proposed a real-time urban drainage monitoring system using IoT sensors to predict drainage and operating emergency responses in stormwater situations. Mohanty et al. [42] developed a two-dimensional real-time flooding prediction system using the Delft-FEWS platform and a smart water level meter for the real-time monitoring of flooding on roads. Studziński et al. [43] used hydraulic models to analyze the failure risk of water distribution systems and identified potential failure points in water distribution systems. Fourth, smart sensor systems can improve flood detection, drainage management, and response. Kavitha et al. [44] explored the use of smart technologies in emergency response and disaster management, discussing various sensing technologies and devices and their potential to enhance response systems. Finally, standardizing disaster management services and integrating heterogeneous early warning systems and sensing devices can enhance disaster response and recovery. Perera et al. [45] analyzed the application of smart systems as a means of early warning, disaster recovery, and post-disaster recovery and proposed linking heterogeneous early warning systems and sensors to improve disaster resilience. Hingmire et al. [46] proposed a real-time flood monitoring and warning system using IoT and GIS technologies.

Despite the above reviews showing significant progress has been made for developing dedicated disaster response systems for the simulation, management, and prediction of and response to disaster information, we argue a mechanism capable of enabling the inclusion of all sensor systems and using their observations, regardless of the deployed responsible units, for emergency response also deserve attention. This implies that even if a sensor system is not previously linked, it will be possible to establish a link whenever necessary, as long as it follows the proposed process. This design expands the possibility and capacity of emergency response mechanisms by allowing sensor systems to be allowed independently from a variety of government agencies or even private agencies to work together in a collaborative manner. The discussion in this paper is restricted to the design and use of metadata to facilitate emergency responses.

3. Methodology

The study’s design was built upon previous research on smart cities, data fragmentation, and disaster response and identified gaps and challenges in the existing literature, particularly the need to manage heterogeneous sensor systems and integrate existing resources effectively. The study incorporated the concept of metadata to describe sensor characteristics and facilitate various functions. It drew insights from previous studies and aimed to propose a standard-based framework to enhance disaster response and apply it to other smart city applications. The study’s design reflects a comprehensive understanding of the research field and attempts to address identified gaps in utilizing the field through metadata design and workflow planning. It impacts future commanders to invoke the required heterogeneity of sensors in disaster management.

3.1. Smart Flooding Disaster Response

To enhance the development of immediate response mechanisms to disasters, the massive deployment of sensors based on IoT technology can be of substantial benefit. For example, in the case of flooding, it is ideal to understand the locations and parameters of flood sensors and Closed-Circuit Television (CCTV) completely, deployed by multidisciplinary units. Despite the rapid development of Internet technology, challenges remain, including a lack of effective control of the resources managed by each unit, heterogeneity of the framework structure, and inconsistent service interfaces. Rather than dedicated response systems specifically developed by the individual agency for its responsible missions, this study focuses on overcoming the major barriers to cross-domain resource sharing from a standardized perspective and proposes a metadata-based approach to facilitate the sharing and interoperability of disaster information for emergency response. Figure 1 shows the major components of the proposed architecture.

Sensor systems from different agencies serve as major sources of observations to update our understanding of continuously changing situations in the real world. While various agencies have independently designed data schemas and developed distribution mechanisms, efforts have been made to promote standards to improve the interoperability of sensor observations. The Open Geospatial Consortium (OGC) Sensor Web Enablement provides a standardized strategy for sensor networks over the Internet. Based on the open data format concept, standardized observations and services (e.g., SOS) have been designed to provide users with cross-domain information [47]. The SensorThings API [48] not only expanded the operations of tasking, but also created a more convenient service environment through lightweight observation and structured networking technologies. For the IoT domain, the M2M Technical Committee (Machine-to-Machine Technical Committee) proposed an extensive standard framework for the development of an overall IoT framework and integration [49].

Metadata, defined as “data about data”, have been widely accepted as an effective solution to enhance the description of data and facilitate data exchange. To search for the correct information from a wide range of resources and determine its fitness for use, the design of metadata must ensure that its content meets the users’ data request demands. The standardization of metadata is the best way to reach a consensus and expand the capacity for data sharing [50]. For example, the Group on Earth Observations (GEOSS) [51] is a metadata-based mechanism for sharing global-scale earth observation resources from participants worldwide. The US Federal Geographic Data Committee (FGDC) [52] and the European Union [53] developed standardized metadata frameworks, which led to the development of cross-unit and cross-nation geospatial resource-sharing portals. At present, the ISO19115 series of metadata standards from ISO/TC211 has been widely adopted by geospatial communities [54] for developing spatial data infrastructure (SDI), particularly for resources owned by the government.

After obtaining a complete understanding of the deployed sensor systems from metadata, the next challenge is to assimilate this knowledge into the disaster response procedure. A logical workflow must be developed to effectively take advantage of all the available sensors and observations, update the threats of disaster, and take necessary actions to reduce the damage caused by the disaster, such as the evacuation of citizens or the shutdown of facilities. The major challenge is moving the architecture design from a human-led command approach to a digital information application approach and, even more so, generating a smart decision aid with available resources.

In this study, metadata were designed to establish an effective mechanism for managing distributed sensor systems and bridging information communication between the emergency response command system and various sensor systems. The metadata design is required to incorporate the characteristics of sensor systems and the needs of decision making. A standardization approach was introduced to allow any sensor system to participate in disaster response mechanisms whenever necessary.

3.2. Sensor Systems and Services

Sensor systems can provide continuous observations of specific phenomena and highlight their geospatial distributions and temporal evolutions for further analysis. The combination of sensor observations, GIS, and the Internet has become the main mode of operation for disaster-response systems. It has been widely used for data processing, spatial analysis, and visual presentation of disaster events. Ideally, real-time observations from any sensor system should be continuously updated and interpreted unambiguously for the intended applications. However, the sharing and interoperability of data from cross-domain-independent resources are often hindered by the various specifications adopted by individual agencies. The challenge involves not only inconsistencies in interfaces, data semantics, and data formats, but also integrated collaboration among related agencies.

The required understanding of individual sensor systems, regardless of whether they meet a universal or self-imposed standard, must include at least the following considerations:

• Ownership of sensor systems: This information focuses on the authority governing each sensor system. Contact information must be available to coordinate access to the sensor systems.
• Subject of the sensor: This describes the object or range of observation. In addition to the sensor type and deployment status, the observed targets should be identifiable and clearly described.
• Sensor specifications and content of observations: This information describes the specifications of the sensors and the content and format of the observations. Sensor specifications describe the hardware and software characteristics of sensors, and the schema describes the content and structure of the data obtained, including time and location information.
• Sensor system services: This information describes the operations and parameters of the services. Typical information includes web addresses, interface standards, access operations, and parameters. The use of common standards helps simplify the acquisition of observations from different sensor systems.
• Time information of sensor observations: In addition to the time recorded for each observation, this information describes the operation time limit of the sensor system and the frequency of data updates.
• Sensor status parameters: This describes the conditions of the sensors, such as the threshold values for triggering alarms.

The OGC SensorThings API offers a comprehensive solution for modeling the characteristics and interrelationships of sensor systems and observations. Seven classes, namely, thing, location, data stream, observation, sensor, observed property, and feature of interest, have been defined as common architectures for various types of sensor systems. The thing class is the key to describing an object whose location can be represented by the location class. The observed features were described by the feature of interest class. An object can have multiple data streams, whose content is a collection of observations generated by the same sensor for the observed property of the feature of interest. When a standard such as the SensorThings API is adopted by different agencies, the standardized tags of the above classes can be parsed and interpreted consistently to achieve the goal of interoperability. Figure 2 shows the flood sensor information and flooding depth sensor data from Civil IoT Taiwan (obtained from https://tinyurl.com/mvu4f893 accessed on 8 April 2023). In this example, the description of the thing is “Flooding height measurements are returned every 1 HR up to 5 cm, 5 cm every 10 min”; the authority is the “5th River Bureau”; and the name of the data stream is “flooding depth”. The observation shows the observation is collected on “2022-08-07T04:48:48.000Z/2022-08-08T11:48:48.000Z” and the result is “0”. The location is provided by the tag of “the coordinates”. Each aspect of the information can be readily interpreted according to standardized schemas.

From a smart city perspective, an emergency response mechanism must effectively manage heterogeneous sensor systems operated by different units that must be interrogated to acquire sensor observations within a disaster area to make appropriate action decisions. The following discussion proposes the design and operation of the response mechanism based on standardized metadata and a workflow. Metadata are designed as a set of elements that describe the various types of properties of the sensor systems to support the search and access of sensor systems that provide useful reference information to the disaster.

3.3. Metadata Design

As the basis for designing standardized metadata, the background factors of distributed sensor systems can be summarized as follows.

• Each agency develops its own sensor systems according to its responsible missions.
• A sensor system comprises multiple sensors that provide observations at different locations over time.
• The sensor system observations followed a chosen schema. The designed schemas may differ from one sensor system to another.
• The time series and quality characteristics of the observations limit their possible applications.
• Sensors may be produced by different manufacturers with different specifications.
• The sensing apparatus has specific targets and sensing capabilities.
• Individual sensor system often distributes observations through a service with a specific Internet link.
• Access to sensor system services may follow specific interfaces (e.g., APIs), including various types of operations.
• Sensor services from different stakeholders may follow the same standards, facilitating interoperable applications and reducing system development costs.
• Different stakeholders may adopt their own preferred service interface standards.
• The interface and content of the sensor system may have access restrictions; for example, only for governmental use.

This paper proposes a set of metadata elements to facilitate the collaborative mechanism of distributed sensor systems. Standardized metadata were developed to include all the required information for decision makers to search for and select suitable services and obtain observations as a reference for response actions. Ideally, all sensor systems should follow a consensus standard for preparing and registering metadata in a resource management system. Figure 3 illustrates the metadata design results using a unified modeling language (UML). Three main components—devices, observations, and services—are considered.

Deployed by authorized agencies according to their needs, sensors are responsible for collecting observations and updating their understanding of the environment. In addition to the elements that describe the common properties of IoT devices, each type of sensor may exhibit unique properties. Therefore, the design of the metadata element must be customized according to the sensor type. Three elements—time, location, and content—form the common architecture of observation. Location is mainly used to depict the geographic distribution of the acquired observations. Because each observation records the instantaneous state of the real world, a time-series observation can be viewed as the history of the observed phenomena. Finally, the value of the observation is determined by the sensor, for example, the water level for a water level sensor and video streaming for CCTV, which may be very different in terms of content and format. Services provide interfaces for acquiring observations from sensor systems hosted by various units. The design of the service metadata must meet various demands, such as identifying sensors, interpreting backend resources, accessing and interpreting the content of the data, identifying how the service content is requested, and confirming that the data are available. Although adopting a consensus standard is certainly advantageous, dealing with the heterogeneous design of service interfaces is inevitable.

In Figure 3, the class of devices is defined as an upper-level class with common attributes of IoT devices (refer to

Table 1. Device (device category) (M: Must, O: Optional).

Name	Definition	Optional Condition	Model Elements or Data Type	Remark
Device	Device		Class
ID	Unique object ID	M	String	Equipment number
Type	Types of devices	M	String	Equipment type
Deployment location	The location where a device is deployed	M	GM_point	Represented by 2D or 3D coordinates
Deployment time	The time when the device is deployed	M	Date	Reference for historical data available
Authority	The name and contact information of the organization that deploys the device	M	String	Responsible for the equipment
Active	Whether the device is active	M	Boolean	1 = yes, 0 = no
Manufacturer	Name of the device manufacturer	O	String	Equipment manufacturers
Serial number	Serial number of the device	O	String	Manufacturer’s equipment serial number
Street address	Street address of the building where the device is deployed	O	String
Auxiliary location information	Facilities that can be used for spatial reference	O	String	Name of the buildings or facilities

), and allows for defining new types of sensors with additional attributes following the inheritance relationship. For example, CCTV and water-level meters are devices with unique metadata elements. In addition to the identification metadata elements, the major metadata element for sensor systems is the location description, which uses coordinates, street addresses, or even auxiliary descriptions to describe where the sensor is deployed.

The CCTV metadata elements are listed in

Table 2. Camera class (CCTV camera class).

Name	Definition	Optional Condition	Model Elements or Data Type	Remarks
Camera	CCTV Camera		Class
Visible object	The ID of the features that are visible via CCTV	O	String	CCTV viewable object ID
Night vision	If the CCTV can capture images during the night-time	O	Boolean	1 = yes, 0 = no
The angle of view α	The viewing angle of the CCTV	O	Double	CCTV viewable range of angles
Far effective range D	The viewing distance of the CCTV	O	Double	CCTV sets the maximum viewable distance
Roll	The angle set for an X axis	O	Double	CCTV vertical axis X in three-dimensional space
Pitch	The angle set for a Y axis	O	Double	CCTV horizontal axis Y in stereoscopic space
Yaw	The angle set for a Z axis	O	Double	CCTV vertical axis Z in stereoscopic space
3D FOV	The 3D presentation of the CCTV field of view	O	Geometry	GM_MultiSurface/GM_Solid

. Except for the location, the elements of the angle of view and the rotation angles of the CCTV were designed separately to calculate the 3D FOV (Field of View) information of the camera. The calculated 3D FOV only provides a theoretical viewable range because the observable phenomena may be obscured by real-world objects; however, it can be used to quickly exclude sensors that do not provide coverage for the disaster area. In addition to the geometric perspective, night-vision capabilities were considered. These metadata elements only cover the basic requirements of CCTV for contingency purposes, and more elements can be expanded when other applications are considered.

The metadata for the water level meters are listed in

Table 3. Water level meter class (WaterLevel_Meter class).

Name	Definition	Optional Condition	Model Elements or Data Type	Remark
Water Level Meter	Water Level Meter		Class
Maximum of range	Water level meter upper limit	M	Integer	Units in centimeters
Minimum of range	Lower limit of water level meter	M	Integer	Units in centimeters
Warning	Threshold value for triggering alerts	M	Integer	Units in centimeters

. In addition to the range of water heights a water level meter can detect, the key information is the threshold value for triggering alerts. Emergency response commanders should be made aware of all water level meters whose observations exceed threshold values.

The service metadata must provide a description of the type and spatial extent of the observations (

Table 4. Service (service category).

Name	Definition	Optional Condition	Model Elements or Data Type	Remark
Service	Service		Class	Service identification information OGC ISO19115/ISO19119
ServiceIdentification	ID of service	M	String	Unique of services ID
ServiceType	Name of service standard type	M	String	Types of geo-networking services provided, such as standard specifications defined by OGC, e.g., Sensor Web Enablement (SWE) and SensorThings API
ServiceTypeVersion	The version of the service standard adopted	O	String	Version of the service standards described in ServiceType element
ServiceProvider	Service providers	M	String	Internet service providers
Keyword	Keyword	O	String	Place or theme keywords
Binding	Conforming protocols; links to call execution procedures	M	String	Web Services Description Language (WSDL), Hypertext Transfer Protocol (HTTP), eXtensible Markup Language (XML), Object Access Protocol (SOAP), Universal Description, Discovery (UDDI), etc.
Operation	Name of executable action provided by the service	M	String	e.g., Getcapabilities
ServiceURL	Web link	M	URL	URL link paths for packaging images, maps, information, instructions, etc.
Constraints	Information about the authorization to access the service	O	String	Instructions on how to link or limiation about the use of services
Spatial extent	Set spatial extent BoundingPolygon uses polygon items to precisely describe the spatial extent of data or services	M	EX_GeographicExtent	The area information for the service
Schema for observation	The schema description of the distributed data	M	String	Can be a particular standard or schema defined by responsible units

). In addition to the coordinates, the description of the spatial extent can be supplemented by place names. Further information may include service URLs, interface standards, associated operation names, parameters, and types of data supplied. To help commanders quickly locate services that may provide useful references, the design of metadata is used to quickly exclude unqualified services by specifying constraints, such as the type of sensors, spatial and temporal extent of the data, and availability of sensors.

3.4. Workflow for Decision Making

With the rapid growth of Information and Communication Technology (ICT), disaster information can now be easily collected; for example, sensor systems using IoT technology or reports from the general public using telephones or social media. Both methods include information about the where (location), when (time), and what (observed disaster) aspects of the disaster. The response mechanism follows a standardized operational procedure (SOP) to determine whether subsequent response actions must be triggered after receiving a reported disaster.

Heterogeneity cannot be ignored when multiple units are involved. Differences in data formats, platforms, software, services, and semantics are major barriers to data sharing. With a large number of sensors deployed for different purposes, the disaster response process involves searching for sensor systems, requesting data, validating whether a disaster has occurred, monitoring continuous changes, and archiving disaster information. Accordingly, a workflow based on four lists is proposed, with each part playing a specific role in the emergency response:

• Tracking list: This tracking list records all the available cross-domain sensor systems whose metadata are registered in a metadata database. Standardized metadata must be established before being included in a database.
• Candidate list: The candidate list records the selected sensor systems based on time, location, and sensor constraints according to the reported disaster. This list shows the quick filtering results based on preliminary constraints. Furthermore, the request for observations from a sensor service determines whether the selected sensor systems should be closely monitored. The list of candidates is updated when a new disaster report is received.
• Monitoring list: When a sensor is added to the monitoring list, it implies that a disaster is confirmed according to its acquired observations; for example, a water level meter that exceeds the alert threshold or a CCTV streaming service that shows the occurrence of a disaster. The monitoring list must be updated continuously until the threat ends.
• Disaster list: Data collected by the sensor systems during emergency responses can be archived later in the disaster list. In addition to the role of historical data, such information can be used as a reference for the subsequent deployment and adjustment of sensor systems (e.g., disaster hotspots).

These four lists were designed to handle the standardized metadata of the sensor systems. In the case of tracking lists, the ideal situation is to include the metadata of “all” sensor systems from different units. Mapping between metadata schemas is necessary if heterogeneous metadata designs from different units are to be considered. The creation of a candidate list depends on the successful establishment of filtering constraints and correct metadata content. Management of the monitoring list provides a visual aid for the geographic distribution of confirmed disasters. Finally, the disaster list builds an archive that records disaster event information on an individual sensor system. The use of these four lists presents the logic for enhancing the integrated operations of a heterogeneous sharing environment. Figure 4 shows the emergency response workflow for a flooding disaster, using a water level station as an example. The major workflow steps are listed in

Table 5. Major steps of the proposed workflow in the flooding example.

Operating Procedures	Operation Details
Receive disaster information	Receive disaster information either from the general public or alerts from sensor systems. Check if all the required information is included, e.g., location and time (sensor ID).
2. Update the candidate list	Select the sensor systems that may provide a useful reference for the reported disaster. Location: If a street name or landmark is reported, it must be converted to coordinate representation. A buffered region is established according to the specified coordinates. Sensor type: Determine the types of sensor systems according to the reported disasters. Query the metadata database to determine the sensor systems added to the candidate list. Spatial constraint: the location of sensors within or the FOV of sensors intersects the buffered region. Time constraint: the sensor system is operating at the time of query. Sensor type: all selected types of sensors. 4. Qualified sensors are added to the candidate list.
3. Acquire observations from selected sensor systems in the candidate list	According to the selected sensor systems in the candidate list, acquire observations from their respective services. From service metadata, interpret the information of the ServiceIdentification, ServiceProvider, Data Provider, Operation, ServiceURL. Obtain the “Observed_Result” for the water level meter sensor. Obtain the “ServiceURL” of each CCTV camera sensor.
4. Update the monitoring list	Depending on the acquired observations, determine if the sensor systems will be added to the monitoring list. Verify if the value of observation value is above the “Warning” threshold value. Visually inspect the CCTV video to verify if a disaster occurs. If the disaster is confirmed, the corresponding sensors are added to the monitoring list.
5. Continuously update the candidate and monitoring list	Continuous updating observations to aid disaster response. Continuously acquire observations of sensors in the monitoring list according to the specified updated frequency. If the threat from a particular sensor ends, the sensor is removed from the monitoring list. Whenever a new disaster is reported, repeat operation procedure 3 and 4. This step ends when the monitoring list becomes empty.
6. Create disaster list and historical records	Build an archive for the historical records of disasters. Keep observations collected during the emergency response period for all sensors in the monitoring list. Historical data include the following information on the basis of the individual sensor. Device: Device ID, Device Type, Deployment Location, and Authority. Observations: All observations of sensors during the time they are monitored.

.

Table 5 further explains the operation procedures for the workflow according to the designed order.

4. Test and Results

The key concept of this study was to effectively coordinate the use of all available sensor systems. Figure 5a,b show video recordings of the same CCTV at different times. Although the camera was deployed to monitor traffic, it could also be used to verify the occurrence of flooding, as shown in Figure 5b. Once a disaster is reported, it is crucial for commanders to be able to automatically search and visually inspect “all” the CCTV cameras in the neighborhood for further decision making, regardless of the responsible units or the initial deployed purpose.

To test the feasibility of the proposed mechanism, the test area was selected to include sensor systems deployed by different responsible units. Because there have been no significant floods in this area in recent years, data on flood water level observations were simulated and adopted in the following analysis. Two types of sensors with different specifications and operating procedures were considered in simulated disaster scenarios.

4.1. Test Area and Selected Sensor Systems

The experimental area was located in the Sinshih District of Tainan City. Nine sensors, including seven CCTV cameras and two water-level meters, were deployed by three government agencies, as discussed below.

• System 1: This system was developed by the Water Resources Administration and Tainan City Government Water Resources Bureau to monitor hydrological regimes. Three sensors were located in the experimental area: two water level meters (ID 284 and ID 88) and one CCTV camera (ID 44). The three sensors use the SensorThings API to distribute the observation information.
• System 2: This system was developed by the Freeway Bureau to monitor freeway traffic using CCTV. In addition to routine traffic monitoring, any disaster that occurs on freeways can be observed. Three CCTV cameras (ID 497, ID 1035, and ID 1582) were used. Distributed data are based on the schema of the system.
• System 3: This was developed by the Directorate General of Highways to monitor local traffic. Three cameras (ID 1639, ID 1760, and ID 1761) were used. The distributed data are also based on the schema of the camera system.

Figure 6 shows the geographic distribution of the sensors in the experimental area, where the individual sensor systems are illustrated with different symbols and colors. Because multiple responsible units are involved, the integrated use of the above three systems must address the heterogeneity of the sensors, observation services, and service interfaces. The manner in which the designed mechanism responds to a disaster is discussed in detail below.

4.2. Standardized Metadata

The standardized schema of the metadata proposed in Section 3 consists of four classes for describing the devices: CCTV, water-level meters, observations, and services. It is advantageous if the required metadata can be imported directly from the information established by the responsible units. However, a customized mapping analysis is necessary, owing to the different aspects of schema design. Mapping analysis must consider two aspects: the semantic aspect, which refers to the meanings of the metadata elements, and the content aspect, which refers to the rules of the recorded information. Even if the designed semantics are identical, rules may differ from one system to another.

The metadata proposed in Section 3 include 18 elements for the CCTV camera class (with inherited elements from the device class), 6 elements for the observation class, and 12 elements for the service class. For System 1, 17 and 42 metadata elements were obtained for the CCTV and water level meter, respectively. For Systems 2 and 3, 15 metadata elements were obtained for CCTV. Even if some proposed metadata elements are not considered mandatory, the information obtained cannot completely satisfy the demands of the proposed metadata elements. Based on the proposed metadata elements, the mapping analysis yielded three types of results.

Type 1: Metadata elements imported from the selected sensor system follow the same semantic and content requirements. The recorded information can be used directly.

Type 2: The imported metadata element follows the same semantic requirements, but has different rules for the recorded information. A customized process based on these differences is necessary.

Type 3: No corresponding metadata elements are found. Further metadata entry by referencing other resources or documents is required.

Table 6. Standardized metadata and heterogeneous data field integration comparison table for CCTV cameras.

	Data Resource		System 1	System 2	System 3
Metadata Elements
CCTV camera		Type 1	4	3	3
		Type 2	2	2	2
		Type 3	12	13	13
Observation		Type 1	0	0	0
		Type 2	1	1	1
		Type 3	5	5	5
Service		Type 1	3	4	4
		Type 2	4	3	3
		Type 3	5	5	5

lists the CCTV mapping results for the three sensor systems. The number of Type 3 elements clearly indicates the different design purposes between the proposed metadata schema and the analyzed sensor systems. Most of the Type 1 metadata elements are about the identification of sensors and responsible units. As the name of the elements may be different, a one-to-one mapping relationship must be established. For Type 2 metadata elements, the major difference is on how the recorded information for each system is designed (e.g., latitude and longitude information). The relatively large number of Type 3 metadata elements indicates the conservative approach for the metadata provided by the responsible units. For example, the proposed metadata elements for the camera include the angle of view α, far effective range D, roll, pitch, and yaw, but most responsible units only intend to use a point to indicate the existence of the camera, rather than providing information about its Field of View (FOV); thus, the users can know its visual coverage only after connecting to the service and acquiring the streaming images. Table 6 summarizes the analysis results of the three sensor systems according to the type of mapping.

Table 7. Standardized metadata and heterogeneous data field integration comparison table for CCTV cameras. 1: Type 1; 2: Type 2; 3: Type 3.

	Data Source	System 1	System 2	System 3
Metadata Elements
+ID [1]:string		1: name: system 1366d6b38-68e5-45b9-8203-a944187dfa6a	1: CCTVID: CCTV-N8-W-10.66-M	1: CCTVID: CCTV-54-0010-321-001
+Device_Type [1]:string		1: ciCategory: Video surveillance images	3: Video surveillance images	3: Video surveillance images
+Deployed location [1]:GM_point		2: [Longitude, Latitude]: 120.289403, 23.062014	2: [PositionLon, PositionLat] 120.287155 23.059651	2: [PositionLon, PositionLat] 120.28867 23.06608
+Authority [1]:string		1: Authority Water Resources Department(in conjunction with the county and city governments)	1: SubAuthorityCode NFB-SR	1:SubAuthorityCode THB-5R
+Street address [0..1]:string		1: stationName: Yongjiu, Xinshi Dist. No. 135	1: RoadName: National Highway No. 8	1:RoadName: Provincial Highway 1
+Observation Result [0..1]:String		Only for water level meter	Only for water level meter	Onlyfor water level meter
+Phenomenon_Time:TM_Object		1: phenomenonTime From Images’ Tag of Date	3: Available from Tag of Date of image	3: Available from Tag of Date of image
+Warning [1]:Integer		Only for water level meter	Only for water level meter	Only for water level meter
+Visible object [0..*]:string		3: water_level_meter_284, 15,886,15,892,15,879	3: No Visible Objects	3: 18,542, 18,562, 18,547, 18,551, 15,942, 17,193, 17,187, 17,206, 17,185, 17,184, 17,183, 18,529, 15,403, 18,528, 17,182, 18,533, 18,613
+ServiceURL [0..1]:url		2: Result (from the SensorThings API Observations class): https://iapi.wra.gov.tw/v3/api/Image/737a9cf5-6423-4da8-8911-eb21d709a7fd (accessed on 23 November 2022)	1: VideoStreamURL https://cctvs.freeway.gov.tw/live-view/mjpg/video.cgi?camera=1096 (accessed on 29 September 2022)	1: VideoStreamURL https://cctv-ss06.thb.gov.tw:443/T1-321K+710(S) (accessed on 29 September 2022)
+ServiceIdentification [1]:string		1: properties/stationID:366d6b38-68e5-45b9-8203-a944187dfa6a	1: LinkID 0000800101300D	1: LinkID 3000100032142D
+ServiceProvider [1]:string		1: OrgName Bureau of Water Resources, Tainan City Government	3: Freeway Bureau, MOTC	3: Directorate General of High-ways Ministry of Transportation and Communications
+Data Provider [0..1]:string		3: Tainan City Government	3: Freeway Bureau, MOTC	3: Directorate General of Highways Ministry of Transportation and Communications
+Operation [1]:string		2: Getobservation (from the SensorThings API data stream class) https://sta.ci.taiwan.gov.tw/STA_WaterResource_v2/v1.0/Datastreams(1080)/Observations (accessed on 10 July 2023)	1: URL https://cctvs.freeway.gov.tw/live-view/mjpg/video.cgi?camera=1096 (accessed on 29 September 2022)	1: URL https://cctv-ss06.thb.gov.tw:443/T1-321K+710(S) (accessed on 29 September 2022)
+Schema for observation [0..1]:string		1: SensorThings API(from the SensorThings API Things class) https://sta.ci.taiwan.gov.tw/STA_WaterResource_v2/v1.0/Things(820) (accessed on 10 July 2023)	1: URL https://cctvs.freeway.gov.tw/live-view/mjpg/video.cgi?camera=1096 (accessed on 29 September 2022)	1: URL https://cctv-ss06.thb.gov.tw:443/T1-321K+710(S) (accessed on 29 September 2022)

further focuses on the mapping results of the 15 metadata elements required for the four workflow lists in Section 3.4, as they are considered to be the essential information for the successful operation of the proposed mechanism. Each element in the table includes the type of mapping, the mapped metadata element, and an example of the recorded information. The content of metadata elements of Type 3 is established by manually referencing to the available online resources or specifications.

Taking the Type 1 metadata elements of System 1 as an example, the name can be directly converted to ID, stationName can be mapped to the street address, and OrgName can be mapped to the service provider. The names of the metadata elements may be different, but the recorded information can be directly used. The metadata elements CCTVID, SubAuthorityCode, and RoadSection/Start exhibited similar mapping results. The results showed that mapping is schema-dependent and must be custom by developed.

A typical example of a Type 2 metadata element is the deployed location. The proposed recording is based on the class GM_Point, which can record the X, Y, and Z coordinates of the sensor by referencing the chosen coordinate reference system. All the analyzed sensor systems use two elements, latitude (PositionLat) and longitude (PositionLon), to record the coordinates. As this <latitude, longitude> and its referenced CRS (e.g., WGS84) can be seen as a special case of GM_Point, the process of copying and pasting coordinate information is not a complex task.

The most challenging task is to determine the content of Type 3 elements because there is no information available directly. The required content must either refer to other documents or be derived from obtained information. For example, an element of a visible object records the ID of the objects visible from a CCTV camera. This can be determined by the viewshed operation of the GIS software (e.g., ArcGIS Pro) if the information of the 3D features (e.g., building) in the neighborhood and the 3D FOV of the camera are available. After mapping, all the established standardized metadata of each sensor and its service were recorded in PostgreSQL.

4.3. Workflow Test

The workflow entails searching for appropriate sensor systems, gathering observations, and updating the monitoring list during a simulated disaster based on flood simulation data. The details of the workflow are outlined below.

• Assume a disaster at (23°03′46.15″ N 120°17′12.92″ E) is reported on 5 November 2022 at 04:32, as illustrated by the arrow symbol in Figure 7. A spatial constraint of buffered distance (500 m) and the element of metadata “Deployed location” of sensors are used for searching sensor deployed in the neighborhood via ArcGIS Pro. Any sensors whose location was within the search constraints were added to the list of candidates.
• In addition to spatial constraints, the search for sensors further considers the types of sensors related to the flooding scenario, i.e., water level meters and CCTV cameras in this example.
• After two types of searches, one water level station (ID 284) and three CCTV cameras (ID 1639, ID 44, and ID 497) were selected (Figure 7). The selected sensors were added to the candidate list for further analysis.
• For the CCTV systems in the candidate list, the FOV information is obtained from the “3D FOV” metadata element and illustrated in the visual interface, as shown in Figure 7.
• From the map-based interface, only a portion of the experimental area is covered by the three cameras; there is no overlap among their coverage areas, and the commander knows which area they will be supplied with continuously updated information. The recorded information of every camera in the candidate list must be visually inspected to determine whether there is a flood in the coverage area. For the three elements of the designed metadata elements, “ServiceURL”, “Operation”, and “observation”, the URLs are used for establishing the required link (for example, the URL for the camera with ID 1639 is https://cctv-ss06.thb.gov.tw:443/T1-321K+710(S)/snapshot. accessed on 6 July 2023). If a flood was visually confirmed from the acquired image, the corresponding CCTV image was added to the monitoring list. In this example, although the location of the reported disaster is not visible, we assume that the disaster was visually confirmed in all three CCTVs; therefore, all of them are added to the monitoring list.

6.

For the water level meter, observations obtained from the metadata element “Observation_Result” is compared against the metadata element of “Warning” to determine whether a warning should be issued. All sensors that qualified for the specified constraints were added to the monitoring list (

Table 8. Monitoring list device’s metadata designed by disaster notification locations.

Devices	ID	Type	Deployed Location	Authority	Visible Object	Disaster Report Time	URL
Camera	ID 497	Camera	120.287155; 23.059651	Freeway Bureau, MOTC	Null	5 November 2022 04:32	https://cctvs.freeway.gov.tw/live-view/mjpg/video.cgi?camera=1096 (accessed on 29 September 2022)
	ID 1639	Camera	120.28867 23.06608	Directorate General of Highways Ministry of Transportation and Communications	18,542, 18,562, 18,547, 18,551, 15,942, 17,193, 17,187, 17,206, 17,185, 17184, 17,183, 18,529, 15,403, 18,528, 17182, 18,533, 18613	5 November 2022 04:32	https://cctv-ss06.thb.gov.tw:443/T1-321K+710(S)/snapshot (accessed on 29 September 2022)
	ID 44	Camera	120.289403; 23.062014	Water Resources Department (in conjunction with Tainan City Government)	water_level_meter_284, 15,886, 15,892, 15,879	5 November 2022 04:32	https://iapi.wra.gov.tw/v3/api/Image/737a9cf5-6423-4da8-8911-eb21d709a7fd (accessed on 23 November 2022)
Water level meter	ID 284	Water_Level_Meter	120.289403 23.062014	Water Resources Department of the Municipality of Tainan	Null	5 November 2022 04:32	Null

). On 2022/11/05 at 04:42, the sensors ID 284, ID 44, ID 497, and ID 1639 were continuously monitored until the disaster ended. With the selected metadata elements, the recorded information in the monitoring list provides a quick summary of the sensors, which can provide an immediate reference for the ongoing disaster. A typical operation involves simultaneously displaying continuously updated observations of the monitored sensor on the dashboard for further emergency response reference.

7.

Assume the commander receives a new disaster report (23°03′34.0″ N 120°17′26.1″ E) at 2022/11/05 06:28; as illustrated in Figure 8, the buffered distance (500 m) and “Deployed location” of sensors are used. Steps 1–6 were repeated to update the candidate and monitoring lists. In this case, one CCTV camera (ID 44) and one water-level meter (ID 88) were added to the monitoring list at 2022/11/05 06:37. One CCTV camera (ID 1639) was removed from the monitoring list at 2022/11/05 10:48 after visual inspection. When the returned observations of the floodwater level were lower than the water level warning set value, ID 284 was removed from the monitoring list at 2022/11/05 10:04. Similarly, the water level of the flood sensor of ID 88 was lower than the warning setting value; the monitoring list became empty at 2022/11/05 12:12.

8.

Because the observations of all the sensors in the monitoring list record confirmed information for certain aspects of the disaster, they should be kept as a reference for disaster history. In addition to the information regarding the identification of sensors (ID, Device Type, Authority) and location (Deployment Location), temporal information must record the time a particular sensor is added and removed from the monitoring list (

Table 9. Disaster list database result.

Devices	ID	Type	Deployed Location	Phenomenon_Time (Begin/End)	Authority
Camera	ID 44	Camera	120.289403; 23.062014	2022-11-5T04:42:00.000Z/ 2022-11-5T12:39:00.000Z	Water Resources Department (in conjunction with Tainan City Government)
	ID 497	Camera	120.287155; 23.059651	2022-11-5T04:42:00.000Z/ 2022-11-5T12:39:00.000Z	Freeway Bureau, MOTC
	ID 1639	Camera	120.28867 23.06608	2022-11-5T04:42:00.000Z/ 2022-11-5T10:48:00.000Z	Directorate General of Highways Ministry of Transportation and Communications
Water level meter	ID 284	Water_Level_Meter	120.289403 23.062014	2022-11-5T04:42:00.000Z/ 2022-11-5T10:04:00.000Z	Water Resources Department of the Municipality of Tainan
	ID 88	Water_Level_Meter	120.291294 23.056533	2022-11-5T04:42:00.000Z/ 2022-11-5T12:12:00.000Z	Water Resources Department of the Municipality of Tainan

). The title of this disaster event should be assigned to the table of the disaster list, which can be traced back to provide a reference for all disasters that occurred in this area. All related observations are stored in a database and can be accessed via a unique sensor ID and specified time period.

5. Conclusions

With the rapid growth of urban populations and huge demands for infrastructure, effectively taking advantage of available geospatial sources to improve citizens’ quality of life is a necessary consideration of digital governance for smart cities. However, the heterogeneity of sensor systems impedes collaborative sharing of information among different stakeholders. This study proposes a standard-based approach to overcome these communication obstacles and establish an interoperable resource-sharing mechanism. Using standardized metadata, the common and unique properties of various sensor systems were described. This design enables the search for heterogeneous sensor systems across different domains and stakeholders as long as their sensor systems are registered in the management mechanism. Standardized metadata play a major role in supporting observation requests, interpretation, and decision making during the disaster response phase. By choosing flooding as the test target, the four lists in the proposed workflow demonstrate how the appropriate design of metadata can successfully bridge the need for disaster updates and information collected from heterogeneous sensor systems to reduce damage. From a smart city perspective, the effective coordination of available geospatial resources and the facilitation of cross-domain collaboration for the chosen applications are necessary. Standardized metadata and service approaches have proven to be effective solutions for building a transparent sharing environment for sensor systems. A well-designed infrastructure for sensor systems plays a key role in the sustainable development of smart cities.

While this study focuses on introducing standardized metadata to remove the barriers to the integrated use of sensor systems and expand the capacity of disaster response mechanisms, the discussion is restricted to demonstrating the feasibility of the proposed approach with a limited number of sensors and simulated observations. Additional tests must be conducted to evaluate the operational performance of the proposed system architecture by increasing the number of sensors. As disaster situations become more complex, additional types of sensors and logic rules must be considered in future studies. The mapping between different metadata schemas and the promotion of standardized metadata also requires more attention to simplify the metadata harvesting process.