NcML/NetCDF Dataset
as Form of
OGC Web Coverage Service
Ben Domenico (for the arm-waving sections)
Stefano Nativi (for the substantive content)
Draft last modified:
August 15, 2005
Background
One might ask what is to be gained by having netCDF as one form of coverage
supported by WCS. There is much to be gained by both the Earth science community
that used netCDF as well as by the GIS community. Among the main reasons for
bringing the two together are:
- The netCDF data model is very popular among scientists belonging to the
Earth Sciences Information Community. In fact, the netCDF is the most commonly
used for in which to access the output of weather and cliamate forecast models.
The output of these models is different from many of the other datasets currently
supported by in the GIS community.
- The netCDF interface is evolving in a direction that supports access to
many different file formats via several different client/server protocols
(e.g., OPeNDAP and ADDE) that are already established in the atmospheric and
ocean sciences data provider community.
- OGC’s WCS can be successfully used to dispatch netCDF datasets via
standardized protocols to many interested groups:
- the Earth Science Information Community (many of whom now use netCDF
interfaces)
- the GIS Information Community
- the general public
Thus the inclusion of netCDF as a WCS format adds only one new data access
interface that in turn brings in collections of forecast model data via a variety
of protocols that are already in use in the data provider community. A draft
conceptual overview of this approach is provided in THREDDS-Integrated
Dataset Discovery and Access Overview
The General Idea
To incorporate netCDF as an alternative for WCS data access, extentions are
needed for both the netCDF interface and the WCS specifcation. The key tasks
would be:
- To extend the netCDF software implementing a mediation component which
maps netCDF (plus conventions) data content model onto WCS data content model.
- To extend the WCS specification in order to support the returning of datasets
characterized by a content modeled according to netCDF data content model;
such datasets must be encoded in one of three possible format: netCDF file,
ncML document, ncML-GML document.
- returning a netCDF file is mainly useful to comply with Earth Sciences
applications requirements;
- returning a ncML document is mainly useful to interoperate with Science
Digital Library applications. Besides, Earth Sciences applications will
require more and more netCDF datasets in a semi-structured encoding.
- returning a ncML-GML document is mainly useful to interoperate with
GIS applications. Besides, Science Digital Library and Earth Sciences
applications will require more and more netCDF datasets in a semi-structured
encoding compliant with ISO 19115 specifcations.
Figure 1 depicts the rationale concepts as well as the extension needs.
Fig. 1 – the WCS extension to accommodate netCDF datasets
Data Model Mediation
Figure 2 shows the model mediation scenario. WCS data content model is based
on ISO 19100 specifications; GML 3.x is based on ISO 19100 specifications.
Fig. 2 Model Mediation
We have already mediated the THREDDS Dataset Inventory Catalog (DIC) content
model to ISO 19115 model. Besides, the ncML-GML specifications mediates from
ncML-CS to GML 3.0, sorting out issues related to the lack of some metadata
(we should extend the present netCDF conventions, or introduce a new one).
If such mediations, duly formalized, could be included in the WCS extension
document for netCDF, they could be the basis for initiating the integration
of netCDF into WCS.
Example case for netCDF WCS
For the purposes of clarifying the discussion with a specific example, we can
use a collection of forecast model output files in netCDF fomr with an associated
catalog. This collection is described in:
http://www.unidata.ucar.edu/projects/THREDDS/DataPublications/SampleDataPublicationFor2005AMS.htm
which provides access to the catalog and datasets via a desktop analysis and
display tool that currently accesses the datasets via the OPeNDAP protocol.
If we use this case study collection for a WCS experiment, we'd have to create
coverage information for the two main classes of forecast model output contained
in the collection:
To support these datasets in a WCS server via a netCDF interface, the server
would have to respond to GetCapabilities, DescribeCoverage,
and GetCoverage requests as noted in the sections below..
GetCapabilities
GetCapabilities responses include information about available
coverages:
- service (describes service and service provider in human readable form,
e.g., description, name, label ..., may point to external metadata description)
. This is similar to the Dublin Core metadata required by NSDL. Do we have
Dublin Core descriptions of the Meso Eta and Workstation Eta.
- capability (describes requests that the service supports). In our case,
this would describe netCDF services.
- content metadata (xlink attributes belonging to the GML AssociatedAttributeGroup??
for external metadata references.) Could this be a reference to an NcML file
describing the Eta model form in our example case?
This section can also have "coverageOptionBrief" which I don't really
understand at this point.)
DescribeCoverage
NcML (including NcML-GML) will be used for:
DescribeCoverage responses include information about specific
coverages:
- domainSet (lat/long, time extremes, note that forecast model output domain
has special time of forecast)
- rangeSet (permitted values of parameters, can all parameters be included?
This is a key question for us. Do temperature, pressure, etc. grids have to
be transmitted as separate coverages?)
- supportedCRSs (coordinate reference system -- NcML-CS or NcML-GML??)
- supported formats (netCDF -- with convention??)
- supported interpolation (none?)
- For our Eta model output, can all parameters be included in one coverage?
For an overview of the primary characteristics of NcML in tabular form, please
see: NcML: The Key Components
For a detailed description of NcML-GML, please see NetCDF
Markup Language (NcML) and its GML-based extension (NcML-GML).
GetCoverage
The currently supported WCS formats are:
- GeoTIFF,
TIFF based interchange format for georeferenced raster imagery
- HDF-EOS, Heirarchical
Data Format for the Earth Observing System
- DTED,
Digital Terrain Elevation Data
- NITF, National
Imagery Transmission Format
- GML,
Geography Markup Language
A WCS server has to support one of these formats. We are proposing to add NetCDF
Dataset as an additional access form. This could be included as an "other"
encoding initially, but it would be good to have it as an additional supported
encoding eventually.
The GetCoverage request specifies:
- URL of WCS server. Required.
- WCS Service name: Must be “WCS”. Required.
- Request protocol version. Required.
- Name of the request. Must be “GetCoverage”. Required.
- Name of an available coverage. Required.
- Coordinate Reference System in which the request is expressed. Required.
- Coordinate Reference System in which to express coverage responses. Optional;
defaults to the request CRS.
- Request a subset defined by the specified bounding box, with min/max coordinate
pairs ordered according to the
Coordinate Reference System identified by the CRS parameter. One of BBOX or
TIME is required.
- Request a subset corresponding to the specified time instants or intervals,
expressed in an extended ISO 8601 syntax.
Optional if a default time (or fixed time, or no time) is defined for the
selected layer. One of BBOX or TIME is required.
- Request a range subset defined by constraining parameter PARAMETER. The
PARAMETER key is a variable string; it
must match the name of a parameter listed in the range set description of
the selected coverage.
Optional if the chosen range component has default values for the parameter.
- Request a grid of the specified width (w), height (h), and [for 3D grids]
depth (d) (integer number of gridpoints). Either these or the subset in terms
of the coordinate reference system (next item) is required.
- Request a coverage subset with a specific spatial resolution along each
axis of the reply CRS. The values are given in
the units appropriate to each axis of the CRS. Either these or WIDTH, HEIGHT,
and [for 3D grids] DEPTH (previous item) are required.
- Requested output format of Coverage. Must be one of those listed under the
description of the selected coverage. Required.
- The format in which exceptions are to be reported by the Server. Optional.
A NetCDF Dataset interface would have to respond to such a request with the
data in netCDF dataset form.
