GeoE3 Service Architecture

  • Share on Pinterest

Geospatially Enabled Ecosystem for Europe, GeoE3, is a project co-financed by the Connecting Europe Facility of the European Union that will provide the vital connection between existing and emerging National, Regional and Cross-Border digital services. The action provides dynamic integration of high-value data sets and services (e.g., meteorological or statistical data) with geospatial features from existing national geospatial data platforms (e.g., building data or road network data). This simplifies meaningful analysis and visualisation in a national and cross-border context.

The GeoE3 service architecture, presented in Figure 1, is a modular structure relying on the ‘OGC API’ family of services. The architecture is built with four types of clients in mind: Web applications, Intelligence traffic (C-ITS), Desktop application (QGIS-plugin), and Data and service quality dashboard.

Three types of data services are employed: OGC API – Features, OGC API – Coverages, and OGC API – Environmental Data Retrieval. The data are always provided from OGC API services, each one giving access to one dataset. In addition, OGC API – Processes yields on-demand analyses based on the data services. The data services retrieve data from databases and/or file storages, and in some exceptional cases, from legacy services.

While data is provided from numerous distributed services, the client is equipped with a single point of access, provided by a separate European cross-border implementation and a context broker. The cross-border implementation is more than a proxy. Consider for example a Digital Elevation Model (DEM) provided by National Land Survey agencies in each country. If the client requests DEM data covering the Nordics, the cross-border implementation needs to fetch the data from several different data services (one per country) and combine the result. On the other hand, weather forecast data comprises several models covering different parameters and geospatial and temporal coverage. Often, these models are provided from various data centers and services, which clients are unaware of. The cross-border implementation needs then to resolve which model and service are the best for the requested parameter, time, and location combination.

Where applicable, the services should support a change-only data provision based on, for example, INSPIRE lifespan tags. However, such functionality is not reasonable, for instance, with constantly updating meteorological data. In the case of non-open data, the authentication is done with a separate APIKEY authenticator. The requests are authenticated both in European cross-border implementation and in data services.

Metadata is provided from the European Data Portal catalog service and the OGC API Records service. In addition, numerous supporting services such as eTranslation, Automatic data quality validation, and Service QoS monitoring are used to ensure fluent development and user experience.