A Sensor Web and Web Service-Based Approach for Active Hydrological Disaster Monitoring

Abstract

Rapid advancements in Earth-observing sensor systems have led to the generation of large amounts of remote sensing data that can be used for the dynamic monitoring and analysis of hydrological disasters. The management and analysis of these data could take advantage of distributed information infrastructure technologies such as Web service and Sensor Web technologies, which have shown great potential in facilitating the use of observed big data in an interoperable, flexible and on-demand way. However, it remains a challenge to achieve timely response to hydrological disaster events and to automate the geoprocessing of hydrological disaster observations. This article proposes a Sensor Web and Web service-based approach to support active hydrological disaster monitoring. This approach integrates an event-driven mechanism, Web services, and a Sensor Web and coordinates them using workflow technologies to facilitate the Web-based sharing and processing of hydrological hazard information. The design and implementation of hydrological Web services for conducting various hydrological analysis tasks on the Web using dynamically updating sensor observation data are presented. An application example is provided to demonstrate the benefits of the proposed approach over the traditional approach. The results confirm the effectiveness and practicality of the proposed approach in cases of hydrological disaster.

1. Introduction

In the big data era, Earth observation technologies provide powerful capabilities to obtain enormous amounts of diverse geospatial data in an on-demand and continuous fashion [1]. For example, the NASA Earth Observing System Data and Information System (EOSDIS) collects approximate 22 terabytes of data per day via orbital and airborne sensors [2]. Hundreds of Earth-observing satellites are currently in orbit and performing various observation tasks. These satellites, such as Landsat, MODIS, and the GF series, play an important role in monitoring regional water resources by collecting many spatial, spectral, radiation, and time-scale observation products that reflect chlorophyll, suspended solids, and turbidity in the water [3]. The Geospatial Data Abstraction Library (GDAL) is widely used to access and process raster and vector geospatial data [4]. It is an open-source geospatial library that supports the translation and processing of data in common geospatial formats such as GeoTIFF, Arc/Info ASCII Grid, and ESRI Shapefile. The integration of the enhanced GDAL with geographic information systems (GIS) can facilitate the processing of Earth observation data [5]. Hydrological Earth observations can be processed to support the monitoring and analysis of hydrological disasters, such as flood disasters and water pollution. The entire data processing workflow can be accomplished locally or remotely using distributed information infrastructures such as spatial data infrastructures or cyberinfrastructures. Traditionally, desktop GIS software (e.g., ENVI or GRASS) or tools are usually used to process data step by step [6,7]. In a remote approach, large volumes of data and powerful computing resources are encapsulated as services with standard interfaces and protocols to enable Web-based sharing and automatic access, thus significantly enhancing the ability to use online/near-line data over the Web and allowing the widespread automation of data analysis and computation [8].

The Open Geospatial Consortium (OGC) has developed a number of specifications for standardizing geospatial Web services, including the Web Coverage Service (WCS), Web Map Service (WMS), Web Feature Service (WFS), and Web Processing Service (WPS) standards [9]. Consequently, various sensors, geospatial data, and geoprocessing functions can be wrapped into such services according to these standards to promote the widespread sharing of and on-demand access to these resources in a distributed environment. Geospatial Web services can be used in various application domains to enable automatic monitoring and analysis [10]. The complex geoprocessing associated with existing geospatial data and geoprocessing services can be implemented as service chains to perform complex data analysis and computations [11,12,13].

