Online watershed boundary delineation: sharing models through Spatial Data Infrastructures

The proposal in this paper is to make accessible the hydrology analysis tools that were developed by our research team in the past years through an interoperable Spatial Data Infrastructure. To this aim we chose to develop add-ons for the geOrchestra OGC-compliant platform. Such add-ons trigger algorithms and retrieve their output in real time through OGC standard WPS. We then introduce a watershed WPS add-on and its functioning modes. In so doing we exemplify the fact that the use of OGC standards make it straightforward (and transparent to the user operating a common web browser) to remotely trigger a process on a distant server, then apply it to distant data present on a remote cartographic server, and drop the outcome onto a third-party cartographic server while visualizing it all on a browser.


INTRODUCTION
Improving the use of spatial data, analysis and modelling tools in the environment remains to be achieved to better support environmental and land-use understanding, management and planning.This observation especially pertains to water management where there is an avenue for improving the availability of public water-related data, and addressing the complexity of the field by providing real-or near real-time answers through the use of sufficiently realistic modelling.
A sound answer to this challenging situation builds on a spatial data infrastructure (SDI) which allows for a wide access to geographical data and takes advantage of the ease of adding various analysis and modelling tools in order to bring extra functionalities to the public, namely a watershed delineation tool detailed in this paper's case study.Such watershed calculation is highly dependant on the quality and accuracy of topographic data: scale and resolution of, and protocol for computing, a digital terrain model (DTM) -itself highly dependant on corrective procedures.As a result a slight variation may lead to dramatic discrepancies in terms of watershed delineation and subsequent on-field resource management.
Our proposal is therefore to integrate a number of functionalities to a SDI based on the Free Open Source Software (FOSS) architecture geOrchestra 1 (2009), with the aim to assist water management (Bera et al., 2015).In this paper we focus on watershed delineation from catchments.
The Geospatial Web now offers solutions and software to exchange data, and to some extent tools, including hydrological modelling ones (Feng et al., 2011;Castronova et al., 2012).However these remain insufficiently interoperable or make a limited use of the potentialities offered by geospatial standards.Therefore, fostering interoperability appears as a priority if these tools are to serve the needs of a growing number of users including: (1) research scientists, as the modelling of hydrological processes and pollution transfer (pesticides, nitrogen, suspended particulate organic matter, etc.) is a prerequisite for better understanding of water and biogeochemical cycles; (2) water managers and administrators: public water managing institutions, local governments, and other professionals with an interest in water quality and availability; (3) the wider society, as in the last resort water has to be administered for the benefit of all, and a straightforward manner of achieving this goal is to put every relevant element under the scrutiny of the citizens, fostering people empowerment.This also addresses the requirements at national and European levels expressed in the Aarhus (1998) convention on environment.On a global scale the UN now consider water security as a priority for the coming years (UN-Water, 2013;Young et al., 2015).
In our view the convergence of technical, legal, and ethical contexts is a plea towards the development and sharing of data and tools in the geospatial domain.This is supported by: (1) the will at the level of European Union (EU) level to ensure the availability and accessibility of public data (EU Directive INSPIRE, 2007) by publishing data and providing the corresponding metadata, i.e. every piece of information that is relevant to the data, and possibly information to retrieve or access the data itself; (2) the development of Open Data and the set-up of local, national and global (DC, 2013) public services for data, amongst which are geospatial ones; (3) the will of key actors of geospatial information and software (including academics, private companies and developers, public administrations) to foster interoperability in systems and streams, which materialised in the Open Geospatial Consortium (OGC, 1994).
A starting point was the need to disseminate the expertise and knowledge built up in our research unit (UMR SAS) for two decades in the field of hydrological modelling which materialised in tools that are broadly used at the national and local scales by watershed and catchment managers.However, these tools remain insufficiently reachable and/or lack transparency/ease of use.In the present paper we put ourselves in the perspective of expanding the capabilities of our geOrchestra-based SDI GéoSAS with functions aimed at assisting water resource management.Our illustration focuses on topographic delineation of watersheds.
We strongly support the idea that in order to ensure a maximal use/re-use/dissemination of systems, data, models and tools, a number of conditions must be fulfilled: (1) openness (FOSS SDI, open and public data, provide FOSS analysis tools and models), ( 2) interoperability (compliance to OGC standards, inclusive and participatory developing process), (3) modularity (conceive the overall architecture as a bespoke structure made of substitutable software building blocks), (4) evolution-ability (easy integration of innovations and upgrades, e.g.processing services to publish tools, methods and models).
The next section works through the technological options retained for our project, followed by a section which introduces and details our approach, focusing on the Watershed WPS (WS WPS) and associated add-on, and demonstrate them in interaction with the other OGC Web Services (OWS) used.Finally, we draw a conclusion and open perspectives.

