Encoding of Coverages in NetCDF

Document Sample
Encoding of Coverages in NetCDF Powered By Docstoc
					       Data Model Mapping Related to
      Encoding of WCS Coverages in CF-
 Ben Domenico, Stefano Nativi, John Caron, Lorenzo Bigagli, Wenli Yang, John Evans
                            Last Modified: June 4, 2006

General Overview and Issues
This document describes the mapping between ISO 19123 data model used as the basis
for WCS and the data model of the netCDF using CF conventions. The mapping will
change as the WCS and CF specifications evolve. However, by using the ISO data model
and describing the mapping between the two data models at a conceptual level, the
description should remain relatively stable.

NetCDF Background
NetCDF (Network Common Data Form) is an interface for array-oriented data access and
a library that provides an implementation of the interface. The netCDF library also
defines a machine-independent format for representing scientific data. Together, the
interface, library, and format support the creation, access, and sharing of scientific data.
In brief, netCDF is a very general purpose form for data storage and access. Thus it is not
surprising that the general netCDF data model is quite different from that of the WCS
Coverage which was specifically conceived for geospatial data. But, among its many
uses, netCDF is quite commonly and successfully used for geospatial data -- especially
data in the realms of atmospheric science and oceanography -- the sciences concerned
with the fluid portions of the globe (FES or Fluid Earth Sciences). Many netCDF user
communities have developed conventions for the use of netCDF with their types of data.
The FES community is converging on the Climate and Forecast (CF) conventions
<> in order to define geospatial
coordinate systems and other semantics equivalent to those in the WCS data model.

NetCDF in the WCS Coverage Context
The salient characteristics of the WCS coverage are listed in the first column of the table
below with the corresponding general characteristics of the netCDF dataset: the middle
column for the generic netCDF and the right column for netCDF conforming to CF
(Climate and Forecast) conventions.

                               netCDF dataset              netCDF dataset (CF
      WCS Coverage
                                  (general)                   conventions)
  At least 2 spatial
  dimensions,            Arbitrary number of
                                                   No lower limit on dimensions.
  optional 3rd spatial   dimensions (i.e.axes).
1                                                  Up to 3 spatial dimensions,
  dimension,             One dimension can be
                                                   one time dimension
  optional time          unlimited.
                                                   Arbitrary number of scalar
  Coverage range - set   Arbitrary number of       variables representing multiple
  of values              scalar variables          entities. A "standard_name"
  representing one       representing multiple     attribute maps variable names to
  entity                 entities                  a controlled set of names in the
                                                   CF conventions name table.
                                                 Each variables can have a
  Coverage range has     Each variables can have
                                                 different unit of measure. Units
3 single unit of         a different unit of
                                                 of measure must conform to CF
  measure                measure
                                                   The dimensions do not have any
                                                   pre-specified order. so the shape
                                                   is arbitrary. However, CF
                         The dimensions do not
                                                   conventions recommends that
                         have any pre-specified
                                                   dimensions be ordered according
    (x,y,z,t) domain     order, so the shape is
4                                                  to *TZYX (§2.4); also note that
    shape                arbitrary except that the
                                                   a time-series of soundings
                         unlimited dimension
                                                   depending on pressure and
                         must be first.
                                                   location, with time modeled as
                                                   the unlimited dimension, does
                                                   not follow this recommendation
                                                   Implicit geolocation metadata.
    Explicit geolocation
5                        Geolocation optional      Must conform to CF
    Grid geometry                                  Grid geometry can be irregularly
6                        Arbitrary grid geometry
    regularly spaced                               spaced

More detailed explanation of table elements

       Row 1: WCS coverage model versus netCDF arrays

       1) The basic of WCS coverage model and netCDF arrays

       WCS models a coverage as a spatial function that assigns tuples of values
       to locations in space & time – viz., f(x,y,z,t)={value1, value2, value3,
       ….}. Each “value” in the range of this function may be a scalar (e.g.,
       brightness between 0 and 255), or an array with one or more dimensions
       (e.g., brightness values measured at different wavelengths). A scalar-
       valued coverage can be expressed as f(x,y,z,t)=V1; an array-valued
       coverage can be expressed as f(x,y,z,t)=V2(w), where w indicates
       wavelength. A coverage with both kinds of values might be expressed as
       f(x,y,z,t)={V1, V2(w)}.

       It should be noted, however, the above is just a conceptual view, the grid
       coverage data are still multidimensional arrays with the temporal-spatial
       dimensions included. Even the single value V1 is also measured at
       different spatial (x,y,z) and time (t) positions, unless the x, y, z, and t are
       fixed at just one position.

       Thus, the above grid coverage is actually equivalent to two data arrays: a
       4-D array: V1(x,y,z,t) and a 5-D array: V2(x,y,z,t,w). These are not
       different from the netCDF data arrays. The only difference between WCS
       grid and netCDF array is that WCS distinguishes the spatial/temporal
       dimensions, (x,y,z,t) from other dimensions (e.g., w).

       2) Number of axes (dimensions)

       Although WCS conceptually requires spatial/temporal dimensions to
       define the “domain” of a coverage, it does not necessarily mean that the
       data array, representing the values of the coverage, must have these
       dimensions explicitly present. For example, values of a variable may be
       measured at several, say 10, positions along x-dimension but only at one
       specific position at y-dimension, at specific time and elevation. The data
       array in this case is actually a 1-D array with 10 elements, but
       conceptually it can still be considered as 4-dimensional coverage, except
       that the ranges of the y, z, and t dimensions are all a single value (the x-
       dimension change from position 1 to 10). Therefore, the required two
       dimensions (i.e., the x and y dimensions) should not be an issue in
       comparing a WCS grid and a netCDF array.

       3) The spatial/temporal axes in WCS coverage and in netCDF