Hydrological disasters can cause tremendous losses of life and property [14,15]. These hazards are defined as violent, sudden, and destructive changes occurring on land, at sea, or in the atmosphere and are characterized as emergency events [16]. Active hydrological disaster monitoring is important for discovering hazard states and tracking their evolution. Formulating strategies for hydrological disaster monitoring includes not only the development of hydrological models and programs but also the integration of Web-related technologies and traditional hydrological methods. For example, the Simulation of Hydrological Extreme Events (SHEE) software has been developed to display, analyse and interpret hydrological processes (e.g., spatial and temporal rainfall distributions, soil moisture states and water routing tendencies) in watersheds based on records of rainfall and flow [17,18]. Traditional distributed hydrological models, such as the TOPography-based hydrological MODEL (TOPMODEL) [19], the MIKE SHE model [20] and grid-based distributed hydrological models (GB models) [21], are continually being improved to enhance their performance and practicality for predicting watershed runoffs, simulating water flows and forecasting floods [22,23,24]. With advancements in Web-related technologies, Web service technologies have begun to be used in hydrological risk management and disaster monitoring to provide an integrated solution for disaster warning, data collection, data processing, and results visualization. Adhering to the Web service approach, TOPMODEL has been implemented in the form of Web services that can be easily accessed through the OGC WPS interface and protocol over the web [25,26,27]. A rainfall–runoff model LISFLOOD [28], which is a GIS-based distributed model, has been proposed for the simulation of runoff and flooding in hydrological processes [29]. DP Ames et al. have presented the design and implementation of a Web service-based software package named HydroDesktop for discovering, downloading, managing, visualizing, and analysing hydrological data [30]. Several researchers are committed to introducing specific data platforms (e.g., the Malawi Spatial Data Platform (MASDAP)) that couple GIS technologies with hydrological processes to perform step-by-step analyses [31]. Sensor Web technologies can provide real-time or near-real-time observations to support disaster management [32]. The OGC Sensor Web Enablement (SWE) framework is employed in hydrological hazard monitoring and is used to make multi-source heterogeneous Sensor Web resources (e.g., sensors, sensor services, observations, and events) available on the Web [33]. To meet the requirements for the monitoring of various hydrological scenarios, these Sensor Web resources are executed in on-demand combinations to enable users to access hydrological information in a timely fashion. The contribution of this paper is to integrate the SWE and WPS components to allow hydrological observations to be linked to appropriate geoprocessing services on demand to perform active processing.

Once a hydrological hazard event occurs, a key challenge is to achieve a timely response to that event and perform automatic geoprocessing for hydrological disaster monitoring. This paper presents a Sensor Web and Web service-based approach for active hydrological disaster monitoring. The proposed approach leverages Sensor Web and Web service technologies and adopts an event-driven mechanism for the online processing of hydrological hazard information. The design and implementation of hydrological Web services are presented. The services are chained into workflows and executed using a workflow engine to enable complex hydrological hazard analyses. The hydrological disaster event of interest is input into an existing workflow tool for automatic triggering of the service chains. Compared with the traditional hydrological analysis approach, the proposed approach supports active event-based processing. An application example is provided to demonstrate the benefits of this approach.

The remainder of the article is organized as follows. Section 2 describes the user requirements of the proposed system and presents the relevant materials and methods. Section 3 introduces the system design and implementation for the proposed approach. Section 4 presents the case study. An evaluation and discussion are presented in Section 5. Conclusions and guidelines for future work are given in Section 6.

2. Materials and Methods

2.1. User Requirements

Traditionally, hydrological users download data into desktop computers and use desktop image processing software to process these data. The process of generating decision support information, such as turbidity maps, is often laborious, inefficient, and time-consuming. In addition, the process is difficult for hydrological users who have limited GIS skills and software experience. It would therefore be beneficial to adapt the traditional desktop mapping method into on-demand mapping service to reduce the resource costs and skill requirements on the end-user side.

Information infrastructure technologies (e.g., Sensor Webs, geospatial Web services, and Web-based workflows) offer new tools for hydrological mapping. Hydrological maps can be delivered on demand by chaining distributed geospatial services. These services are chained into workflows and executed using a workflow engine to enable complex hydrological hazard analyses and timely response to hydrological events. To meet the needs of users with different levels of background knowledge and computer skills, different types of service chaining should be developed. The OGC Abstract Service Architecture identifies three types of service chaining: transparent chaining, translucent chaining, and opaque chaining [34]. Transparent chaining, also called user-defined chaining, is often adopted by professionals who are skilled in geospatial analysis and the use of geospatial services. They are able to manage the execution of the chains by themselves. In translucent chaining, also called workflow-managed chaining, workflow engines control the service chains. The invocation of services is hidden, and users focus on the formulation of business-level workflows. In opaque chaining, users are completely separated from the backend workflows and services. In the context of hydrological disaster analysis, domain experts can design workflows using workflow tools operating in drag-and-drop mode. These workflow tools bind and invoke services to enact workflows. Once a workflow has been archived and can be accessed as a whole as a new service, general users or decision-makers can use that workflow in the opaque chaining approach by invoking the new service.

