RiBaSE: A Pilot for Testing the OGC Web Services Integration of Water-related Information and Models
Lluís Pesquer Mayos, Grumets Research Group CREAF Edicifi C, Universitat Autònoma de Barcelona
08193 Bellaterra, Spain l.pesquer@creaf.uab.cat
Christoph Stasch,
52°North Initiative for Geospatial Open Source Software GmbH
48155 Münster, Germany c.stasch@52north.org
Simon Jirka,
52°North Initiative for Geospatial Open Source Software GmbH
48155 Münster, Germany s.jirka@52north.org
Joan Masó Pau,
Grumets Research Group CREAF Edicifi C, Universitat Autònoma de Barcelona
Bellaterra, Spain joan.maso@uab.es
David Arctur,
Center for Research in Water Resources, University of Texas at Austin 10100 Burnet Rd Bldg 119, Austin, TX USA
david.arctur@utexas.edu
Abstract—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.
Keywords—Interoperabilty; WaterML; flood modeling; river basin management; OGC; WPS
I. 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 [1]
in the OGC compliance program [2]. Notwithstanding, some current efforts are progressing in this sector, e.g. the Sensor Web Enablement (SWE), where the corresponding working group develops standards to integrate sensors into the Geospatial Web [3]; and a second example is the WMO Hydrology Domain Working Group that close collaborates with the World Meteorological Organization (WMO) Commission for Hydrology [4]. Furthermore, the level of interoperability that may be achieved using these standards in different application scenarios and study areas has not yet been fully evaluated, specifically the lack of interoperability between information provided by sensors and the processing services and alerts.
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 model providers and decision makers.
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
• the adaptability of common spatial standards to water applications
and coordinated by the OGC, an Interoperability Pilot, called RiBaSE, is designed for testing:
• 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 [5]. This paper describes the overall approach of this pilot, key standardization issues, and corresponding solutions for a global interoperable workflow for supporting decision makers in an inland flood risk situation.
II. INTEROPERABILTY PILOT DESIGN
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 [6] and [7] have demonstrated the possibilities for the integration of some hydrological applications with OGC standards, however a complete interoperable workflow (from the primary data sources, to final outputs, including all processing models) still needs to be designed and developed.
1 http://www.waterinneu.org
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.
Fig. 1. Pilot workflow
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 [8].
The services considered in this workflow can be classified by their main functionality as:
• Data exchanging: NetCDF and WaterML translator
• Modeling: WPS flood simulation
• Delivering: WCS (raster), WFS (vector), SAS (alerts)
• Visualization: WMS (maps)
Acronym Standards Specifications
netCDF CF
SAS draft
SOS 2.0
WaterML 2.0
WCS 2.0
WFS 2.0
WPS 1.0
Table 1. Where to find the complete information corresponding to the OGC standards referred to in the architecture diagram
The general workflow that integrates all these components in a flooding scenario is structured in four concrete experiments:
• Experiment #1: Extract WaterML 2.0 from the SOS 2.0 Hydrology Profile for the desired area and time.
• 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 [9]. Hence, the pilot can evaluate the application of the SOS Hydrology profile.
The threshold for Experiment #2 is being recalculated for each study region considering the statistics of the previous executions.
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.
III. MODEL IMPLEMENTATION
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 [10], TauDEM2
2 http://hydrology.usu.edu/taudem/taudem5/index.html /HAND [11] or r.inund.fluv (GRASS) [12]. The WPS descriptions are encapsulated in a XML file (example in Fig. 2) containing all the necessary information for server execution.
Fig. 3. First content of WPS ProcessDescription XML file
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
Fig. 3. Workflow of the main operations between WPS server and the corresponding client
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
3 http://52north.org (Figure 4).
Fig. 4. Flood Prediction interface from a 52°North client
IV. CASE STUDIES
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.
Fig. 5. Map location of the three case studies, red polygons over Blue Marble NASA-JPL image
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
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.
in WaterML 2.0 format.
The Severn rises on the northeastern slopes of Plynlimon (Wales) and flows to the Bristol Channel and the Atlantic
4 www.waterinfo.be
Ocean. It is the longest river in the United Kingdom. It is
about 354 km long and its2.
The hydrological dataset is provided by the National River Flow Archive (NRFA) through a SOS hosted in the Centre for Ecology & Hydrology (CEH)5
In these three regions, the terrain is obtained from the ASTER Global Digital Elevation Model 30 m spatial resolution [13]. This resolution is enough for testing the interoperability challenges in present experiment, but a finer resolution would be needed for a more accurate implementation. Other main auxiliary information, also non- time dependent in this study, is the land use database:
CORINE Land Cover [14] (available for Bulgaria and Turkey, but not for Greece in Maritsa). Since both data sets are not dynamic, interoperability efforts are not strictly necessary.
They are prepared next to the server for some implemented hydrological model or for identifying the affected areas.
(Figure 6).
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.
Fig. 6. Response of SOS GetFeatureOfInterest by the CEH server (accessed July 2016)
V. 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.
5 http://www.ceh.ac.uk
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.
ACKNOWLEDGMENT
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.
REFERENCES
[1] J. Yu, P. Taylor, S.J.D Cox and G.Walker “Validating observation data in WaterML 2.0” Computers & Geosciences, vol 82, pp. 98-110, 2015.
[2] Open Geospatial Consortium 2016,
[3] Broering, A., J. Echterhoff, S. Jirka, I. Simonis, T. Everding, C. Stasch, S. Liang, & R. Lemmens (2011): New Generation Sensor Web Enablement. Sensors, 11(3), pp. 2652-2699
[4] Guide to Hydrological Practices,vol. I: Hydrology—From Measurement to Hydrological Information, and vol. II: Management of Water Resources and Application to Hydrological Practices, Sixth edition 2008 and 2009, WMO 168, World Meteorological Organziation, Geneva, Switzerland
[5] A.M. Castronova, J.L.Goodall and M.B.Ercan, “Integrated modeling within a Hydrologic Information System: An OpenMI based approach”
Environmental Modelling & Software 39 263-273, 2013.
[6] R.M. Khattar and D. Ames “OGC and HIS: Implementing WFS and WaterML2 for HydroServer” Proceedings on 7th International Congress on Environmental Modelling and Software, San Diego, California, USA, D.P. Ames, N. Quinn (Eds.), 2014.
[7] A. Almoradie, A. Jonoski, I. Popescu and D. Solomatime “Web Based Access to Water Related Data Using OGC WaterML 2.0”, International Journal of Advanced Computer Science and Applications (IJACSA), EnviroGRIDS Special Issue on “Building a Regional Observation System in the Black Sea Catchment,pp. 83-89, 2013.
[8] J.L. Goodall, B.F Robinson and A.M. Castronova, “Modeling water resource systems using a service-oriented computing paradigm”, Environmental Modelling & Software, Vol 26(5), Pages 573-582, 2011.
[9] A. Volker, S. Jirka, and M. Utech, “OGC® Sensor Observation Service 2.0 Hydrology Profile”,
[10] M. Follum, A.A. Tavakoly, J.D. Niemann, A.D. Snow, “AutoRAPID: A Model for Prompt Streamflow Estimation and Flood Inundation Mapping over Regional to Continental Extents”, In Review 2016.
[11] A.D. Nobre, L. A. Cuartas, M. Hodnett, C. D. Rennó, G. Rodrigues, A.
Silveira, M. Waterloo and S. Saleska, “Height Above the Nearest Drainage – a hydrologically relevant new terrain model”, Journal of Hydrology, 404(1–2): 13-29, 2011.
[12] I. Ferrando, B. Federici, D. Sguerso and R. Marzocch, “The r.inund.fluv tool for flood-prone areas evaluation in GRASS GIS: application to the terminal reach of Magra River”, Geomatics Workbooks (12). FOSS4G Europe Como, 2015.
[13] J.A. Slater, B. Heady, G. Kroenung, W. Curtis, J. Haase, D. Hoegemann, C. Shockley and K. Tracy “Global Assessment of the New ASTER Global Digital Elevation Model,” Photogrammetric Engineering &
Remote Sensing, 77 (4), 335-350, 2011.
[14] European Environment Agency CLC2006 technical guidelines (Publication No.519 17/2007) (2007). Luembourg. Retrieved from
