-The design of an interoperability experiment to demonstrate how current ICT-based tools and water data can work in combination with geospatial web services is presented. This solution is being tested in three transboundary river basins: Scheldt, Maritsa and Severn. The purpose of this experiment is to assess the effectiveness of OGC standards for describing status and dynamics of surface water in river basins, to demonstrate their applicability and finally to increase awareness of emerging hydrological standards as WaterML 2.0. Also, this pilot will help in identifying potential gaps in OGC standards in water domain applications, applied to a flooding scenario in present work.
INTRODUCTION
There are several standardization committees and international organizations relevant for water domain Information Technology (IT) applications: International Organization for Standardization (ISO), World Wide Web Consortium (W3C), Institute of Electrical and Electronics Engineers (IEEE), Organization for the Advancement of Structured Information Standards (OASIS), Open Geospatial Consortium (OGC), Internet Engineering Task Force (IETF), etc. Related to the Infrastructure for Spatial Information in Europe (INSPIRE), the OGC is one of the main players (with the ISO TC211) providing standardized specifications of spatial information and interoperability of the corresponding spatial data services.
The OGC is an international industry consortium of
companies, government agencies and universities participating
in a consensus process to develop publicly available interface
standards. Some successful examples of OGC standards for
general spatial purposes are, for example, the Web Map
Service (WMS) for providing interoperable pictorial maps
over the web and the Keyhole Markup Language (KML) as a
data format for virtual globes. On the other hand,
specializations of common OGC standards for the water
domain, such as WaterML 2.0, a model and exchange format
for water observations and metadata, are not yet as widely
used as the veteran WMS standard. Hence, supporting tools
such as an official WaterML validator are not yet available [
European directives such as INSPIRE, the Water Framework Directive (WFD), or the EU Floods Directive (Directive 2007/60/EC), as well as agendas and roadmaps include many recommendations in terms of harmonization, standardization and interoperability goals. They indeed raise very important challenges for progressing in these issues. In particular, the water sector needs standards for: • • • •
Exchange of geographic information at local, regional and global levels.
Transmission of hydrological information to different agencies and organizations.
Dissemination of hydrological forecasts between different agencies and corresponding own methodologies.
Alerting and Notification between data and providers and decision makers. model
Flood modeling is a paradigmatic example in the water domain where standardization can improve the IT contributions to the society. The increasingly variable climate has seen a rising number of extreme flood events in the last decades. Floods are natural phenomena that cannot be fully avoided, but through the right measures we can reduce their likelihood and limit their impacts. Indeed, floods pose great challenges to decision makers of the meteorological and hydrological agencies and local communities. An interoperable design of all related components in the area of flood forecasting, warning, and emergency response will contribute to the integrated flood management plans on various administrative scales.
In the context of the Horizon 2020 project WaterInnEU1 and coordinated by the OGC, an Interoperability Pilot, called RiBaSE, is designed for testing: • the adaptability of common spatial standards to water applications • the best suitable connection between them • the specific characteristics for the engaging of the WaterML 2.0 in a general geospatial framework.
While there are many examples of data management and
modeling systems as separate tools in the water domain, fewer
examples of integrated systems are set up. The present work
follows the general trend towards standardization in both the
data and the modeling [
The present work aims to design a global approach for one
hydrological issue, an emergency flood scenario, integrating
all related processes in an interoperable way. Previous works
such as [
The whole approach is shown in Figure 1 including the services involved and the client interfaces. Essentially, the monitoring of meteorological data and the hydrological gauges provide input data to a flood prediction model. Depending on countries and agencies, the data is provided in heterogeneous structures and formats, e.g. as plain CSV files or in custom XML formats. In order to ease the integration of different data sources, the Observation & Measurements (O&M) standard and its extension for WaterML 2.0 defines common models and encodings for observation data. In case data inputs are not yet provided in WaterML 2.0 or O&M, a translator component is needed that allows conversion of the data into the WaterML 2.0 structure for providing it via Sensor Observation Services (SOS) or netCDF format in a Web Coverage Service (WCS). The flood model (detailed in the next section) is encapsulated in a Web Processing Service (WPS) allowing the execution of it in Web-based infrastructures. The output of the model is sent to a client for visualization purposes under a WMS and the raw data can be downloaded via a WCS service or Web Feature Service (WFS), which is transactional for a better integration with WPS. These services are launched by the WPS client that controls the status of the WPS and coordinates its outputs and the following processes. At the end of this workflow and, in case of a risk situation for a particular location in a river basin, an alert notification will be sent. Since there is not yet a common standard available for the alerting functionality, new concepts such as encapsulating the event engine in WPS are being elaborated and tested in the pilot. In this architecture, the client applications enable control, visualization and decision support based on the model results, considering data and metadata.
Short descriptions of the standards utilized in these components are as follows (references to these standards are given in Table 1):
NetCDF – Network Common Data Form: It consists of a standards suite that supports encoding of digital geospatial information representing space/time-varying phenomena in a binary file format.
SAS – Sensor Alert Service: It is an event notification service for determining the nature of offered alerts, the protocols used, and the options to subscribe to specific alert types.
SOS – Sensor Observation Service: It defines a Web Service interface which allows querying and receiving observations, sensor metadata, as well as representations of observed features.
WaterML 2.0: It is a standard information model for the representation of in-situ water observation data. In fact, it is a specialization of a more generic standard: ISO/OGC Observations & Measurements. So far, WaterML 2.0 is composed of three parts: Part 1: Time series; Part 2: Ratings, Gauging and Sections; Part 3: Water Quality. This work primarily uses Part 1.
WCS – Web Coverage Service: It defines a standard interface and operations that enable interoperable access to geospatial grid coverage.
WFS – Web Feature Service: It defines a Web interface with operations for querying and editing vector geographic features. The subtype WFS-T (transactional) allows creation, deletion, and updating of features.
WPS – Web Processing Service: It is a standardized
interface that defines a standardized Web-based access to
geoprocessing functionality, as well as rules for standardizing
the inputs and outputs (requests and responses) of geospatial
processing functionality. This is the main component for the
flood model and this solution has been successful for
geoprocessing in other water resource systems [
The services considered in this workflow can be classified by their main functionality as: • • • •
Data exchanging: NetCDF and WaterML translator
Delivering: WCS (raster), WFS (vector), SAS (alerts)
netCDF CF
SOS 2.0
Standards Specifications www.opengeospatial.org/standards/netcdf www.opengeospatial.org/projects/initiativ es/sasie www.opengeospatial.org/standards/sos www.opengeospatial.org/standards/water ml www.opengeospatial.org/standards/wcs www.opengeospatial.org/standards/wfs www.opengeospatial.org/standards/wps
The general workflow that integrates all these components in a flooding scenario is structured in four concrete experiments: Experiment #2: If the readings exceed a threshold, start a WPS 2.0 execution with a hydrological model. Experiment #3: Expose the results of the model using geospatial services to download data suitable for visualization.
Experiment #4: Notify alerts to the relevant emergency services using Sensor Notification Services or similar. This might be more experimental, since there is a lack of official standards. Current work of the OGC Pub/Sub Standards Working Group can be an alternative to take into consideration.
Some recommendations for the suitable integration of the four experiments into the whole workflow need to be considered:
Related to Experiment #1, the SOS can be used to query
O&M data and metadata about sensors in a standardized way.
A specialization of the SOS for the water domain already
exists with the SOS Hydrology profile [
In Experiment. #3, input data (as well as output data) also needs interfaces to be published over the web: stream gauge data and a time series hydrograph (WMS) and gridded data (WCS) are forms suitable for publishing the time series graph and map data.
For Experiment #4, various notifications are triggered depending on the location, timing, and severity of the alert situation.
The model to predict and map inland flood inundation
areas is the core component of the RiBaSE architecture. This
architecture allows any execution model with a complete
description of all processes, options, variables and parameters
involved. This description allows a generic WPS implemented
solution and models from AutoRapid [
2 http://hydrology.usu.edu/taudem/taudem5/index.html
This complete description is the key for the correct interpretation and implementation of the main WPS operations (shown in Figure 3):
GetCapabilities: it describes the service and provides the list of available processing functionality in the instance. DescribeProcess: it is a full description of inputs and outputs of a specific geoprocessing functionality, e.g. parameter names, value types, what parameters are optional or mandatory, default values, etc.
Execute: it runs a process with the inputs provided and returns the corresponding outputs
For this pilot, the WPS is implemented on the server side as a Common Gateway Interface (CGI). Thus it is enabled for wrapping the selected hydrological model and guided by the WPS configuration file. The WPS client instance implemented is provided by 52°North3 (Figure 4).
In order to test the present design, three transboundary regions have been proposed: Scheldt, Maritsa and Severn. Figure 5 shows a short geographical description for these areas.
The Scheldt flows through Wallonia, Flanders and the Netherlands, and discharges in the North Sea at Flushing. This makes it one of Europe’s most densely populated river basin districts. The hydrological dataset has been downloaded from the portal of the Flemish Water Management4 in WaterML 2.0 format.
Maritsa is the largest river in Balkan Peninsula and flows through Bulgaria, Greek and Turkey. A small subsample of data for this study is provided by the East Aegean River Basin in a CSV format.
The Severn rises on the northeastern slopes of Plynlimon (Wales) and flows to the Bristol Channel and the Atlantic
Ocean. It is the longest river in the United Kingdom. It is 2 about 354 km long and its drainage basin area is 11266 km . The hydrological dataset is provided by the National River Flow Archive (NRFA) through a SOS hosted in the Centre for Ecology & Hydrology (CEH)5 (Figure 6).
In these three regions, the terrain is obtained from the
ASTER Global Digital Elevation Model 30 m spatial
resolution [
The three study regions cover a wide range of possibilities of data and metadata availability coming from different agencies and bodies, in terms of format, completeness, accuracy and openness. This is a great challenge for the interoperable goals of the present work and a robust test for the four experiments mentioned previously.
CONCLUSIONS
The work presents the design, the methodology and the requirements of the RiBaSE, an interoperability pilot that is running within the WaterInnEU project. This design pursues to achieve a complete integration of the specific thematic standards, as WaterML, into more mature generic geospatial standards (WMS, WFS, WCS, etc.). The proposed architecture allows testing with different hydrological model implementations in a WPS context. This integration of services and the heterogeneity of three study regions represent an interoperable effort for a more efficient emergency management in a flooding scenario.
Future works will aim to conduct the same architecture with other flooding models and using finer (spatial and time) resolution datasets and examine the expected improvements on the accuracy of predictions.
This work is currently developing within the WaterInnEU project (No 641821) that has received funding from the European Union’s Horizon 2020 research and innovation programme and it is also supported by Catalan Government under Grant 2014SGR-149.