Earth observation technologies coordinated with Sensor Webs can support real-time or near-real-time data provision. Distributed geospatial data obtained from Earth observations can be accessed through standard geospatial data services. To perform complex and real-time hydrological monitoring tasks, it is necessary not only to share data and geoprocessing functions over the Web but also to coordinate sensor observations and geoprocessing functions in an event-based manner. The automatic geoprocessing of hydrological hazard events is urgently needed by experts to help them react as soon as possible. An event-driven mechanism can help to achieve this goal.

2.2. Sensor Web and Event-Driven Mechanism

A Sensor Web is a collaborative observation system that is composed of heterogeneous sensors and associated systems [35]. The OGC Sensor Web Enablement (SWE) Architecture defines a set of standard information models and service interfaces for discovering, publishing, and collecting Sensor Web resources [36]. The SWE specifications include the Observations and Measurements (O&M), Transducer Markup Language (TML), Sensor Model Language (SensorML), Sensor Observation Service (SOS), Sensor Planning Service (SPS), Sensor Event Service (SES), and Web Notification Service (WNS) standards. This technology is playing a more and more significant role in disaster management and environmental monitoring [37]. It allows the on-demand provision of real-time or near-real-time observations, thereby enabling live geoprocessing to support a timely response to hydrological hazard events.

Figure 1 shows the typical use of Sensor Web services. In the context of hydrological disaster management, they can be used for event subscription, sensor tasking and observation access. Each user should first register a WNS ID to receive notifications. They can subscribe to certain hydrological events, such as cases in which the water turbidity exceeds a given threshold. The processes by which sensor observations are collected can be divided into two types. One type is based on regular time intervals, and the other is based on notifications from a WNS service. In the example of Figure 1, SOS1 is defined to provide in situ sensor observations at regular time intervals. The SES will continuously monitor observations from in situ sensors obtained through SOS1. When it finds observations exceeding a specified threshold, it will notify users through the WNS. Users can assign satellite sensors observations tasks through the SPS. When the planned sensors are in place, the SPS will instruct the WNS to send a message to the users. Users can then submit GetObservation requests to SOS2 to obtain remote sensing observations. These observations are automatically sent to the WPS for live geoprocessing.

Generally, an event is defined as anything that occurs or is triggered by certain factors [38]. In the Sensor Web environment, each observation can be defined as an event. There are four logical layers in the event processing flow, namely, the event generator, the event channel, the event processing engine and the downstream event-driven activity [39]. The event-driven method can play an important role in the management and monitoring of hydrological disasters [40]. Figure 2 illustrates the event-driven mechanism. Users can subscribe to an event with certain filter criteria [41]. These filter criteria will be further encoded as an event pattern that defines rules, such as filters, for event processing. These filters, such as sensor identifiers and observation properties, can be used by the event generator. Sensor observations can be made available in real time or near real time through the SOS interface. These observations are retrieved by regularly sending GetObservation requests to an SOS and then are parsed to produce observation events. These observation events are pushed into an event channel and compared with the threshold specified in the event pattern. An SES can perform filtering based on various criteria, such as threshold values (e.g., a sediment concentration equal to 50 mg/L). Once some observations have passed the threshold, the detection of an event is alerted, and the SES will work with a WNS to activate new sensor observations and geoprocessing workflows. Such an event-driven mechanism is adopted in the proposed approach for hydrological event processing.

The proposed system for active hydrological monitoring relies on standards-based interoperable services. The OGC Web Service standards, including the Sensor Web standards, are typically adopted when developing hydrological Web services [37]. The event-driven mechanism is implemented based on Sensor Web standards such as SOS, SES, and WNS. The processing of the sensor observations follows the WPS standard, which specifies a standard interface and protocol for offering geospatial processing functionalities to clients over the Web. The provision of services following these standards allows the plug-and-play implementation of hydrological Web services and improves the flexibility of service binding for geoprocessing workflows.

3. System Design and Implementation

3.1. Architecture Design