Although the number of dimensions itself in WCS coverage and in netCDF does
not conflict with from the view point of multi-dimensional arrays, there will be a
problem when multiple multi-dimension arrays (each representing one variable)
are involved. In WCS, everything included in one coverage must have the same
domain, i.e., the same spatial/temporal dimensions. In netCDF, there is no
restriction to the dimensions of different variable included in one netCDF file. For
example, if a temperature measurement, T, and a pressure measurement, P, are
included in a coverage, f(x,y)={T,P}, the (x,y) domain is the same for T and P.
That is, the (x,y) in array T(x,y) and array P(x,y) are the same. While in netCDF,
if two variables T and P (both 2-D arrays: T(x,y) and P(x,y)) are included in one
netCDF file, there is no requirement on whether the (x,y) associated with variable
T should or should not be the same as the (x,y) associated with variable P. In
effect, one netCDF dataset can contain many coverages.

       Row 2: WCS coverage range versus netCDF variables

       As mentioned above, the WCS coverage range can contain more than one
       entities (called measures or attributes or properties or fields or variables or
       parameters – still under discussion), such as Temperature and Pressure
       f(x,y)={T,P}, which correspond to different variables in netCDF. There is
       a name associated with each such WCS range entities. Thus netCDF
       variables and WCS range entities are equivalent. The biggest issue is that,
       as mentioned in item 3 of Row 1 above, WCS requires the
       spatial/temporal domain of all range entities to be the same while in
       netCDF such requirement does not exist.

       Row 3: WCS coverage range unit versus netCDF variable unit

WCS coverage range can have different unit for different entities included in the
range. For example, the T and P in f(x,y)={T,P} have different units.

       Row 4: The shape of (x,y,z, t) in WCS

       WCS does not require that the x, y, z, and t dimensions need to be ordered
       in any specific order. The (x,y,z,t) can be order in any order corresponding
       to specific spatial (and temporal) coordinate reference system. For
       example, the latitude axis may be before or after the longitude axis,
       depending on the coordinate reference system used.

       Row 5: Geolocation

       WCS intends to be used for geospatial coverage, the coverage data thus
       must have certain kind of geolocation information. The spatial part,
       (x,y,z), of the (x,y,z,t) is used to define the geolocation of a coverage. It
       can be either explicit or implicit. The explicit way is that the (x,y) (the z-
       dimension is dropped here just for simplicity) is some kind of geo-
       coordinate system, such as latitude/longitude. The implicit way is that the
       (x,y) is some non-geo coordinate such as row/column but is associated
       with geo-coordinate. Additional information is needed to tell how the non-
       geo coordinate, row/column, is associated with geo coordinate so that
       geolocating can be done. In a recent WCS design document written by
       Arliss Whiteside, a non-georectified and non-geo-referenced grid use case
       is presented. In such a non-georectified and non-geo-referenced grid, there
       is no geo-referencing information and thus request of grid data can only be
       done by grid, or image, coordinate. But for geospatial application, any
       data can eventually be associated with some kind of geo-information.
       Row 6: Grid geometry

       The WCS grid geometry can be irregularly spaced. The orbital swath data
       is one of the examples.

Additional Spatial and Temporal Dimensions
Besides the characteristics shown in the table, the FES community often employs
specialized coordinate systems for specific datasets. For example, the vertical spatial
dimension can be pressure in the atmosphere or density in the ocean. Or there may be a
such a vertical dimension in addition to vertical height; likewise, additional, a forcast-
time axis may be used in addition to a real time axis. Consequently, the earth scientist
thinks in a 4 or 5-dimensional space and requires a 4 or 5-dimensional data model or an
arbitrary n-dimensional data model. Each dimension is an independent scalar variable; we
can think of a netCDF gridded-based datasets as a 4-D, 5-D (or n-D) hypercube

