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. 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 mean environmental data, chemical or physical information about terrestial or oceanic areas. Data can be yet present in the d4Science Infrastructure ore 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 compiant documents. These include WPS, WCS, WMS and WFS.
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 geospatial analysis on some data or want to retrieve environmental characteristics.
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 datasource for retrieving physical and chemical earth features;
- Thredds Connector: a connector to the 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 data;
- 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 in multiple hosts and on multiple scopes, this does not guarantee a performance improvement because these are associated to the requests which are made towards external sources. There are no temporal constraints on the co-deployment of services and plugins. Every plugin 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 contain geo-spatial information. It is suitable when the production of standard OGC format documents is needed. The development of any plugin for the Environmental Service immediately extends the ability of the systems to interact with other kinds of geospatial datasources.