Figure 3 shows the architecture of the Sensor Web-enabled hydrological Web service system. The system not only allows hydrological analysis functions to be wrapped as geoprocessing services following the OGC WPS standard but also enables event-driven integrated geoprocessing on the Web for active hydrological disaster monitoring. A three-tier architecture is adopted in the system, including application, business, and data tiers.

The data tier is responsible for the management and release of real-time and historical observation data from the Sensor Web. Sensor systems in the emerging information cyberinfrastructure can provide various observations from in situ and remote sensors. These observations can be retrieved and accessed using standard operations such as GetObservation requests via the SOS interface. Observation data and data URLs are returned to clients based on standard information transmission protocols.

The business tier focuses on the integration of hydrologic services. For the realization of active hydrological disaster monitoring using the proposed Sensor Web and Web service-based approach, the core component is the event processing middleware. It takes hydrological events from the Sensor Web as inputs, processes them in accordance with event patterns, and activates geoprocessing workflows to generate live products. When an abnormal event is detected, new observations can be tasked and acquired in time. These observations will be delivered to the workflow module. The workflow module includes three sub-components: the workflow modeller, the workflow binding component, and the workflow engine. The workflow modeller generates an abstract process model consisting of the control flows and data flows among atomic processes. The workflow binding component instantiates this abstract process model into a concrete workflow or executable service chain by binding the atomic processes to services. The executable workflows or service chains are then executed by the workflow engine to generate on-demand data products. When observations are sent to workflows, those workflows can be activated to perform live geoprocessing, thereby providing timely decision support information when specific hydrological hazard events occur.

The hydrological analysis functions are accessed through the OGC WPS standard interface. On the internal side, hydrological geoprocessing processes are implemented by calling APIs of the algorithm libraries in existing GIS software systems. Legacy hydrological analysis functions, in the form of geoprocessing services, are deployed on a Web geoprocessing application server. The request/response messages for these hydrological processing services can be parsed by either a servlet or JSP container. Then, the WPS operations specified in the messages will be processed in the WPS request/response handling module. The execution of these processes will call the necessary hydrological analysis programs. These hydrologic geoprocessing services can be published in a registry and discovered on the Web. Users can design workflow models via a workflow designing tool, and these models can later be transformed into executable workflows by binding the hydrological geoprocessing services discovered from the registry. By using interoperable interfaces, hydrological analysis services can be coordinated with Sensor Web services and existing OGC data services to compose workflows for active hydrological monitoring.

The application tier, also known as the client tier, provides a customized interface for interacting with users. Users can invoke services, integrate workflows, issue tasks to sensor systems, collect observations, and visualize geoprocessing results through clients on this tier.

3.2. Implementation

The Web services for hydrological analysis were developed according to the OGC WPS specification version 1.0.0. These services are written based on the JAVA Development Kit (JDK) to enable cross-platform deployment and are deployed onto an Apache Tomcat in a 64-bit Linux operating environment. The services are developed by wrapping existing hydrologic analysis algorithms from legacy software.

• GDAL provides a set of APIs for reading and writing remote sensing imagery. In this implementation, it is used to realize the functionalities of orthorectification, geometric calibration, and resampling. The orthorectification service will be adopted in the later turbidity extraction geoprocessing.
• Several processing algorithms (e.g., radiometric calibration, Normal Differential Water Index (NDWI) calculations, and silt inversion) are listed in Appendix B. These algorithms can derive appropriate data products. Their corresponding C++ programs are packaged as Dynamic-Link Libraries (DLLs). Other algorithms can reuse processing functions in legacy components, e.g., GRASS scripts.
• The above DLLs are finally exposed as Web services via the Java Native Interface (JNI). JNI [42] can make Java code directly call the methods written in other programming languages, including C++. The hydrological analysis processes, which are implemented based on JNI and DLL, include the NDWI calculation and silt inversion functions used for turbidity extraction. Commands/scripts from legacy software can also be wrapped using the JAVA runtime exec method.

The hydrological analysis process for remote sensing imagery consists of two steps: The first is pre-processing the raw images. The second step is conducting the specific hydrological analysis model on the pre-processed images. Both steps depend on the existing mathematical models or algorithms. These algorithms can be connected and integrated to achieve an advanced hydrological hazard analysis. The algorithms were initially written in C++ and were wrapped using JAVA. Take the task of extracting the turbidity in Poyang Lake as a demonstration to introduce the mathematical algorithms applied when calculating the total suspended sediment concentration (TSSC) from GF-1 imagery. The image pre-processing step often includes processes like orthorectification, radiometric calibration, and atmospheric correction.

