WCS Wrapper About

Back to aq-ogc-services.sourceforge.net

About OpenGeoSpatial Web Services

The OGC Web Services like WCS, Web Coverage Service and WMS, Web Map Service, were designed to allow dynamic client-server interoperability between applications.

The most successful of them, WMS is widely used due to a crucial property: It's output is an image. All the web browsers can display images, people understand images. If it just was like that for everything! Unfortunately that is not the case.

The General Problem of data sharing

There are a lot of sites that have data available in numeric formats, binary or text. While the formats are human readable, it is impossible to write a generic reader that can read any data and properly convert it into the format that data processing applications actually use. Even if the data is in netcdf format, it's still lacking semantics.

A NetCDF array has syntactic properties like its dimensions and data type, but no semantic interpretation what they actually mean. Computing latitude, longitude and time to Ozone[457,34,98] is easy once you know how to compute it. You need a human to create a reading script for every kind of file format, which is a daunting task. The converter to the above binary files at datafed is almost 500 lines of python. That's a substantial investment and waste of human resources.

The importance of NetCDF Conventions

NetCDF is a fine format when it comes to syntax. The library tells you what the variables and their dimensions are, and can get you the data with ease. The semantic part is now taken care with the NetCDF conventions, which help programs to understand how that data relates to real world. Most important is perhaps the dimensionality: Where is a data point in the four dimensional physical world.

A typical quite successful case of a successful convention in the image processing is GeoTIFF, a TIFF image with geographical projection in it. With a plain PNG image, you'd have to know yourself what the projection is, with GeoTIFF it's in the image itself.

This means no more scripting. Open a NetCDF file with your program, and the convention guides the applications.

The OWS system is promoting NetCDF Climate and Forecast (CF) Metadata Convention and it's latest version CF-1.5

Creating the First WCS based on WCS 1.1.0

The original OWS system was started August 2007 with the idea, that if CF convention simplifies the client code, it can also simplify the server code.

• WCS GetCapabilites requires a list of coverages and their extents.
• WCS DescribeCoverage requires a coverage, its dimensions and its fields.
• WCS GetCoverage requires mapping the physical query ranges into array indexes.

All of these can come directly out of CF-NetCDF file, without any human help.

A computer can host several WCS services, which are not related at all. For example:

   http://htap.icg.kfa-juelich.de:58080/HTAP_FC_pressure
   http://htap.icg.kfa-juelich.de:58080/MACC_bnds

These two are two services HTAP_FC_pressure and MACC_bnds in htap.icg.kfa-juelich.de and creating a service is now simple: It's a folder in your file system containing NetCDF files. There is no link between different services.

A WCS Service can have any number of coverages with completely different kind of data and dimensions. Each Coverage is a collection of data in the same spatial/temporal dimensions. Each NetCDF file contains one or more variables that share the same time,latitude and longitude dimensions. This leads to the next mapping: Each NetCDF file becomes a coverage.

A field is a scalar data offering inside a coverage. For example weather coverage may offer temperature, humidity, wind speed, wind direction, cloud coverage fields. If a netcdf file has latitude, longitude and time dimensions and then temperature, humidity etc... variables, it's natural to make a NetCDF variable a field and NetCDF coordinate variable a dimension.

So the HTAP_FC_pressure folder has NetCDF files GISS-PUCCINI-modelEaer_FC1_aerosolm.nc and GISS-PUCCINI-modelEaer_FC2_aerosolm.nc. The coverages are then called respectively GISS-PUCCINI-modelEaer_FC1_aerosolm and GISS-PUCCINI-modelEaer_FC2_aerosolm. Here is a sample DescribeCoverage query, generated automatically from the NetCDF file.

Mapping between NetCDF Files and WCS Services

• Have a computer, even a workstation will do.
• A folder becomes a WCS service.
• A NetCDF file becomes a WCS Coverage.
• A NetCDF data variable becomes a WCS Field.
• A NetCDF coordinate variable becomes a WCS Dimension.
• NetCDF attributes like "units" are mapped to DescribeCoverage.
• All you need to fill is the service abstract, keywords, usage restrictions and contact person.

The real configuration is done when creating the NetCDF files, and it's just reused in the WCS.

Adding Point Data

The WCS is designed for N-dimensional cubes. A lot of data in the world is anyway collected from stations distributed in randomly placed stations. While it's possible to interpolate such data into a cube, it is also important to be able to get the original data in relational table form: time, station code, data.

The station time series has a time dimension, but it does not have latitude or longitude dimensions. They are properties of the location dimension.

The WCS query itself can be used to subset point data just fine. Since OWS is the only WCS service for point data, we're inventing our own conventions here.

Benefits of WCS standard versus just using CGI queries

The plain CGI queries don't carry any semantics, so it's not possible to write a generic client.

• Once you have your data published as a WCS service, the benefits are immediate:
  • You can register your service to datafed catalog and let others find it.
  • You can browse it too.
• You can write a generic data processing client: filter, aggregate, combine.
• Piggybacking a WMS service on top of a WCS service in in plans.