Towards a Spatial Data Infrastructure and an Integrated Management of Groundwater Resources

International studies of expertise have shown that the difficulty of data access is one of the major hindrances that brakes any effort to conduct studies on groundwater. This research paper is an attempt to address this problematic through developing a technical framework to implement a Spatial Data Infrastructure (SDI) with a view to improving the status of access to data related to groundwater in Morocco, and achieving their interoperability. This prototype is primarily based on international standards (OGC & ISO) such as Web Map Service (WMS), Web Feature Service (WFS), Catalog Web Service (CSW) and Sensor Observation Service (SOS) accompanied by the use of associated specifications such as Geography Markup Language (GML) and Filter Encoding (FE). This platform is considered both as a tool for sharing updated data collected from numerous and divers source providers, and as a tool of web-based GIS for groundwater management, which constitutes the basis for decision making.


Introduction
Spatial data play an important role in many social, environmental, economic and political decisions and are increasingly acknowledged as a national resource essential for sustainable development [1]- [4].
Recent national and European investigations such as GDI-DE (German National Spatial Data Infrastructure) [5] [6], GEOSS (Global Earth Observation System of Systems) [7] and INSPIRE (Infrastructure for Spatial Information in Europe, http://inspire.jrc.it)[8] [9] have shown that the implementation of Spatial Data Infrastructures (SDI) constitutes a very efficient tool in developed countries.The goal of INSPIRE Directive is to harmonise spatial information across Europe and to improve geospatial data services according to common principles [10].
Morocco is one of the South Mediterranean border countries which are integrated into the Barcelona process [11].Developments in these countries also affect the European Union both directly and indirectly.Therefore, the choice of this region reflects clearly the consideration of the European Barcelona Process, which intends to tie the border countries closer to European Economy.
Within the groundwater sector of Morocco we see that there is a great demand for the use of and access to spatial information [12] [13].But we encounter several problems that are related to the lack of metadata, standards are not supported, data are not regularly updated, naming conventions that are used in different datasets, the use of different coordinate system and a low level of coordination.This means that groundwater data need to be shared and to be made interoperable in order to give users and stakeholders the opportunity to turn data into useable and understandable information [14].
To address this need, we decided to develop an innovative system, which brings a new approach to the monitoring, managing and publishing of spatial information.Otherwise, our system is designed to provide a powerful tool that enhances the ability of regional staff to monitor near real-time groundwater data and as a result will help provide a more effective response to environmental upsets [15].

Spatial Data Infrastructure SDI
A Spatial Data Infrastructure includes all the required access technologies, standards, systems and protocols to harmonize all Spatial databases aimed at increasing the availability and accessibility of geographic information [16] [17].[18] highlights that SDI's are implemented to collect and make fully available to the whole society more accurate spatial information able to improve the quality of citizens' lives.In this sense, SDI's allow for a smooth exchange and sharing of spatial data between different actors and, mainly, saving time in data creation and maintenance [19].
An SDI should be more than a mere data set or a database [8]; it is composed of spatial information, metadata, and tools to discover, visualize and assess it, with a view to accessing and harnessing information.In order to set up a system of interoperable components, these elements must observe certain norms and standards [20] [21].
To develop an SDI and make it operational, an institutional and organizational framework is also required to clearly define the actors, their roles and responsibilities, the legal foundation, and a financing and charging policy (Organizational aspects) [20].
To achieve these objectives, many countries allocated huge resources to the development of their own national spatial data infrastructure to manage and use in a cost-efficient way spatial data, minimize the production costs of data and avoid duplicated efforts in data acquisition [2] [3] [22].
In Morocco, there is a willingness to comply with international directives in geomatics through the digitalization of some links in cartographic production chain that falls within the mainstream of the national agency for real estate registry, cadastre and cartography (ANCFCC) [12].Nevertheless, these efforts are still at their embryonic stage.Mohammadi et al. in 2006 [23] showcase the importance of a two-stage process in developing national spatial data infrastructures.First, there is the technical phase (interoperability); the second is non technical (including the application of one-standard data model, the development of collaboration models, the implementation of an institutional framework) [24].Within this research, we are concerned primarily with the technical aspect of SDI's, the non technical side being mainly managed by managers and decision-makers in consultation with other actors and organizations.

Initiatives Worldwide
The research work which is the object of this research project requires the apprehension of various concepts linked, inter alia, to projects that were previously set up in areas of spatial data infrastructures.This part provides an overview of the literature produced with respect to various projects that were deemed of relevance to this research project.

Inspire
The European directive INSPIRE aims at establishing a spatial information infrastructure in the European community for the purposes of environment preservation.In the terms of the Directive, spatial information infrastructure designates an array of information services available online, provided on the web sites of different stakeholders, allowing for spatial data dissemination and sharing (Figure 1).In this respect, the Inspire directive aims essentially at allowing access to spatial data through a geo-portal [8] [25].
From a technical point of view, INSPIRE comprises various services (visualization, transformation, download, etc.) that can be used by GIS applications and geo-portals via INSPIRE service bus.

Ewater
Having been developed as part of implementing the European directive on water, ewater represents an SDI designed for the management of hydrogeological data in Europe.Its major purpose (http://www.ewater.eu) is to improve and increase accessibility and use of specialized data regarding groundwater quality, location and use.This project will allow for an easier exchange of data among national and regional agencies in charge of water resource management, and for addressing issues related to crossborder water management.
On the other hand, ewater aims at strengthening partnership between the providers of hydrogeological data through a harmonization of spatialized hydrogeological information metadata and online access to data and service.

Groundwater Information Network (RIES)
RIES is a Canadian SDI designed for groundwater management.It allows the increase of knowledge on groundwater systems and a better management through access to standardized information.RIES utilizes SDI standards and technologies to provide transparent access to generalized heterogenous data.Its highly developed geo-portal (www.gw-info.net)enables to visualize and analyse data with a view to meeting scientific and commercial needs and water management requirements (Figure 2).RIES constitutes one of the pioneering SDI's in hydrogeology [26]- [29].

Remarks
In brief, and drawing on this literature overview, we noticed that the importance of SDI's induced most coun-  tries to integrate this system in their development approach, where SDI's are a key driver in scientific research, in supporting decision making in the area of groundwater development and management, and in involving the different stakeholders in the decision-making process.The existence of an infrastructure that provides services of georeferenced data discovery and sharing has become necessary so that all stakeholders can test, validate and communicate their hypotheses.
Our research project fits into this perspective, and is intended to have a share in drawing up SDI concepts for a better groundwater management.Nevertheless, it is incumbent upon us to ensure that the would-be implemented infrastructure responds to national requirements in terms of groundwater management, and that it favors the involvement of decision makers, researchers and academicians to bring forth a better dialogue.

Architecture of a Groundwater SDI in Morocco
Cuthbert in 1998 [30] suggests a model for spatial data publication composed of four processing units and four representation components (Figure 3): • The data selection process is managed by OGC/ISO Filter Encoding specification [31], • Access to vector data is performed through SQL query language, provided by the implementation of the Simple Feature Specification [32], or its equivalent Web Feature Service WFS. • Representation of features and feature collections is performed based on GML standards (Geography Markup Language), • The display generator applies Style Layor Descriptor (SLD) rules on geographic entities and produces graphic representations as images (PNG, TIFF, JPEG, etc.)) [33], • The implementation of a Web Map Service (WMS) enables to define an interface to access the map, which represents the result of both processes: Display and Render, • The result thus obtained is delivered to the user through a web client.
Based on Cuthbert model, an interoperable n-tier architecture-based platform was developed.The general idea behind this platform is to use the concept of web services to allow access to hydrogeological data.
As far as the server is concerned, the engine of our system is an Apache Tomcat application server developed in Java.It is a servlet container where are deployed other components of this tier.This container also comprises a web server that enables to receive requests and send responses to clients following several protocols, including HTTP, used in online exchanges [34].
The major component of our spatial server is based on the degree framework.The core of degree is a comprehensive Java Application Programming Interface (API) offering access to spatial features, analysis, metadata and coordinate reference systems [35] [36].It comprises the required services for an SDI (Deegree Web Service) and for the geo-portal components [37].It provides a mechanism for managing security and access control problems (Deegree iGeo Security) and storage [38].It is based on OGC/ISO 19115/19119 standards.It has been used as a key support in implementing several Web Services (Figure 4):

Web Mapping Service (WMS):
WMS specification describes an interface on which georeferenced maps can be made available [39].Data are visualized as images (gif, png, jpeg, svg).The service is composed of three workflows to send requests to the server and retrieve data: Get Capabilities returns service-level metadata which is a description of the service's information content and acceptable request parameters • Get Map returns a map image whose geospatial and dimensional parameters are well defined • Get Feature Info: returns information about particular features shown on a map.
Web Feature Service (WFS): WFS is able to serve vector and attribute data from different data sources (backends) and deliver it to any client that is able to perform WFS compliant HTTP-GET or POST requests [40] through the interfaces [41]: Get Capabilities: A web feature service must be able to describe its capabilities.Specifically, it must indicate which feature types it can service and what operations are supported on each feature type.
Describe Feature Type A web feature service must be able, upon request, to describe the structure of any feature type it can service.
Get Feature A web feature service must be able to service a request to retrieve feature instances.In addition, the client should be able to specify which feature properties to fetch and should be able to constrain the query spatially and non-spatially.
Web Coverage Service (WCS): WCS supports electronic retrieval of geospatial data as "coverages" -that is, digital geospatial information representing space-varying phenomena [42].
It provides three operations [42] [43]: Get Capabilities: returns an XML document describing the service and brief descriptions of the coverages that clients may request.
Describe Coverage: lets clients request a full description of one or more coverages served by a particular WCS server.The server responds with an XML document that fully describes the identified coverages.
Get Coverage returns a coverage, encoded in a well-known coverage format Catalog Services for the Web (CSW): CSW provides the possibility to list and to search services or data sets based on metadata files published for each resource to enable their discovery.This service also provides the use of a transactional interface for data updates [44].It supports the operations [42]: Get Capabilities: returns an XML document describing the service and brief descriptions of the metadata including Service Identification, Service Provider, Operations Metadata, and Contents that clients may request [45].
The 'get Records' operation is particularly important.It returns metadata records according to specified conditions in a request.
Get Record By ID: is KVP encoded and requested via HTTP GET method.It returns a record (records) according to specified id (ids).The same possibility exists to request a full, summary, or brief record from the catalogue [46].

Sensor Observation Service (SOS):
The Sensor Observation Service (SOS) provides a standardized interface for managing and retrieving metadata and observations from heterogeneous sensor systems [47].It defines three obligatory interfaces: Get Capabilities describes the capabilities of the service and provides metadata about the service instance.Describe Sensor returns a sensor description which is encoded using the Sensor Model Language.Get Observation: returns the actual values of a sensor.Those values are encoded using the Observations & Measurements.
They are normally linked to other specifications [48]: • Simple Features (enabling the clients to access geographic objects through adapted queries) [49].
• Coordinate Transformation Services (enabling to overlay information issued by different coordinate systems) [50], • Geography Markup Language (enabling the transmission of geometric and semantic information to the client, consequently extending just the image and spatial feature visualization).All these services are implemented as a servlet and runs on an Apache Tomcat servlet container.SOS, CSW and WFS web services connect to a Postgre SQL and Oracle Database called Badre 21 for storing and retrieving the vector and sensor metadata and measurement values.An external web client can connect to the SOS and use OGC-compliant XML-requests to fetch server and sensor metadata or measurements, as well as insert new sen-sors or observations into the web service [51].WMS and a CS-W are being installed as a base system allowing querying metadata, finding geodata and displaying it in an intra/internet.WMS, WFS, WCS and Gazetteer interact in controlling data access cooperatively.WMS and Gazetteer support use of the Catalog Service in providing mechanisms for spatial retrieval and/or using geographic names.The Catalog Service identifies relevant datasets of a query and stores information allowing access to the data over suitable Web Services (WMS, WCS, WFS) [52].

Geo-Portal
The implementation of an SDI usually invokes a geo-portal, which is used as a single window to gain access to infrastructure, providing the functions of data discovery, visualization and access [53].Within this work, a geo-portal was set up to serve as access interface.This geo-portal is designed to be the most comprehensive possible access point to search for the major geographic and alphanumeric data on groundwater resources (Figure 5).

Data Access and Visualization
Cartography areas enable us to visualize spatial data: we can select an area of interest, a scale and the suggested topic that the user needs to represent on a map (such as sub-watersheds, water points, aquifers...).
Besides the standard functions of zooming in and out, panning and request, it is possible to search, select and browse towards geographic entities (boreholes, hydrographic network, watersheds...).
It is possible to generate, store and use OGC Web Map Context documents to obtain a defined status of the Web-based interface.
Each thematic map comprises browsing, panning and printing tools, etc. as well as specific spatial data displayed according to threshold scales and with predefined features (Gazetteer, color, size, format…).
Drawing on database management systems technologies, the geo-portal offers the possibility of accessing data on boreholes as description sheets and stratigraphic logs.It also allows to generate interactive maps following the user's needs.

Geocatalog
The geo-portal provides a catalog covering all georeferenced data via a search engine that enables identification and sorting out of data to be visualized.Metadata are structured in conformity with ISO 19115 and ISO 19139 standards for metadata structuring and encoding.
This geocatalog uses CSW requests to query the server and to repatriate the required data based on metadata previously entered through the Editor module of the open source deegree-CSW application.The view module enables to perform searching just by keywords or to include other searching criteria such as geographic area, date of required data creation/modification.
With a view to reaching a solution that includes a geo-portal and a catalog, we set up the required configuration to enable the CSW-client module that is entegrated in the geo-portal.The result is shown in Figure 3, which illustrates how a search is made on the geo-portal to query the Deegree-CSW server about water data, for instance: view of metadata of a layer that is published on the WMS server on dams in this area.

Geosensors
The geosensor module enables the user to retrieve data issued by in situ sensors via the Sensor Observation Service (SOS) standard, which is a generic OGC standard linked to surveillance sensors and information [51].Each measurement station transfers data to the central server, so that, subsequently, the data import tool, SOS-Import, can integrate them into the Postgre SQL/Post GIS database that communicates with the 52˚ North SOS server [51] [54]- [56].This service is used here in the real-time monitoring of the piezometric level.This technology can be used to perform a multitude of on-site measurements, inter alia, of groundwater quality.SOS improves visualization both by allowing direct access to data and by inserting information on stations, such as the person responsible for their maintenance and data collected by sensors.

Conclusions
Groundwater is a vital resource for sustaining socio-economic and ecological systems, especially at times of surface water scarcity [57].In morocco, groundwater data need to be shared and to be made interoperable.In this context, a prototype of SDI has been developed for efficient management of groundwater data using OGC standards and open source technologies.It provides a platform for collecting, storing, and sharing monitoring groundwater data.The developed platform constitutes the linchpin of an ambitious project aiming at the design of a Spatial Data infrastructure SDI in Morocco dedicated to groundwater management.This application is primarily based on international standards (OGC and ISO).Data issue is from different databases (Postgre SQL, Badre 21, etc.).The application is connected to those data sources either by JDBC technology, or via WMS/ WFS.All document formats used are XML applications, in accordance with OGC standards (Get Capabilities, Get Map, etc.) as well as the W3C standards.
This platform is viewed both as a sharing and generalization tool of updated data derived from different data sources, and second as a tool of web-based water resource management that generates the indicators used in decision making.
Despite all these efforts, the data geocatalog suffers from some gaps in terms of data semantics management.Our future research will try to address the issue of semantic heterogeneity using domain ontology.

Figure 5 .
Figure 5. Geoportal for groundwater data management in morocco.