A common method for Orthorectification is the Rational Polynomial Coefficient (RPC) camera model which takes Digital Elevation Model (DEM) data as input. The RPC model resamples (longitude, latitude, and height) object coordinates into the (line, sample) coordinates. The equation of the model is [43]:

$$\left(L, S\right)=RPC\left({\rm Y}, \varphi , H\right)$$

(1)

where $L$ is the line of the input image, $S$ is the sample index, ${\rm Y}$ is the longitude, $\varphi$ is the latitude, and $H$ is the orthometric height.

A radiometric calibration method can be applied to process imagery with the aid of the calibration coefficients of the WFV2 sensor on the GF-1 satellite [44,45]. The following Equation (2) is used to convert remotely sensed DN values into at-satellite radiances:

$$Lsa{t}_{\lambda }=Gain\times DN+Bias$$

(2)

where $Lsa{t}_{\lambda }$ is the at-satellite spectral radiance in the given spectral band ($\mathrm{W}·{\mathrm{m}}^2·{\mathrm{sr}}^{-1}·{\mathsf{\mu }\mathrm{m}}^{-1}$), $Gain$ represents the gain for the given spectral band ($\mathrm{W}·{\mathrm{m}}^2·{\mathrm{sr}}^{-1}·{\mathsf{\mu }\mathrm{m}}^{-1}$), $Bias$ is the offset for the given spectral band ($\mathrm{W}·{\mathrm{m}}^2·{\mathrm{sr}}^{-1}·{\mathsf{\mu }\mathrm{m}}^{-1}$), and $DN$ is the calibrated pixel grey value.

The COST model is employed to do atmospheric correction [46,47]. It not only corrects the effects caused by the Sun’s zenith angle, solar radiance and atmospheric scattering but also accounts for atmospheric absorption. Its equation is:

$$R_{\lambda }=\mathsf{\pi }\times D^2\times \left(Lsa{t}_{\lambda }-Lhaz{e}_{\lambda }\right)/Esu{n}_{\lambda }{\cos }^2\theta$$

(3)

where λ is the wavelength, $R_{\lambda }$ is the spectral reflectance of the surface, $D$ is the distance between the Earth and the Sun, $Lsa{t}_{\lambda }$ is the at-satellite spectral radiance in the given spectral band, $Lhaz{e}_{\lambda }$ is the atmospheric path radiance, $Esu{n}_{\lambda }$ is the Exo-atmospheric solar irradiance, and $\theta$ is the Sun’s zenith angle.

After image pre-processing, the NDWI calculation, mask building, and silt inversion steps can be linked into a workflow to calculate TSSC. The NDWI, which aims to highlight water features in remote sensing imagery, is calculated by Equation (4). The values of the NDWI range from −1 to 1. Open water surfaces usually have negative values [48].

$$NDWI=\left(Green-NIR\right)/\left(Green+NIR\right)$$

(4)

In the formula, Green denotes the green band and NIR means the near-infrared radiation band.

Finally, the value of TSSC can be calculated from the results of atmospheric correction for bands 2 and 3 [49]. The formula is

$$TSSC=0.4023{\mathrm{e}}^{\left(46.457X\right)}$$

$$X=\left(R_{\lambda } \left({\lambda }_{b2centre}\right)+R_{\lambda } \left({\lambda }_{b3centre}\right)\right)R_{\lambda } \left({\lambda }_{b3centre}\right)/R_{\lambda } \left({\lambda }_{b2centre}\right)$$

(5)

where λ is the wavelength, $R_{\lambda }$ is the spectral reflectance of the surface, ${\lambda }_{b2centre}$ is the central wavelength for band 2 of the GF-1 satellite, ${\lambda }_{b3centre}$ is the central wavelength for band 3, and $X$ is a factor calculated by combining the $R_{\lambda }$ values in bands 2 and 3 obtained from the GF-1 sensor. The procedure is organized and summarized in the following Algorithm 1.

