Difference between revisions of "WCS Wrapper About"

From Earth Science Information Partners (ESIP)
Line 59: Line 59:
  
 
The real configuration is done when creating the NetCDF files, and it's just reused in the WCS.
 
The real configuration is done when creating the NetCDF files, and it's just reused in the WCS.
 +
 +
== Co-Operation with Juelich ==
 +
 +
Year 2009 Forschungszentrum Juelich became a user, and they made significant contributions to the code base in the Linux port.
 +
 +
Year 2010 the new WCS versions 1.1.1 and 1.1.2 were implemented, as well as much improved filtering of dimensions.
  
 
== Adding Point Data ==
 
== Adding Point Data ==

Revision as of 14:56, December 3, 2010

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 dependency 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.

Shortly put:

  • 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.

Co-Operation with Juelich

Year 2009 Forschungszentrum Juelich became a user, and they made significant contributions to the code base in the Linux port.

Year 2010 the new WCS versions 1.1.1 and 1.1.2 were implemented, as well as much improved filtering of dimensions.

Adding Point Data

What is station time series and how it's done

Benefits of WCS standard versus just using cgi queries

  • Catalog.aspx
  • browser.aspx
  • plug'n play processing