Environmental Service
A broker for searching among geo-referenced data sources, aiming to provide users and services with tools for retrieving information about environmental characteristics in a standard OGC format. This document outlines the design rationale, key features, and high-level architecture, as well as the options deployment.
Overview
The goal of this service is to offer a unique access for retrieving geo-spatial data which could contain environmental data, chemical or physical information about terrestrial or oceanic areas. Data can be yet present in the d4Science Infrastructure or they could be obtained by processing resident information. In some cases data have to be downloaded from external sources.
The Service is able to take requests coming from clients or services under many formats and answers by producing OGC compliant documents. These include WPS, WCS, WMS and WFS formats.
Connectors towards data providers are implemented as plug-ins which makes the injection mechanism of new functionalities easy to deploy.
Design
Philosophy
This represents a unique endpoint for those clients or services which want to perform geo-spatial analysis on some data or want to retrieve environmental characteristics about earth areas.
Further details are available at the Geo Spatial Facilities Section on the gCube wiki.
Architecture
The subsystem comprises the following components:
- MyOcean Connector: a connector to the MyOcean data source for retrieving physical and chemical earth features;
- Thredds Connector: a connector to a http://www.unidata.ucar.edu/software/thredds/current/tds/ THREDDS] server which retrieves stored geo-spatial information in OGC standard format;
- WPS Connector: a connector to a WPS Service (a 52 North implementation) which provides extraction functionalities from net-CDF files or environmental layers;
- Environmental Service: the Service Core which implements the orchestration logic.
A diagram of the relationships between these components is reported in the following figure:
Deployment
All the components of the service must be deployed together in a single node. This subsystem can be replicated on multiple hosts and scopes, this does not guarantee a performance improvement because this is associated to the requests which are made towards external sources. There are no temporal constraints on the co-deployment of services and plug-ins. Every plug-in must be deployed on every instance of the service.
The Service will automatically take the available sources by asking to the d4Science Information System for the scope it is running into.
Small deployment
The deployment follows the schema of the Architecture, as it implies the THREDDS, WPS and MyOcean Services are running in the same scope.
Use Cases
Well suited Use Cases
The subsystem is particularly suited to support abstraction over geo-spatial information retrieval both in cases of environmental data or time series or other formatted data which have geo-spatial information associated. It is suitable when the production of standard OGC format documents is needed. The development of any plug-in for the Environmental Service immediately extends the ability of the systems to interact with other kinds of geo-spatial data sources.