Dimension space geometry can be implicit (e.g. grids) or explicit (e.g. multi-points);
semi-implicit geometry is possible as well, such as irregular grid geometries, i.e.,
geometries where the distance among adjacent points along one or more of the grid axes
is not constant. The co-dimensions (i.e. range set) can be numerous, defined on all the
independent variables or on a subset of them. Each co-dimension is a dependent scalar
variable. NetCDF data model was designed to encode such datasets in a straightforward
and flexible way. Indeed, a netCDF dataset can contain different 3/4/5 D coordinate
systems, which can share common axes.

       Spatial and temporal dimensions

       WCS coverage has only one temporal dimension and three spatial
       dimensions. Additional height and time dimensions in FES data may need
       to be treated as other axes in coverage. For example, a 5-D data, P, with
       two time dimensions, t1, and t2, and two height dimensions, z1, and z2,
       may be announced in a WCS server as to have a (x,y,z1,t1) domain and
       two axes, z2, and t2, which represent the additional height and time
       dimensions: f(x,y,z1,t1)={P(z2,t2)}. The data array itself is a 5-D array
       P(x,y,z1,z2,t1,t2) although it is conceptually considered as a WCS grid
       having two axes and being defined in a 3-D spatial/temporal domain. A
       client will be able to do subset of such a coverage (5-D array) with
       appropriate spatial/temporal and axis subset specified. The server can
       decide which time and height dimension should be treated as WCS
       domain dimensions and which should be treated as WCS axes.


       As mentioned in comment on Row 1 (3) above, more than one variables
       can be contained in a WCS coverage and different variable can share, all
       or partial, dimensions. The difference is that the dimensions treated as
       domain dimensions in WCS coverage (i.e., the x,y,z,t dimensions) must be
       the same for all variables while this is not required in netCDF, in which
       different variable can have different coordinate reference systems.

Metadata Mapping
Much of the metadata for netCDF datasets is implicit in the conventions. The information
in the netCDF itself combined with that implied in the CF conventions can be mapped
into a corresponding set of GIS coverage concepts:

      A netCDF dataset often contains many different variables (a hundred or more is
       not uncommon for large model simulations). Because each variable has unique
       units, each becomes a separate coverage.
      Each coverage is characterized by a domain and a range-set and is referenced by a
       coordinate system/coordinate reference system;
      Each coverage is optionally described by a geographic extent;
      Each domain is characterized by a geometry, one of the following supported
       domains: regular grid domain, irregular grid domain and multipoint domain;
      Each range-set lists or points to a set of values associated to each domain location,
       one of the following supported range-set types: scalar range-set and parametric

Additional Detail on Metadata Mapping

       1) Variables versus range

       As mentioned above, a WCS coverage can have one or more variables
       with different units (the term, variable or some other term, has not been
       finalized). A coverage has one domain, (x,y,z,t), and one range,
       {variable(s)}. The latter can include more than one variables.

       2) Domain geometry

       Since WCS is designed for grid coverage, regular grid and irregular grid
       may be the geometry should be considered. At the current state of the
       standards, point data should be served in Web Feature Service (WFS).
       However, in the future WCS may be able to handle point-based coverages
       as well. (Compared with WFS, it would provide a different view of those
       features, not as unconnected points, but as representing a spatially-varying

       3) Scalar versus compound values in the range-set

       A scalar value in a range set denotes a single value associated to each
       location in the domain, such as f(x,y,z,t)={T}. The corresponding NetCDF
       variable has at most 4 dimensions, T(x,y,z,t).
       A compound value in a rangeset denotes a set of values associated with
       each location in the domain, such as radiances, R(w), measured at
       different wavelength, w. Thus the coverage is expressed as
       f(x,y,z,t)={R(w)}. The corresponding NetCDF data array has 5-
       dimensions: R(x,y,z,t,w).

NetCDF as WCS Direct Binary Encoding Form
In the direct usage of netCDF as a WCS binary encoding format, the server, in response
to the getCoverage request simply returns a binary consistent netCDF file object (as
opposed to simple “data chunks” even though the server may prene
dimensions,coordinate variables, etc. that are not requested by the client). The server
must return the requested coverage(s) as netCDF variables and associated coordinate
variables. If the WCS request asks for a subset, the variable and its coordinates must be
appropriately subsetted. The server should remove unneeded dimensions, variables, etc.
not needed by the requested coverages. The exact encoding must be documented and
published as a NetCDF Convention; we recommend the CF-1.0 Convention, or variants
of it as recommended by the CF working groups. In essence this means that the client can
write this object to disk and then manipulate it using the netCDF interface. This is the
approach used on the experimental Unidata WCS server: The NetCDF file has the
coordinate system information encoded in a standard way. The Netcdf libraries are
currently being developed to automatically extract coordinate system information through
a standard API.

Some Challenges for Direct Binary Encoding at Present

       With the conceptual models in WCS coverage and in netCDF as the
       starting point, the key to the mapping is the relationship between the WCS
       grid and netCDF multi-dimensional arrays. In fact, the WCS coverage is
       entirely conceptual and does not prescribe the physical grid data array. But
       the grid data are normally stored as multidimensional arrays as in netCDF.

       At present includes two aspects present some difficulties. First, how the
       spatial/temporal dimensions in netCDF can be completely represented in
       WCS? NetCDF is very flexible regarding to these dimensions while OGC
       has clearly defined Coordinate Reference System identifiers. A set of
       commonly used spatial/temporal dimensions from netCDF CF
       conventions may have to be included in the OGC recognized identifier set.
       This may also provide solutions for the additional time and height
       dimensions, and other coordinates like atmospheric presssure coordinate.
       Second, how to identify a subset of netCDF, with clear, specific, and
       commonly accepted convention, which is general enough to represent the
       most netCDF user communities yet is simple (or easy) enough to be
       quickly started for discussion/implementation.
       One approach (being undertaken in the GALEON Interoperability
       Experiment) is to identify a few netCDF files that are commonly used in
       the FES communities to illustrate the metadata included in these files in
       terms of coordinate reference systems, geolocation methods, naming
       conventions, other metadata, and common operations on those files (e.g.,
       subsetting along certain dimensions). By comparing these with the WCS
       coverage model, the current WCS interface, and the available WCS
       resources (e.g., interpolation methods, subsetting methods, coordinate
       system identifiers), we will be able to identify what can be easily done by
       WCS and what is difficult. This will lead to a more complete netCDF
       profile for WCS and may also provide additional input to the WCS
       specification revision.