Algorithm 1. Calculate the Total Suspended Sediment Concentration (TSSC) in the Study Area.

Input:

An image pre-processed and represented by a 3-D matrix;

Main algorithm: Clip the inputted image to generate a sub-image of the study area; Calculate the NDWI value of the sub-image using Equation (4); Binarize the result of the NDWI calculation according to a specified threshold (threshold equals to 0) by assigning 1 to those pixels with negative NDWI values and 0 to the rest; Perform mask building for the band-by-band multiplication of the binary image with the pre-processed GF-1 image to extract water areas; Calculate the total suspended sediment concentration (TSSC) using Equation (5).

Output:

An image whose pixel values are the calculated TSSC results.

Figure 4 illustrates the design and implementation of a Web processing service wrapper for the publication of new hydrological analysis services using scripts and DLL functions. Both legacy and new executable hydrological analysis programs are invoked using the JAVA code wrapper by calling shell scripts or JNI interfaces. The list of algorithms is maintained in an internal algorithm store. HTTP requests for WPS GetCapabilities, DescribeProcess, and Execute operations can be processed by servlets and request/response handlers. For example, when a user submits an Execute POST request to a WPS server, the XML document will be parsed to extract the required parameters (e.g., process identifiers). By comparing the identifiers with the algorithms in the internal algorithm store, the appropriate processes can be located. After the completion of geoprocessing, the results will be delivered to the response handler to generate XML responses according to the output data types specified in the response of the DescribeProcess operation.

The 52North Sensor Web community has developed a series of open-source server software for five kinds of SWE services and also client applications [50]. This software is adopted in the Sensor Web service implementation. The workflows are supported by an open-source geoprocessing workflow tool named GeoJModelBuilder [27], which can be used to create and execute workflow models based on user requirements. Figure 5 illustrates the process of workflow-based hydrological service chaining. First, an abstract hydrological workflow model is created according to hydrological business logic. The models are designed by dragging and dropping operations using the workflow tool. The abstract workflow model is then instantiated into an executable service chain by binding hydrological services, such as orthorectification, radiometric calibration, and atmospheric correction services. The workflow tool also supports Sensor Web events as nodes in the models. When an event occurs, the workflow model will be automatically activated, and the chaining result will be executed by the workflow engine to generate the desired data products to support timely decision-making.

4. Case Study

The implemented system has been used for hydrological disaster monitoring. Because of the significance of suspended sediment concentrations in enabling timely warnings of floods and other hydrological disasters, a case of turbidity extraction for Poyang Lake, Jiangxi Province, China, was selected for study. Poyang Lake is the largest fresh water lake in China, and it is located in the middle section of the Yangtze River [51]. The period from April to September is the rainy season in this region. During that period, water from the Yangtze River and several other connected tributaries flows into this lake, which frequently causes flood disasters in the region [49]. Floods usually result in excessive sediment concentrations in water bodies [52,53]. The total suspended sediment concentration (TSSC) can be regarded as a quality indicator of water turbidity [54].

This case study demonstrates the use of the proposed approach to monitor excessive sediment concentrations in the study region based on observations recorded by the Chinese GF-1 satellite during the flood risk period. The implemented system was used to generate thematic images representing sediment concentration, which can be used to support subsequent decision-making. The hydrological monitoring process enabled by the implemented information infrastructure technologies, including Sensor Web technologies, geospatial services, and the proposed workflow management approach, is illustrated in Figure 6. Translucent or opaque service chaining in GeoJModelBuilder was used to compose a workflow model for turbidity extraction. As a starting point, a “Water Turbidity” node was added into the workflow for the active triggering of the turbidity extraction process. Distributed observation, data and geoprocessing resources available over the Web were linked into the model in the same way.

In the excessive sediment concentration monitoring, the first step is to subscribe water turbidity events in Poyang Lake through an SES. As Figure 7 shows, users subscribe via a request window by specifying certain filter conditions (sensor identifier, observation property and threshold value) and choose to receive messages from a WNS. All parameters are organized in a set order to generate a standard Subscribe XML request. When the request is received by the SES, an event generator middleware will be regularly activated to send GetObservation requests to an SOS to retrieve in situ sensor observations of the region. Every new observation is treated as an event. Figure 8 shows an instance of the Observation class. The child node in the Contents is the Observation class, which describes one sensor observation using the following elements: id, samplingTime, procedure, observedProperty, featureOfInterest, and result. The TSSC values for the observation are recorded in the result node. According to the event-driven mechanism described in Section 2, observations are pushed into an event channel and compared with event patterns. The values of the child nodes, such as procedure, observedProperty and result, are used to perform filter matching.