TECHNOLOGY
The overall approach builds upon the OCG-compliant data architecture geOrchestra and implements extra specific code based on MNTSurf, an in-house DTM analysis piece of software.geOrchestra geOrchestra ( 2009) is a Free Open-Source Software (FOSS) Spatial Data Architecture (SDA) which is a consistent bundle of geospatial software amongst which: GeoNetwork (catalogue), GeoServer (cartographic and mapping server), mapfishapp (a viewer implemented with OpenLayers, GeoExt, ExtJS).We instantiated this SDA as Spatial Data Infrastructure (SDI) GéoSAS (2009).

Web Processing Service
The WPS standard (OGC WPS, 2007) defines inputs/outputs (i/o) and interactions between client-and server-side pertaining to processes (including models) on geospatal data.Input data can be local to the server or distant (on the client side), make use of image formats (e.g.GeoTIFF) as well as data exchange formats (Zipped SHAPE, GML, etc.).A process may have any degree of complexity.The WPS standard is designed to make processing services interoperable, hence enabling the effective interaction of such services as well as their reusability (and of course, re-usability of associated code).A WPS service must be able to execute three types of operations (on the server side) as a result of a client's request: (1) GetCapabilities requests are for the client to retrieve the service metadata (Service metadata describe the capabilities of the WPS server queried: name and description of each WPS hosted on the server, version of the standard used for client-server interaction); (2) DescribeProcess requests return detailed information on how the services function (expected input type, possible outputs, available formats); (3) Execute actually triggers the process, using the parameters selected through the client, and sends back the process result.

MNTSurf
The services detailed further rely on MNTSurf (Squividant, 1994) a piece of software developped at the SAS department and dedicated to Digital Terrain Models (DTMs) in connection with hydrological modelling.It offers a method for DTM correction using a vector hydrology layer on the one hand, and a mechanism to remove flow anomalies based on a graph structure (drain tree) on the other hand (Aurousseau and Squividant, 1997).MNTSurf implements a representation of surface water flows by means of a uni-directional as well as multi-directional drain model (Aurousseau and Squividant, 1996).
Amongst other functions MNTSurf was designed to: (1) calculate catchment extents and delineate watersheds upstream of any selected location.This location is therefore the outlet of the aforementioned catchment, i.e. all surface flow within the watershed eventually flows through the location; (2) compute hydrographic networks as tree graphs; (3) locate hydrological stations in the vicinity of any part of the hydrographic network.

MNTSURF INSIDE GEORCHESTRA WITH WPS
The novelty of the proposed tool relies on the implementation of the OGC WPS-compliant service to the geOrchestra suite.A WPS is to be proposed to each function of MNTSurf.The operation of the WS WPS presented further in this paper may be generalised to all of MNTSurf's functions.The result is a simplified access to automated watershed delineation (by clicking in a browser UI).The actual WPS (ensuring interoperable i/o) is triggered by an add-on integrated to the SDI.

Parameters
The WS WPS can be tuned through the Hydrology / Watershed / Parameters menu available on the toolbar of geOrchestra's viewer.One can thus select: the DTM/DEM to be used as input, the minimal areal extent of the watersheds to be calculated, the smoothing mode for the resulting watershed's outline, and toggle automatic zoom on the result.

Execution
The WS WPS is triggered using menu Hydrology / Watershed.It can manage four alternative types of inputs namely: (a) a mouse click on a location of the map, hence sending point coordinates (x,y); (b) a list of point coordinates in a GML file imported to the viewer by the user; (c) a reference to a whole OWS Web Map Service (WMS) point-layer (then the actual data flow directly between the OWS cartographic server and the WPS server); (d) an object (outlets, therefore of the point type) selection from a WMS layer cast by a third party OWS server.A variant (e) consists of passing the reference to the selection instead of the selection itself in addition to the reference to the WMS layer.

Output and result
Once calculated the layer processed by the WS WPS is sent to a thirdparty cartographic OWS server and added as a WMS layer to the list of visible layers in the viewer.This layer therefore benefits from all the OGC functionalities implemented on the viewer (the Web client) including: display (WMS), download in ESRI SHAPE format thanks to Web Feature Service (WFS), spatial and attribute requests (WMS, WFS), styling (Styled Layer Descriptor, SLD), context (Web Map Context, WMC), etc.
Figure 1 shows the flow sequence between the SDI modules from the execution of add-on WS WPS depending on the chosen option (pertaining to the type of input): mouse click (Fig. 1   example only the reference or description of the selection goes through).Table 1 complements Fig. 1 as a comparative list of data flow chronology for each option.
Figure 2 illustrates the use of add-on WS and the WS WPS in geOrchestra's mapfishapp UI as it is accessed on the GéoSAS website (WS-WPS, 2013).A number of data layers are loaded and displayed in the viewer, as OpenStreetMap base map, hydrology stations in Brittany, France.Some more base maps are loaded though they are not displayed (unchecked in the table of content): IGN (French geodetic survey institute) map scan and composite multi-resolution orthophoto.All these base maps are available as OWS on GéoBretagne's cartographic server, whereas hydrological stations are retrieved (as OWS) from GéoSAS.A selection from the latter data layer is made, and the selected objects appear, on the list below the maps (with associated attributes) and underlined on the map itself.In our example the selection is that of all stations referenced as catchment outlets of more than 500 hectares in area (field bv at the right hand in the attribute table).Add-on WS is then selected from menu tools (or toolbar), with the Catchment calculation from WMS cover option, which initiates the WPS request.The output, i.e. the watersheds which delineate catchments whose outlets are the aforementioned selected stations, is then appended to the map canvas and table of content as an OWS layer (in shades of blue on the map) and item named bv_date_time, respectively.

CONCLUSION AND PERSPECTIVES
We demonstrate the dynamic (real-time) use of a hydrological analysis function in a web browser achieved by extensively resorting to OGC standards, exclusively relying on FOSS, and taking advantage of the Open Data movement and European directive INSPIRE.This operational set-up together with the OGC standards (for interoperability), and the software architecture retained (for its modularity) allows a straightforward transposition other analysis tools and functions following the same principle, i.e. a concurrent use of distant data available on an OGC-compliant cartographic server, and analysis or modelling processes available on an OGC-compliant process server, to perform a spatial computation (which benefits from server resources) whose outcome may then be stored on a third-party OGC-compliant cartographic server and subsequently visualised (real-time) in the client web browser.We thus prove spatial analysis can be seamlessly done on delocalised data using delocalised processes.
Following the same principles we are now working on making available an increasing number of MNTSurf functions as WPS, and facilitating access and use by associating geOrchestra add-ons to each of these (in addition, every client implementing WPS, e.g.Quantum GIS through its WPS plugin, can use MNTSurf's functions irrespective of the use of geOrchestra and its add-ons).An objective is to offer the users WPS tools linking modelling and real-time on-field measurements (e.g.Macro Flux, Vinson, 2003).
A number of add-ons to geOrchestra that we have developed are already available (e.g.Vidae, 2009Vidae, , 2013)), and are being retuned as WPS.Vidae is dedicated to mining the data collected as ongoing time-series by a number of environmental sensors disseminated on several experimental sites.The data collected include stream-and ground-water physical and chemical properties and composition; the sites are located in Brittany, France (two sites) and around the Mediterranean basin (one in France and one in Tunisia).
Moreover, we do not restrict ourselves to the field of hydrology when it comes to developping WPS, as we have also produced a soil-database query tool as a WPS for projects Websol (Chafchafi and Bargeot, 2013) and Soils of Brittany (SdB, 2013).
Other ongoing projects aim at increasing the number and variety of available WPS: putting GRASS's functions as WPS (52north.org),and a similar trend exists involving ArcGIS.The perspective of having all the processes and models available will likely increase and transform practices in geomatics, and unify the different communities (which are largely based on software).The use of WPS transcends local (client-side) software as long as it includes a WPS client.We can even do completely without a desktop GIS, as we demonstrate a Web browser can do as long as at the server's end the architecture takes full advantage of OGC standards.
Figure1shows the flow sequence between the SDI modules from the execution of add-on WS WPS depending on the chosen option (pertaining to the type of input): mouse click (Fig.1(a)), GML file (Fig. 1(b)), reference to an OWS layer (Fig. 1(c)), selection within an OWS layer (Fig. 1(d) and (e): in the first case the selection is sent through the Web whereas in the second Fig. 1a Fig. 1b Fig. 1c Flow succession from: 1a. a mouse click 1b. a GML spatial layer of points 1c. a reference to a whole OGC point layer 1d. a user-selected objects from an OGC point layer 1e. a reference to a OGC point layer plus the reference of a selection on this layer

Fig. 1 Table 1
Fig. 1 Flows and transactions between the client and servers depending on the WS add-on's input type.Table 1 Comparison of the different flows streaming between the client and servers depending on add-on WS's input.Numbers on the first line (type of flow) refer to Fig. 1(a)-(e).Type of flow 1a 1b 1c 1d 1e Coordinates (x,y) are sent as a result of a mouse click in the viewer. 1 Incoming flow as a GML point file towards the viewer. 1 WMS flow from the OWS cartographic server to the viewer (client) 1 1 1 WFS flow from the OWS cartographic server to the viewer (client) as a result of a selection 2 The viewer sends the GML file's reference to add-on WS 2 2 3 Transmission of the WMS's reference 2 Sending of the WMS's and Openlayer.Filter filter's references which translates the "select from" request 2 WPS flow triggered by the WS add-on towards the WPS server 3 3 3 4 3 WFS flow from the OWS cartographic server to WPS server 4 WFS flow from the OWS cartographic server to the WPS server.Additionally the selection is conveyed by CQL filter 4 API REST deposits the process's outcome to third party OWS cartographic server 4 4 5 5 5 Output WPS flow (from WPS server to add-on WS) 5 5 6 6 6 Add-on WS sends the outcome's reference (WMS's address) to the viewer 6 6 7 7 7 Client's request (the viewer) and third party server's reply to send back the outcome (several OWS involved: WMS, WFS, SLD, WMC) 7 7 8 8 8

Fig. 2
Fig. 2 Add-on WS and the outcome of WS WPS in geOrchestra's viewer.