NetCDF Encoded in ncML-GML with Binary Data via
An alternative the server response to at getCoverage request is an ncML-GML document
which includes an OPeNDAP URL pointer to the binary encoded data which can be
retrieved via the OPeNDAP protocol. This approach is used on the University of Florence
WCS-G server:

NetCDF Fully Encoded in ncML-GML
The University of Florence WCS-G server has an alternative option for requesting the
data fully encoded into ncML-GML. In this case the entire requested dataset is returned
as an ncML-GML document, so there is no need for a binary encoding. However, for
large netCDF datasets, this alternative may be impractical.

<<<Need a reference to the latest version of the ncML-GML documentation>>>

Leveraging SOAP technology, the University of Florence WCS-G server implemented a
third option for responding to a getCoverage SOAP request: the requested dataset
metadata are returned as an ncML-GML document contained in the SOAP response
body, while the corresponding binary netCDF file object is included as a SOAP
Detailed, Formal NetCDF Data Model
Mapping to ISO 19123 Coverage
Standard for WCS implementation
The scope of this document is to specify a conceptual map between a profile of the CF-
netCDF data model, specifically introduced for this purpose, and the geo-information
coverage model as specified by the ISO 19123 standard.

This mapping is essential to implement WCS server which supports CF-netCDF datasets.
In fact, the main WCS objective is to provide access to standard geo-information
coverages. While WCS specification is under revision, ISO 19123 specification was
recently approved.

This mapping can be leveraged to conceive similar mappings for other Earth Sciences
well-accepted data models, such as: HDF and OPeDAP.

NetCDF and its extension CF-netCDF data models will be briefly described. Then, the
geo-information coverage data model, as defined by ISO 19123, will be introduced.

Due to the complexity of our scope, we decided to proceed step-by-step; thus, we started
considering only coverages characterized by a regularly spaced domain, positioned using
a geographic CRS.

Therefore, the discrete grid point coverage model will be utilized as co-domain of our
mapping. Actually, a profile of the general model for discrete grid point coverage will be

After that, a CF-netCDF profile will be specified in order to provide the lowest amount of
required semantics to support the generation of geo-information coverages.

Then, the mapping rules from the CF-netCDF profile to the discrete grid point coverage
model profile will be specified.

Finally, important issues will be discussed.

1. The netCDF data model
The following figure depicts the netCDF-3 data model.

                                           << Ty pe >>

             Attribute                                                     Dimension

         +name:String                                                    +name:String
         +v alue:Record                                                  +length:int
         +ty pe:DataTy pe
                                *                        shape       *
                                                                                   << CodeList >>
                                             Variable                                   DataTyp e

                                        +name:String                              +by te:int
                                        +shape:Dimension[]                        +char:int
                                        +ty pe:DataTy pe                          +short:int

                                        CoordinateVariab le

                                    Fig. 1 – netCDF-3 data model

NetCDF-3 data model is simple and hence powerful. In fact, as far as semantics is
concerned, it is based on very “general” concepts, such as: variable, dimension and
attribute. Hence, any other data description element (i.e. metadata) may be captured using
the generic “attribute” semantics.

2. Climate and Forecast Conventions: CF-netCDF data model
In order to introduce more specific semantic elements (i.e. metadata) which are required
by different communities to fully describe their datasets, the netCDF data model was
extended adding a set of conventions. One of the most popular convention is the Climate
and Forecasting metadata convention (CF). The following figure depicts the CF-netCDF
data model.

CF conventions are quite loose, to maximize backward compatibility with COARDS.
Besides, support to precise geo-location is scarce. For example, CF conventions assume
that “Latitude, longitude, and time are defined by internationally recognized standards,
and hence, identifying the coordinates of these types is sufficient to locate data values
uniquely with respect to time and a point on the earth's surface.”

On the other hand, CF model is very flexible and, consequently, complex. The following
diagram depicts CF conventions and their relationship with netCDF concepts, in UML.
CF-netCDF model

                                                                                       -Conv entions:String=CF-1.0
                      -Conv entions:String
                      -history:String                                                                                                  GridMappin gVariable
                                                                                       -ref erence:String                           -grid_mapping_name :String

                                                        local attributes
                                                        ov erride global ones
                  *                     *
     Dimension                                   Variable                              -institution:String
                                             -shape:Dimension[]                        -source:String
                                                                                       -ref erences:String
                                                                                       -long_name :String                                  ClimatologyVariable
                                                                                       -grid_mapping :GridMappingVariable
                                                                                       -bounds:Boundary Variable
                                       CoordinateVariable                              -cell_measures:String
 { shape->size = 1}                                                                    -cell_methods:String
                                                                                       -scale_f actor int
                                                                                       -add_off set:int                                     Boun daryVariable


 - same name as related
  dimension                                                ScalarCoordinateVariab le
 - numeric v alues
 - monotonic


 Identif ied either v ia:                       -axis:X|Y |Z| T
 - units (length, pressure, etc.)
 - positiv e attribute
                                                                                                                                            units as def ined in
                                                                                                                                            Udunits package

                               Vertical Coordin ate               LatLonCoordinate             TimeCoordinate                 ClimatologicalTimeCoordin ate
                               -units:String                                                -calendar:String                  -climatology:Climatology Variable
                               -positiv e:up|down                                           -month_lengths:String
                               -f ormula_terms:String                                       -leap_y ear:int

                                              Fig. 2 – CF- netCDF data model
