WCS Wrapper Standards

From Earth Science Information Partners (ESIP)
Revision as of 17:32, December 14, 2010 by Hoijarvi (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Back to aq-ogc-services.sourceforge.net

Standards used in this project.

The OWS project attempts to use existing standards whenever possible, and invent own conventions only when no agreement exists.

NetCDF Standards

NetCDF is a well established binary standard with cross platform libraries. Unfortunately, NetCDF alone does not guarantee interoperability. NetCDF just describes the syntax, not semantics. Semantic problems include but are not limited to:

  • How do you define what the projection of the data is?
  • How do you calculate lattitude and longitude coordinates to plot it on a map?
  • How do you get the time of the measurement?
  • What is the physical parameter the data is about?
  • What are the units of the data?
  • Is the elevation atmosphere of ocean depth?

And so on. These problems have been addressed with NetCDF conventions which tell people, that if you mark time variable "hours since 1990-01-01" then it's easy to tell that 12 means 1990-01-01T13:00:00 without any help from humans.

CF-Conventions

The recommended convention is NetCDF Climate and Forecast (CF) Metadata Convention and it's latest version CF-1.5

CF Standard Names

The standard name table is used to identify real chemical/physical category of the data.

Official source: CF Standard Name Tables. The latest version is v15, so the document is alive and updated.

Datafed has combined some unofficial names from the HTAP project: datafed standard names table which may or may not be official one day.

CF-NetCDF For Cubes

This is the original data type and it standardizes vast majority of important metadata so that plug'n play processing is possible.

CF-NetCDF for Timeseries of Station Data

The type of data that OWS deals with is Timeseries of Station Data.

Currently WCS supports this kind of data, but the source being SQL and output being CSV, [#Comma_Separated_Values Comma Separated Values].

In the future the plans are to first allow converting the output data as CF-1.5, and later serve station data directly from CF-NetCDF files.

OpenGeoSpatial Web Services Standards

The OpenGeoSpatial Consortium has plenty of Web Service Standards. The OWS system has been designed from the beginning to support any of these standards by separating the low-level web protocols from the actual service module.

Web Coverage Service 1.1.x

The most important standard is Web Coverage Service, WCS 1.1.2. The standard focuses only to N-dimensional cubed data, but the OWS system extends this with Timeseries of Station Data, Point Data.

Because there is no good way to describe the location table in CoverageDescription, OWS uses the Web Feature Service 1.0.0 to deliver the location tables.

The supported formats are currently CF-NetCDF for cubes and CSV for points. Planned future formats are:

  • Cubes: image/png
  • Points: CF-NetCDF station time series, XML as .NET datasets.

Web Feature Service 1.0.0

The Web Feature Service WFS 1.0.0 is designed to deliver static features of geographical landscape. Currently OWS has partial support for this, The GetFeature Query is implemented to deliver the location table of a point coverage.

Currently supported format is CSV, [#Comma_Separated_Values Comma Separated Values].

Web Map Service

The Web Map Service: WMS 1.0.0 .. 1.3.1 is very nice when you want to display your data on a map. There are plenty of clients out there, that work with any WMS server.

The plan currently is to piggyback a WMS server over any WCS. So if you have a WCS, you don't have to do a thing to view it.

Comma Separated Values

Comma Separated Values, CSV as MS Excel understands them.

This is a simple human readable, machine-readable file format that may programs, for example MS Excel can display as is.

Python has library support for CSV.

Web Protocol Standard HTTP GET

This is the only supported standard for query inputs. Others, like SOAP over HTTP-POST, don't add enough value to deserve support.

The big advantage is that queries can be done from any web browser.

Authentication or https is not supported yet. If you need authentication, you have to use a VPN, firewalls, or similar technologies.