A Spatial Data Infrastructure for the Global Mercury Observation System

The Global Mercury Observation System (GMOS) Project includes a specific Work Package aimed at developing tools (i.e. databases, catalogs, services) to collect GMOS datasets, harvest mercury databases, and offer services like search, view, and download spatial datasets from the GMOS portal (www.gmos.eu). The system will be developed under the framework of the Infrastructure for Spatial Information in the European Community (INSPIRE) Directive and the Directive 2003/4/EC on public access to environmental information, which both aim to make relevant, harmonized, high-quality geographic information available to support the formulation, implementation, monitoring, and evaluation of policies and activities that have a direct or indirect impact on the environment. Three databases have been proposed (on emissions, field data and model results), and each will be equipped with state-of-the-art, open-source software to allow for the highest performance possible. Web-based user-interfaces and prototype applications will be developed to demonstrate the potential of blending different datasets from different servers for environmental assessment studies. Several services (i.e. catalog browsers, WMS and WCS services, web GIS services) will be developed to facilitate data integration, data re-use, and data exchange within and beyond the GMOS project. Different types of measurement and model datasets provided by project partners and other sources will be integrated into PostgreSQL-PostGIS, harmonized by creating INSPIRE-compliant metadata and made available to a larger community of stakeholders, policy makers, scientists, and NGOs (as well as to other public and private institutions, as dictated by the Directive 2003/4/EC). Since interoperability is a central concept for the Global Earth Observation System of Systems (GEOSS), the Global Monitoring for Environmental and Security (GMES) and the INSPIRE Directive, guidelines developed in these three frameworks will be adopted. The use of standards will be a key concern throughout the encoding process. We will use the international standards for data and spatial schemas (ISO19107, ISO14825), for metadata (ISO19115:2003, ISO/DTS19139:2005, ISO15836) and for services (WMS 1.1.1, WFS 1.0, SLD 1.0, GML 3.1). On the other side, we will use XML for data exchange, together with SOAP, XSD, J2EE (for applications development) and W3C (for standard interfaces). With specific reference to GMES, the global database on mercury monitoring and the GMOS model outputs will be made available through a series of monitoring, forecast and re-analysis services. Finally, we hope the GMOS operational services will contribute to the Monitoring Atmospheric Composition and Climate (MACC) project, by providing access to atmospheric environmental services.


Introduction
The Global Mercury Observation System (GMOS) Project includes a specific Work Package aimed at developing tools (i.e.databases, catalogs, services) to collect GMOS datasets, harvest mercury databases, and to offer services like search, view, and download spatial datasets from the GMOS portal (www.gmos.eu).
The aim is to make relevant, harmonised and high quality geographic information availableto support formulation, implementation, monitoring, and evaluation of policies and activities thathave a direct or indirect impact on the environment.An e-infrastructure will store databases and tools to release web services and web applications in an effort to facilitate data integration, data re-use, and data exchange within and beyond the GMOS

(2013)
This is an Open Access article distributed under the terms of the Creative Commons Attribution License 2 0 , which .permits unrestricted use, distributi and reproduction in any medium, provided the original work is properly cited.on, 1 project.Different types of measurement datasets and model datasets that are provided by the GMOS project's partners (and from other sources) will then be harmonized, integrated intothe cyber-infrastructure, and catalogued, by creating compliant metadata standards, which will then be made available to a larger community of stakeholders, policymakers, scientists, NGOs,and other public and private institutions (as dictated by the Directive 2003/4/EC).

Architecture
With the above in mind, we developed a Spatial Data Infrastructure (SDI) architecture, as the cornerstone of an integrated architecture, where any component can be plugged in.Services and processes provided by the SDI are controlled through an Information Infrastructure that includes the most useful processes of the proposed SDI, in order to provide high-level services (e.g.data integration) to final users.This Information Infrastructure acts as a middleware between users and the SDI,giving a more user-friendly facade to the face of the SDI.
Hereafter, the SDI Architecture will be describedby using the terminology of the Reference Model of Open Distributed Processing (RM-ODP) (ITU-T Rec.X.901-X.904| ISO/IEC 10746) [16]- [28].RM-ODP is a model used to describe complex ICT systems.
The following RM-ODP viewpoints have been considered: Engineering The enterprise viewpoint focuses on the purpose, scope, and policies of a system.It provides the context and the overall environment within which the system will be built, and therefore indicates constraints and obligations that must be applied to all other viewpoints.Therefore, the enterprise viewpoint represents the global requirements that the SDI must respect.For example, from the perspective of an end-user, an SDI should both organize information/resources and distribute them by providing services via a single access point, often online.
The information viewpoint is focused on information semantics and the information processing that is performed.It describes the information managed by the system and the structure and type of content of the supporting data.It then describes the system in terms of the data managed.For example, description of data stored is fundamental as storing and organizing data requires it to be contextualized in order to give information on any collection methodology, lineage, spatial and temporal domain, copyright, context of use, etc.Such documentation is called metadata.
The computational viewpoint enables distribution through functional system decomposition into objects that interact through an interface.It describes the architecture of an SDI by means of its components.
Finally, the engineering viewpoint focuses on the interactions that occur between the distributed components of the system.