3. The Geo-Information Coverage model
A coverage is a feature that associates positions within a bounded space (its domain) to
feature attribute values (its range). In other words, it is both a feature and a function.
Examples include a raster image, a polygon overlay or a digital elevation matrix.. [ISO

The following Figure shows the coverage types introduced by ISO 19123.

As far as the general geo-information framework is concerned, Coverage is a feature
ContinuousCoverage type is the subclass of Coverage that returns a distinct record of
feature attribute values for any direct position within its domain. While, the domain of a
DiscreteCoverage consists of a collection of geometric objects. DiscreteCoverages are
subclassed on the basis of the type of geometric object in the spatial domain.
 Cov erageSubclassesModel

                                                               << metaclass >>
                                                               GF_FeatureT yp e

                                                                          << instantiates >>

                                                                  << Ty pe >>

                                                 << Ty pe >>                        << Ty pe >>
                                            CV_ContinuousCoverage               CV_DiscreteCoverage

                    << Ty pe >>                                                         (discriminator)     << Ty pe >>
      CV_ContinuousQuadrilaterGridCoverage                                                           CV_DiscretePointCoverage

                              << Ty pe >>                                                                   << Ty pe >>
                            CV_TINCoverage                                                         CV_DiscreteGridPointCoverage

                        << Ty pe >>                                                                        << Ty pe >>
               CV_Hexagon alGridCoverage                                                           CV_DiscreteCurveCoverage

                         << Ty pe >>                                                                        << Ty pe >>
               CV_SegmentedCurveCo verage                                                          CV_DiscreteSurfaceCoverage

                         << Ty pe >>                                                                      << Ty pe >>
               CV_Thiessen PolygonCoverage                                                         CV_DiscreteSolidCoverage

                                              Fig.3 Coverage types

DiscretePointCoverage type is characterized by a finite domain consisting of points.
Generally, the domain is a set of irregularly distributed points; the principal use of
discrete point coverages is to provide a basis for continuous coverage functions. Indeed,
DiscretePointCoverage occurrences could be used to implement multi-point coverage

The domain of a DiscreteGridPointCoverage occurrency is a set of GridPoints that are
associated with records of feature attribute values through a GridValuesMatrix element.
Certainly, DiscreteGridPointCoverage occurrences must be used to implement gridded-
based coverage domains -either regularly or quasi-regularly spaced ones.

The following Figure depicts the DiscreteGridPointCoverage model.

 DiscreteGridPointCov erageModel

                  << Abstract >>                                  << metaclass >>
                                                                                                                           << CodeList >>
                     SC_CRS                                       GF_FeatureT yp e
                                                                                                                       CV_CommonPoin tRule

                  + CRS                                                                                                +av arage:int
                                                        << instantiates >>
                                                                     << Ty pe >>                                       +all:int
                                                          CV_DiscreteGridPointCoverage                                 +start:int
             Coordinate Ref erence Sy stem              +domainExtent:EX_Extent [1..*]
                                    +                   +rangeTy pe:RecordTy pe
     /Cov erageFunction                                                               + ev aluator


                       *                                                           + v alueAssignment
                           + element

               CV_GridPointValuePair                                         << Ty pe >>                                          << Ty pe >>

               +point:CV_GridPoint                                     CV_GridValu eMatrix                                         CV_Grid
               +v alue:Record                                  +v alues:Sequencee<Record>                           +dimension:int
                                                               +sequencingRule:CV_SequenceRule          Valuation   +axisNames:Sequence<CharacterString>
                                                               +startSequence:CV_GridCoordinates                    +extent:CV_GridEnv elope

                               Fig.4 - Discrete Grid Point Coverage model

Referring to ISO 19123 elements specification:

The attribute domainExtent shall contain the extent of the domain of the coverage. The
data type EX_Extent is defined in ISO 19108:2003. Extents may be specified in space,
time or space-time.

The attribute rangeType shall describe the range of the coverage. The data type
RecordType is defined in ISO/TS 19103. It consists of a list of attribute name/data type
pairs. A simple list is the most common form of rangeType, but RecordType can be used
recursively to describe more complex structures.

The attribute commonPointRule shall identify the procedure to be used for evaluating the
Coverage at a position that falls either on a boundary between geometric objects or within
the boundaries of two or more overlapping geometric objects.
Coordinate Reference System
The association Coordinate Reference System shall link the Coverage to the coordinate
reference system to which the objects in its domain are referenced. The class SC_CRS is
specified in ISO 19111:2003. The multiplicity of the CRS role in the Coordinate
Reference System association is one, so a coverage with the same range but with its
domain defined in a different coordinate reference system is a different coverage.

The association CoverageFunction shall link the discrete Coverage to the set of
GeometryValuePairs included in the coverage. The association CoverageFunction is
shown as derived because the elements may be generated from the GridValuesMatrix
through the association PointFunction.

The association PointFunction shall link the DiscreteGridPointCoverage to the
GridValuesMatrix for which it is an evaluator. The range of a Coverage shall be a
homogeneous collection of records. That is, the range shall have a constant dimension
over the entire domain, and each field of the record shall provide a value of the same
attribute type over the entire domain.

The class GridPointValuePair describes an element of a set that defines the relationships
of a discrete grid point coverage. In fact, the domain of a DiscreteGridPointCoverage is a
set of GridPoints that are associated with records of feature attribute values through a
GridValuesMatrix. GridPointValuePair is composed of a GridPoint geometry and a
feature attribute value Record.

The attribute point shall be the geometry member of the GridPointValuePair.

The attribute value shall be the member of the GridPointValuePair taken from the
sequence values in the GridValuesMatrix.

GridValuesMatrix is a subclass of Grid that ties feature attribute values to grid geometry.
It has three attributes: values, sequencingRule and startSequence. It holds a sequence of
records associated with a sequencing rule that specifies an algorithm for assigning
records of feature attribute values to grid points. An instance of the GridValuesMatrix
may be, at the same time, an instance of either a generic Grid or one of its subclasses:
RectifiedGrid and ReferenceableGrid.

The attribute values shall be a sequence of N feature attribute value records where N is
the number of grid points within the section of the grid specified by extent.
The attribute sequencingRule shall describe how the grid points are ordered for
association to the elements of the sequence values.

The attribute startSequence shall identify the grid point to be associated with the first
record in the values sequence.

SequenceRule is a data type that contains information for mapping grid coordinates to a
position within the sequence of records of feature attribute values.
The attribute type shall identify the type of sequencing method that shall be used. The
default value shall be “linear”.

The attribute scanDirection shall be a list of signed axisNames that indicates the order in
which grid points shall be mapped to position within the sequence of records of feature
attribute values. An additional element may be included in the list to allow for
interleaving of feature attribute values. . See Annex D of ISO 19123.

SequenceType is a code list that identifies methods for sequential enumeration of the grid
points. See Annex D of ISO 19123.

Record and RecordType
A Record is a structure of logically related elements, and may be used as an
implementation representation for features, by keeping a list of (name, value) pairs in a
dictionary. This represents a generic storage structure for features.

A dictionary is similar to an array, except that the lookup index for an array is expressed
in integer numbers.

The following Figure shows the Grid model.

                                                                      << Ty pe >>                                    << DataTy pe >>
                                                                       CV_Grid                                      CV_GridEnvelop e
                                 + f ramework
                                                  +dimension :int                                             +low :CV_GridCoordinates
         Ev aluationStructure                     +axisNames :Sequence<CharacterString>                       +high :CV_GridCoordinates
                                                  +extent :CV_GridEnv elope
              1..*   + cell
                                                                                                                            << DataTy pe >>
                                                          + f ramework
        << DataTy pe >>                                                                                                   CV_GridCoordinates
          CV_GridCell                                                        Organization                     +coordValues :Sequence<Integer>

                                                                      1..*   + intersection
         + cell      1..*                  + corner
                                                                 << DataTy pe >>
                            Location             4..*                CV_GridPoint
                                                          +gridCoord:CV_GridCoordinates          1
                                       + gridPoint                                              + center

                                   Ref erence                                                              SampleSpace

                                          0..1                                                             + f ootprint
                                                     + groundPoint
                                        << Ty pe >>
                                         GM_Point                                           +geometry:GML_Object

                                                Fig. 5 - Grid geometry model

The class Grid contains the geometric characteristics of a quadrilateral grid.

The attribute dimension shall identify the dimensionality of the grid.

The attribute axisNames shall list the names of the grid axes.

The optional attribute extent GridEnvelope shall specify the limits of a section of the

The association Organization shall link the Grid to the set of GridPoints that are located
at the intersections of the grid lines.
Grid has three subclasses, which lie in two partitions. The following Figure depicts the
Grid subclasses. The Positioning partition includes RectifiedGrid and ReferenceableGrid,
which contain information that relates the grid coordinates to an external coordinate
reference system. The Valuation partition includes GridValuesMatrix, which contains
information for assigning values from the range to each of the grid points.

                                      Fig.6 - Grid types

Grid is not an abstract class: an instance of Grid need not be an instance of any of its
subclasses. The partitions indicate that an instance of the subclass GridValuesMatrix may
be, at the same time, an instance of either the subclass RectifiedGrid or of the subclass

GridEnvelope is a data type that provides the grid coordinate values for the diametrically
opposed corners of the Grid. It has two attributes, low and high.

GridPoint is the class that represents the intersections of the grid lines.

GridCoordinate is a data type for holding the grid coordinates of a GridPoint.
A GridCell is delineated by the grid lines of Grid. Its corners are associated with the
GridPoints at the intersections of the grid lines that bound it.

A Footprint is the sample space of a grid in an external coordinate reference system.

A rectified grid shall be defined by an origin in an external coordinate reference system,
and a set of offset vectors that specify the direction and distance between the grid lines
within that external coordinate reference system. The class RectifiedGrid contains the
additional geometric characteristics of a rectified grid.

4. Discrete grid point coverage profile
Referring to the previous schemas, it is noticeably that there exists several possible
solutions to describe and formalize discrete grid point coverage domains:
    1) Implementing a Grid object and its related GridPointValuePair objects (see Fig.
        4): useful to model either regularly or quasi-regularly spaced domains.
    2) Implementing a Grid object (see Fig. 4), its associated GridPoint objects (see Fig.
        5) and its valuation GridValueMatrix object: useful to model either regularly or
        quasi-regularly spaced domains.
    3) Implementing a RectifiedGrid object (see Fig. 6) and its valuation
        GridValueMatrix object: useful to model only regularly spaced domains.