When a sediment concentration received from the in situ sensors exceeds the threshold (greater than 50 mg/L), an alert will automatically be sent to subscribers by the WNS. The SES delivers a DoNotification request to the WNS, which will then notify subscribers via a specified means, such as email. The abnormal observation contents are included in the notification message. Once the message is received, the responder workflow begins to plan and schedule sensor resources for coordinated observations among multi-source sensors, such as satellites or unmanned aerial vehicles (UAVs). The next step is to access the new observation data through the SOS. Remote sensing data from Earth observations are provided by the SOS instead of needing to be manually downloaded. Because an SOS can provide real-time or near-real-time observations, it can avoid the time delays incurred in manual operations and communication. The remote sensing data will be automatically sent to the “Water Turbidity” workflow for live geoprocessing. Finally, the hydrological geoprocessing workflow will be automatically executed to process the new observations.

This case study demonstrates that the event-driven service method is able to assist with event subscription, detection, notification and response in a real flooding scenario. The proposed approach can reduce the complexity of hydrological resource retrieval, spatial analysis processing, information extraction, message notification and map generation compared with the traditional manual monitoring approach. Users often process local remote sensing data manually using desktop analysis software. Using the proposed approach, however, users need not check observations on a regular basis to recognize when an anomaly has occurred.

5. Evaluation and Discussion

5.1. Evaluation

To evaluate the effectiveness and practicality of the proposed approach, we performed two experiments. One was to compare the processing performance between the traditional manual hydrological processing method and the event-driven service approach. The other was to assess the execution efficiency by executing the turbidity extraction workflow/services on different servers. The input observation was obtained from the sensors on the Chinese GF-1 satellite. For the chosen example observation recorded on 21 September 2014, the image volume is 0.98 GB. The turbidity extraction workflow includes the following processes: orthorectification, radiometric calibration, atmospheric correction, clipping, NDWI calculation, mask building, and silt inversion.

Figure 9 illustrates the performance results in the first experiment. Both Test 1 and 2 are performed on regular personal computers (PCs), each equipped with a 3.60 GHz Intel(R) Core(TM) i7 processor and 8.0 GB of memory, running the Microsoft Windows 10 operating system. Traditionally, hydrological users often use a local approach, in which they manually process data using desktop GIS software or tools. In the manual approach (Test 1), ten graduate students with sufficient background knowledge and computer skills were invited to participate in the experiment. They were trained to perform the necessary manual operations using desktop GRASS software. The time cost (e.g., 40.27 min) by each student in Test 1 was recorded, starting from when the input data is opened in the GRASS software and ending at the completion of all the operations. In the workflow approach (Test 2), the executable workflow for turbidity extraction was performed ten times using services deployed on distributed PCs on a local network. The execution time (e.g., 20.73 min) for each execution of the workflow in Test 2 was recorded, starting from the invocation of the workflow and ending with the return of the response. To avoid contingency effects, each execution time for the proposed approach was calculated as the average of the time costs of ten executions of the workflow. Figure 9 illustrates the obtained performance results. Compared with the proposed approach, the time curve for the manual approach shows significant fluctuations because of the variations in operation proficiency from person to person. The performance of the proposed approach is relatively stable because it is conducted automatically by computers, with little human intervention. Based on the results of the experiments, it can clearly be concluded that the proposed approach exhibits superior performance compared with the traditional method in terms of saving time and effort and shortening the wait times for endpoint consumers of hydrological disaster information.