Implementation
We adopted open source components to build the GMOS SDI.
We selectedPostGis, Geoserver and Geonetwork for the storage of geographic data, the export of geographic web services, and the management of metadata, respectively; whereas some Javascript libraries embedded in OpenLayers can be used to display geographic information.This approach enabled the construction of the SDI as a pluggable system.This scenario will requireadditional effort to solve the challenges that arise in the integration process, in the interactions between the different components.Information Infrastructure can play an important role in this regard, by exporting a uniform and unique interface for the components involved in the SDI.
The architecture of the GMOS SDI is aimed at providing geographic services for integration into a Service Oriented Architecture (SOA), like GEOSS.SOA is now increasingly being used in developing the environmental sector.
The SDI Architecture consists of three different logic levels, namely the Data Storage Layer (DSL), the Business Logic Layer (BLL) and the Application Layer (AL) (Figure 1) (D'Amore et al., 2011;D'Amore et al., 2012).
The core of the system is represented by the Database Management System (DBMS), which holds vector geospatial information and functional data.The DBMS represents the DSL in the SDI architecture, which stores metadata and geographic data in separate databases to maintain a different logic structure for each type of data.It is accessed by BLL components or can be accessed in a secure way.Additional databases are dedicated to functional tasks by applications that perform data integration or system management.
To date, raster data are stored in the File System and handled directly by the map server.This approach is due to constraints imposed by the open-source geodatabase (i.e.Postgis), which cannot directly handle raster information.In the near future, they will be managed by Data Access Objects (DAOs), which are objects that provide an abstract interface to access databases, used in Software Engineering to decouple storage systems from software layers (D'Amore et al., 2011).
All server components that perform metadata editing, data management, map creation and data dissemination are in the BLL.Among them, the map server is used toexport data through OGC compliant services and the metadata server to manage metadata and the related catalog.Server components export OGC Web Services (OWS) such as Web Feature, Web Map, Web Coverage and Web Catalogue Services, through the Hypertext Transfer Protocol.The main open-source components that perform the requested tasks include : • Geoserver (Geoserver, 2012), a map server that exports OWS (Open Geospatial Consortium Web Services).These services can be used directly by end-users in complex service-oriented architecture (SOA) systems or geo-portals built with Web technologies.OGC services are also used by the following tools to integrate metadata with maps and other geographic data; • Geonetwork (Geonetwork, 2012), a tool used to manage metadata.Metadata are exported via the CS-W 2.0.2 protocol, which is the basis for integrating the SDI into complex systems.This tool allows links with Geographical Services such as WMS and correlation with different, evenunstructured, data sources; • EARTh (Plini et al., 2009;EARTh, 2012), the Thesaurus linked to Geonetwork to support the metadata editing process; • Gi-cat (Nativi et al., 2009;Gi-cat, 2012) is a Service Broker used as collector for Geographic Web Services.It supports several protocols (including WMS, WFS, THREDDS, CS-W), accepts a wide variety of inputs, and extracts information and exports it in a standardized protocol as CS-W.It is linked directly within Geonetwork to export metadata and to integrate the SDI into more complex Systems of Systems, like those constructed within GEOSS.

Conclusion
We developed the GMOS SDIusing advanced interoperable tools in an effort to construct a fully-integrated framework.These tools are compliant with existing standards, and are designed for GEOSS integration.This interoperable system can be helpful in assuring real-time data analysis and dissemination within the scientific community, as well as in offering the information to policymakers and other stakeholders.The GMOS SDI holds information on mercury concentrations measured at permanent sites, as well as information collected in monitoring campaigns.It will also incorporatemodel outputs and meteorological parameters.The tools developed can support both modelling activities and environmental assessments aimedat evaluating the impacts of mercury pollution on terrestrial and aquatic ecosystems, as well as on human health.

Fig. 1 .
Fig. 1.The SDI architecture with the Data Storage Layer (left), the Business Logic Layer (centre left) and the Application Layer (right).