We decided to model only regularly spaced domains, following the third solution.
Therefore, a specific DiscreteGridPointCoverage profile was conceived. The profile
model is shown in the following Figure.
 DiscreteGridPointCov erageProf ile model

                      << Abstract >>                      << metaclass >>                                                    << metaclass >>
                         SC_CRS                           GF_FeatureT yp e                                                     RecordType

                                                                                                          +ty peName:Ty peName
                                                                                                          +attributeTy pes:Dictionary <AttributeName, Ty peName>
                      + CRS
                                                << instantiates >>                                                   + recordTy pe

                                                                                                                    RecordTy pe
                                            *                << Ty pe >>

                Coordinate Ref erence Sy stem     CV_DiscreteGridPointCoverage                                                     *   + record
                                                +domainExtent:EX_Extent [1..*]
                                                +rangeTy pe:RecordTy pe                                                        Record
                                                +commonPointRule:CommonPointRule                              +attributes:Dctionary <AttributeName, Any >

                                                      + ev aluator   0..1

                                                                                                           AttributeName                             TypeName
                << DataTy pe>>
               CV_GridEnvelo pe                    PointFunction                                       +aName:String                              +aName:String
                                                                                                       +attributeTy pe:Ty peName
                                                                     + v alueAssignment
                                                                                                                         << Ty pe >>
                                                              << Ty pe >>
               << DataTy pe >>                                                                                       CV_Rectified Grid
                                                         CV_GridValu eMatrix
             CV_GridCoordinates                                                                           +dimension:int
                                                 +v alues:Sequencee<Record>
       +coordValues :Sequence<Integer>                                                    v aluation      +axisNames:Sequence<CharacterString>
                                                                                                          +extent:CV_GridEnv elope
                                                                                                          +of festVectorsSequence<Vector>

                              Fig. 7 – Discrete grid point coverage profile model

