Skip to main content

Getting coverage

By GeoConnexion - 28th June 2013 - 09:04

The OGC is working on ways to deal with the world’s big data challenges, writes Peter Baumann

Sensor data, images, simulation models, statistics data – all these data sources contribute massively to the world’s big data challenges. In 2010, the OGC web coverage service (WCS) standards working group (SWG) established a modular, scalable data and service model for big geo coverages data. Building on the well-established core service model of the WCS standard, the WCS SWG is now working on additional service extensions including time-handling, RESTful interfaces, and integrated data/metadata search. Since the OGC coverages domain working group and temporal domain working group have made their listservs open to the public, anyone can follow discussions in these OGC groups. To subscribe, visit http://lists.opengeospatial.org/mailman/listinfo.

A common abstraction for big data in the geospatial domains is a ‘coverage’ – loosely defined as the digital representation of a phenomenon varying in space and time (see Figure 1). Examples include 1D sensor time-series, 2D satellite imagery, 3D x/y/t image timeseries and x/y/z geology models, and 4D x/y/z/t climate simulation output. Beyond the ‘classical’ regular grids, we find irregular grids, point clouds, triangulated irregular network (TINs) and general meshes.

In ISO 19123, which is identical to OGC abstract topic six, a high-level abstract definition of the term coverage is given. This abstract definition does not lead to interoperable implementations – in fact, many divergent implementations are possible and do indeed exist.

Interoperability is achieved through implementations of the OGC GML 3.2.1 application schema – coverages standard, nicknamed GMLCOV [cov]. This standard establishes data structure and conformance testing down to the pixel level while retaining freedom to encode data in GML, GeoTIFF, NetCDF, or any other suitable format, be it lossless or lossy. Coverages may be embedded into higher-level structures, such as observations modelled by the OGC observations and measurements (O&M) encoding standard. In addition, coverages can carry optional application metadata.

Serving coverages

For serving out coverages, the OGC web coverage service (WCS) interface standard specifies a modular suite of service interfaces consisting of mandatory core functionality (‘WCS core’) and a set of mix-and-match extensions. WCS core defines spatio-temporal sub-setting and format encoding. Among the extensions (see Figure 2) are band extraction, scaling, coordinate reference system (CRS) transformation, interpolation, server updating (‘WCS-Transactional’), and processing. The latter service extension, the OGC web coverage processing service (WCPS) language interface standard, establishes a high-level tool for ad-hoc filtering and processing of coverages, also known as ‘scalable R’.

Implementations can use any number of the extensions with the core while still retaining interoperability. To give guidance and optimally support specific application domains, the WCS SWG is establishing so-called application profiles (APs). The earth observation AP, EO-WCS, has been completed and has been voted upon already; work on the MetOcean-WCS AP has commenced.

Notably, the coverage data structure is independent of a particular service – on principle, coverages can be exchanged freely through implementations of WCS and WCPS as well as implementations of other OGC standards such as the OGC web processing service (WPS), sensor observation service (SOS), web map service (WMS) and other OGC interface standards (see Figure 2). This provides a platform for mash-ups and orchestration in which each service can be employed for its strengths, such as SOS for upstream sensor acquisition and WCS for downstream serving of coverages (see Figure 2).

Many dimensions

In the course of its work, the OGC WCS SWG has encountered a severe obstacle: today’s coordinate reference systems are not suitable for multi-dimensional, spatio-temporal data. Hence, an OGC name type specification for coordinate reference systems has been approved as an OGC best practice (BP). This BP defines how to treat horizontal, vertical, and temporal axes alike, and also supports dynamic combination of CRSs into new ones, such as WGS84 and ANSI time for image time series. The OGC CRS resolver is supported by an open-source tool that handles these CRS extensions. The new temporal DWG is focusing on issues of time handling, and, as mentioned above, the members of the working group have opened the listserv to the public.

In line with the recent wide-ranging discussion in the OGC on topics such as RESTful access and linked data, the WCS SWG has established a new candidate protocol binding for RESTful access, in addition to GET/KVP, POST, and SOAP. The goal of RESTful WCS is to provide the most compact access to coverages possible while retaining all spatio-temporal capabilities.

All WCS concepts are evaluated and tested on the WCS Core open source reference implementation, rasdaman, before going into adoption. This reference implementation also serves to demonstrate that the WCS standards suite indeed supports fast, scalable implementations. Other WCS implementations include MapServer, GeoServer, GMU, and OpenDAP.

In the course of its work, the OGC WCS SWG has encountered a severe obstacle: today’s coordinate reference systems are not suitable for multi-dimensional, spatio-temporal data.Peter Baumann of Jacobs University is chair, OGC web coverage service standards working group, OGC coverages domain working group and the OGC temporal domain working group.

Read More: GIS Terrestrial Mapping

Subscribe to our newsletter

Stay updated on the latest technology, innovation product arrivals and exciting offers to your inbox.

Newsletter