WCS-CF-netCDF Matching

From Earth Science Information Partners (ESIP)

< Back to Glossary | Edit with Form

WCS-CF-netCDF_Matching Description: Term Description

Glossary Domain: WCS, HTAP

Related Links

Links to this page
No Links


No Contributors


No History Available

Term Details

The nice match between netCDF-CF and WCS 1.1

The obvious benefit is the ease that software tools can read the files and recognize the meaning of each item. The Datafed datafed WCS service framework is such a tool, it relies heavily on CF information in Data Configuration for Cubes, making it possible to automatically create a WCS 1.1 service from files.

  • Each netCDF file becomes a coverage. So a WCS service may contain several, unrelated and different looking coverages.
  • Each data variable in the netCDF file becomes a field in the coverages. Variables share the dimensions, so coverage fields have equal latitude, longitude and time dimensions.
    • A coverage is not a single piece of data, a coverage is a record of fields, like a netCDF file is a collection of variables.
    • Coverages do not have units. The global attributes in netCDF files do not contain units either.
    • Coverage must have at least one field. A netCDF file must have a variable to contain data.
    • A field is a single measure. A netCDF variable has a scalar type: int, float, char etc...
    • Fields do have a scalar unit of measure. Units in netCDF files are associated to individual variables.
    • A field can be a data field or metadata field: a quality flag or measurement error range.

Some design advice:

  • If the measurements have big mismatch, they should be different coverages.
  • If fields relate to each other, they should be in the same coverage:
    • weather coverage: file "weather.nc"
      • temperature field
      • humidity field
      • visibility field
      • weather code field: relates to all the measurements and it (clear | rain | show | tornado) can be used to filter out misleading data.
  • If the measurements are related, but each data variable has an independent set of quality flags, it may be better to create a separate coverage for each measurement. For example:
    • temperature coverage: file "temperature.nc"
      • temperature field
      • number of observations field
      • quality flag field
    • wind coverage: file "wind.nc"
      • speed field
      • direction field
      • gust maximum field
      • number of observations field

In this case, fields that belong together are in separate coverages. This is advisable to avoid incorrect associations between fields. Like the two "number of observations" are totally different fields and "quality flag" only relates to temperature, not to wind. It would be possible to put these to one coverage, since the wind and temperature may have identical dimensions. The design decision here is to weigh pros and cons of each arrangement.