5. The CF-netCDF profile for generating coverages
In order to generate coverages from CF-netCDF datasets, it is important to recognize the
minimum set of metadata elements which are mandatory to enable the mapping process.
Thus, a profile of the CF-netCDF model is introduced. The following Figure shows the
coverage profile of the CF-netCDF data model. The schema depicts the concepts that are
considered in the profile.
CF-netCDFProf ileModel

                                                                                        -Conv entions:String=CF-1.0
                         -Conv entions:String
                                                                                        -ref erence:String

                                                           local attributes
                                                           ov erride global ones
                     *                     *
        Dimension                                   Variable                            -institution:String
                                                -shape:Dimension[]                      -source:String
                                                                                        -ref erences:String
                                                                                        -long_name :String

    { shape->size = 1}

    - same name as related
    - numeric v alues
    - monotonic



    Identif ied either v ia:                       -axis:X|Y |Z| T
    - units (length, pressure, etc.)
    - positiv e attribute
                                                                                                                                units as def ined in
                                                                                                                                Udunits package

                                  Vertical Coordin ate               LatLonCoordinate             TimeCoordinate
                                  -units:String                                              -calendar:String
                                  -positiv e:up|down                                         -month_lengths:String
                                  -f ormula_terms:String                                     -leap_y ear:int

                                         Fig. 8 - CF-netCDF profile data model
The simplification rationale is briefly described, reporting the CF conventions features
which are not considered in the present profile:
    GridMappingVariable and grid_mapping attribute – used to accommodate dataset
       that are geolocated through Projected CRS. The feature has been left to future
    ClimatologyVariable and ClimatologicalTimeCoordinate – used to express time
       intervals and support climatological statistics. The features have been left to
       future steps;
    BoundaryVariable, bounds, cell_measures and cell_methods attributes – used to
       express data representatives of cells/region instead of point values. The features
       have been left to future steps;
    AuxiliaryCoordinateVariable and coordinates attribute – used to accommodate
       slanted/compressed grids or non-numeric coordinate axis. The features have been
       left to future steps;
    ScalarCoordinateVariable and compress attribute – used for performance
       optimization. The features may be skipped, without loss of generality for the
       mapping, being strictly related to encoding;
    Scale_factor and add_offset attributes – used for data packing. The features may
       be skipped, without loss of generality for the mapping, being strictly related to