The performance was further improved when the hydrological analysis services were migrated to high-performance computing servers. Figure 10 presents the results of performance tests conducted with the turbidity extraction services deployed on new servers (Test 3) with Intel(R) Xeon(R) E5-2692v2 2.20 GHz processors and 32.0 GB of memory, running Linux Ubuntu 12.04. These tests were performed in the same pattern with Test 2 to determine the actual effects on time costs. As shown in Figure 10, the time cost for executing the turbidity extraction workflow on high-performance servers is much lower than that for execution on PCs. The reason is that in this case, the Web services can automatically take advantage of remotely distributed computational resources, retrieve observations from various sources and perform hydrological analyses on them, following the previously designed steps of the workflow model. It should also be noted that the experiments were conducted over a local area network (LAN) with a speed of 1 Gbps. For a wide area network (WAN) with a lower transmission speed and a narrower bandwidth, additional optimized strategies will be necessary for the deployment of services on different servers; for example, several services may need to be deployed on a single server, or certain services may require servers with better connections. This task is beyond the scope of the current paper and will be studied in the future.

5.2. Discussion

Based on the experiment, the proposed workflow approach can offer several benefits for hydrological disaster management, compared with the traditional method in Test 1.

Table 1. The advantages of the proposed approach.

Category	Traditional Method	Proposed Approach
Workload	Heavy	Light
Resource utilization	Local resources	Distributed resources
Automation	Manual processing	Automatic processing
Time	Long	Short
Professional skills	High	Low
Error prone	Often	Rarely
Usability	Low	High
Knowledge sharing	Low	High

provides a comparison of the two approaches.

(1) From the perspective of hydrological users, the proposed approach provides a convenient and user-friendly way for users to interact with elementary hydrological analysis capabilities and utilize them in real hydrological disaster monitoring cases. The complexity of the technical details is hidden behind the workflow models, thereby significantly lowering the barrier to entry for users. The standardized service interfaces allow workflow models to be used to assemble hydrological services into workflows for complex tasks in a plug-and-play fashion. By contrast, traditional manual processing can only be performed by professionals with rich background knowledge and computer programming skills.

(2) From the perspective of hydrological services, the service-oriented hydrological analysis approach does not rely on any specific software or programs installed on users’ personal machines. The analysis can be conducted remotely via Web services. The use of standard interfaces allows various hydrological service providers to contribute reusable service modules that can be dynamically integrated into large Web-executable workflow models for use by others in the community as part of the implementation of the system as a whole.

(3) From the viewpoint of hydrological workflows, the proposed service approach achieves automated hydrological processing through an event-driven workflow execution process. By contrast, traditional manual methods require a high level of professional skill from endpoint users and are highly time-consuming and prone to error. The workflows automate the execution of business logic and can produce on-demand hydrological data products more quickly, with little or no manual intervention and fewer opportunities for error, which is especially beneficial for monitoring on-going hydrological disasters.

(4) From the viewpoint of knowledge management, existing workflow models allow analysts to interactively construct new, more complex workflow models. The knowledge of hydrological modellers is formulated and stored during the construction of workflow models. Through the sharing, reuse and addition of workflow models and service chains, this community-involved and open approach allows the system to grow and become more intelligent, gaining more powerful capabilities, as knowledge is continuously shared and accumulated. As knowledge about various aspects of a hydrological disaster becomes more certain, the results of the even-driven processing workflow will also become more accurate and reliable.

6. Conclusions and Future Work

This paper introduces an approach for developing a Web service system to support active hydrological disaster monitoring in a distributed Web environment. It presents a comprehensive design and implementation of automated real-time geoprocessing services for the processing of hydrological hazard information. By means of the integration of Sensor Web services, geoprocessing Web services and workflow technologies, the approach not only provides an interoperable and agile solution for performing hydrologic analyses in a community-involved, distributed Web environment but also allows reusable hydrological service modules to be accessed and linked together in an event-driven manner. The proposed system performs more automatic and intelligent data processing to facilitate the response of hydrological disaster decision-makers to hydrological hazard events and provide them with decision support based on sensor observations in a timely manner.

Future work will focus on improving the capabilities of the system and on applying it to the physical sensor networks deployed in Poyang Lake. As the lake is the largest fresh water lake in China, sensor networks have been widely installed in this area for active hydrological monitoring. We will further enrich the developed hydrological analysis services with more sophisticated domain-specific algorithms. In addition, we will apply event-driven processing to more different types of sensors in Poyang Lake to support more complex event-driven patterns.