6. Mapping rules
This paragraph specifies the mapping from the CF-netCDF profile model to the
DiscreteGridPointCoverage profile model. The following Figure depicts a first high-level
concepts mapping.
CF complete Class Diagram

                                                                                          -Conv entions:String=CF-1.0
                           -Conv entions:String
                                                                                          -ref erence:String

                                                             local attributes
                                                             ov erride global ones
                       *                     *
          Dimension                                   Variable                            -institution:String
                                                  -shape:Dimension[]                      -source:String                                                 DiscreteGridPointCov erageProf ile model
                                                                                          -ref erences:String
                                                                                          -long_name :String                                                                  << Abstract >>                      << metaclass >>                                                    << metaclass >>
                                                                                          -standard_name:String                                                                  SC_CRS                           GF_FeatureT yp e                                                     RecordType

                                                                                                                                                                                                                                                                  +ty peName:Ty peName
                                                                                                                                                                                                                                                                  +attributeTy pes:Dictionary <AttributeName, Ty peName>
                                                                                                                                                                              + CRS
      { shape->size = 1}                                                                                                                                                                                                                                                     + recordTy pe
                                                                                                                                                                                                        << instantiates >>

                                                                                                                                                                                       1…n                                                                                  RecordTy pe
                                                                                                                                                                                                    *                << Ty pe >>

                                                                                                                                                                        Coordinate Ref erence Sy stem     CV_DiscreteGridPointCoverage
                                                                                                                                                                                                        +domainExtent:EX_Extent [1..*]
                                                                                                                                                                                                                                                  0…1                                      *   + record

                                                                                      coordinates                                                                                                       +rangeTy pe:RecordTy pe                                                        Record
                                                                                                    *                                                                                                   +commonPointRule:CommonPointRule                              +attributes:Dctionary <AttributeName, Any >
      - same name as related
                                                                                                        Coordinate                                                                                            + ev aluator   0..1
      - numeric v alues
      - monotonic
                                                                                                                                                                        << DataTy pe>>
                                                                                                                                                                                                                                          0…1                      AttributeName                             TypeName

                                                                                                                                                                       CV_GridEnvelo pe                    PointFunction                                       +aName:String                              +aName:String
                                                                                                                                                                                                                                                               +attributeTy pe:Ty peName
                                                                                                                        DimensionalQuantity                        +high:CV_GridCoordinates
                                                                                                                        -units:String                                                                                        + v alueAssignment
                                                                                                                                                                                                                                                                                 << Ty pe >>
                                                     CF-CoordinateVariable                                                                                                                                            << Ty pe >>
                                                                                                                                                                       << DataTy pe >>                                                                                       CV_Rectified Grid
                                                                                                                                                                                                                 CV_GridValu eMatrix
      Identif ied either v ia:                       -axis:X|Y |Z| T                                                                                                 CV_GridCoordinates                                                                           +dimension:int
      - units (length, pressure, etc.)                                                                                                                                                                   +v alues:Sequencee<Record>
                                                                                                                                                               +coordValues :Sequence<Integer>                                                    v aluation      +axisNames:Sequence<CharacterString>
      - positiv e attribute                                                                                                                                                                              +sequencingRule:CV_SequenceRule
                                                                                                                                                                                                                                                                  +extent:CV_GridEnv elope
                                                                                                                                  units as def ined in                                                   +startSequence:CV_GridCoordinates
                                                                                                                                  Udunits package                                                                                                                 +origin:DirectPosition
                                                                                                                                                                                                                                                                  +of festVectorsSequence<Vector>

                                    Vertical Coordin ate               LatLonCoordinate             TimeCoordinate
                                    -units:String                                              -calendar:String
                                    -positiv e:up|down                                         -month_lengths:String
                                    -f ormula_terms:String                                     -leap_y ear:int

   a CF-netCDF dataset may originate more than one DiscreteGridPointCoverage,
     since it may contain (groups of) variables with different shapes (e.g. lat-lon, lat-
     lon-time, lat-lon-depth, etc.);
   only spatial and temporal coordinates becomes part of the coverage domain,
     whereas other dimensions are mapped to compound range sets;
   in general, variables are mapped to range set components.

A detailed and formalized description of the mapping is provided by means of the
following assertions and rules will be added:

---Formal mapping description---

7. Dimensions order issue
Consider the slides presented in Bonn; they were uploaded in the GALEON website (03-

Additional descriptions of the issues relating to the order of dimensions were presented at
the OGC Technical Committee meeting in November 2005 in Bonn.
8. Open issues and future work
To extend the profile and model projected domains.

To extend the profile and model quasi-regularly spaced domains.

To extend the profile and model multi-point domains.

      Proposed CF-netCDF WCS Encoding Profile
      List of URLs for netCDF and CF Conventions Documents
      Alternative forms for rendering netCDF metadata and data
      ISO/TC 211, ISO/PDTS 19103 Geographic information — Conceptual Schema
       Language, ISO/PDTS 19103:2003.
      ISO/TC 211, ISO/FDIS 19123 Geographic information — Schema for coverage
       geometry and functions, ISO/FDIS 19123:2005(E).
      UNIDATA, “NetCDF”, available at:
      BADC, “CF Convention”, available at:

Shared By: