wiki:PotentialDataModelTypes

Version 26 (modified by jonathan, 7 years ago) (diff)

--

Potential Data Model Types

Types, or Constructs (the terms are used interchangeably here) are the data model constituents. An implementation may take these and instansiate particular Classes, Variables or similar to express the concept in the relevant way for that implementation.

For each potential candidate type:

  • a type name
  • a short description

should be provided.

Terms of Reference

  • The scope of the data model is to define the concepts of CF and the relationships that exist between these concepts.
  • The data model provides a logical, implementation neutral, abstraction of the concepts defined by CF.
  • The data model does not define the interface to CF.

Editing These Resources

  • Anyone involved in the CF community is welcome to add an entry to the 'Types' list and 'definition'.
  • Creation of new entries is preferred to editing of current entries.
  • If entries are to be edited, please use strikethrough to indicate text suggested to remove and underline for text suggested to be added and add your trac user name beside the edit.

Types

  • Field:
    • a defined phenomenon with a multi-dimensional set of phenomenon values.
  • Coordinate:
    • a defined phenomenon, providing metadata to a Field.
  • DimensionCoordinate (Coordinate):
    • a 1 dimensional, monotonic, numerical coordinate describing one dimension of a Field.
  • AuxiliaryCoordinate (Coordinate):
    • a coordinate describing one or more dimensions of a Field
  • CoordinateSystem:
    • a frame of reference which spatial coordiantes may be defined with respect to.
  • CellMethod:
    • a qualification of the phenomenon definition for a field.

The following are the constructs or types of the CF data model proposed in CF ticket 68, which aims at a minimal model, corresponding to CF-netCDF convention version 1.5. By "minimal" we mean with as few constructs as possible (jonathan):

Field
a space (defined by Dimensions, AuxiliaryCoordinates, CellMeasures and Transforms) containing data values (a scalar, one- or multi-dimensional array), described by CellMethods, metadata properties (such as standard_name and units), and ancillary Fields. All these contents are optional. For instance, the Field might just be a space with no data in it (for instance, this might be used to describe a grid), or it might be data with no coordinates (for instance, the global mean surface air temperature for an unspecified time).
Dimension
the size of a single dimension of the Field, with a one-dimensional monotonic numerical coordinate array of that size, a two-dimensional array of boundary coordinates, and metadata properties serving to describe the dimension. The size is mandatory, but the other contents are optional.
AuxiliaryCoordinate
a coordinate array having one or more dimensions of the Field, and optionally a boundary coordinate array and metadata properties.
CellMeasures
values for some metric of the space of the Field (for instance, cell areas), either a scalar or an array having one or more dimensions of the Field, with specified units and optionally with other metadata properties.
CellMethods
an ordered list of operations, applying to Dimensions of the Field or to other quantities (identified by standard_name), indicating how the data values of the Field represent variation of the quantity within cells (e.g. zonal mean, daily maximum).
Transform
functions which specify how coordinate values of the Field can be computed. A Transform identifies the function to be used, and specifies input terms for the function, which can be scalar parameters, Dimensions, AuxiliaryCoordinates of the Field, or other Fields. Transforms represent the CF-netCDF apparatus for dimensionless vertical coordinates (e.g. to compute a pressure coordinate from the sigma and pressure parts of a hybrid sigma-pressure coordinate and a surface pressure Field) and grid_mappings (e.g. to compute latitude and longitude coordinates from eastings and northings in a map projection).

Relations

A UML diagram will be displayed here when sufficient types have been agreed upon.

Examples of Types

Example 1

  • Field:
    • A data variable in a CF NetCDF file is an example of a Field, e.g.:
      • a standard name of 'specific_humidity'
      • a unit of '1'
      • a 2D array of data values, size: (n,m). jonathan: In the model of ticket 68, only the identity of the Dimensions is part of the Field, not their size.
  • Coordinate:
    • This type does not have an example, it can be thought of as an abstract type, which provides common functionality to its tangible sub-types.
    • jonathan: This type is not included in the model of ticket 68.
  • DimensionCoordinate (Coordinate):
    • The example Field may be defined with respect to a regular horizontal grid; this Field would have:
      • DimensionCoordinate:
        • a long name name of 'easting'
        • a unit of 'm'
        • a 1D array of values, size:n
      • DimensionCoordinate:
        • a long name name of 'northing'
        • a unit of 'm'
        • a 1D array of values, size:m
    • jonathan: The model of ticket 68 has a Dimension construct instead of this type; the difference is that it also contains the size of the dimension.
  • AuxiliaryCoordinate (Coordinate):
    • The example Field may be defined at an instant in time, with a set of height values, one for each data value; this Field would have:
      • AuxiliaryCoordiante:
        • a standard name of 'time'
        • a temporal unit and calendar
        • a single value
        • a pair of bounds values
      • AuxiliaryCoordinate:
        • a standard name of 'height_above_reference_ellipsoid'
        • a unit of 'm'
        • a 2D array of values, size:(n,m). jonathan: In the model of ticket 68, the AuxiliaryCoordinate identifies its dimensions, but their size is part of the Dimensions constructs concerned.
  • CoordinateSystem:
    • The spatial Coordinates of the Field may be defined with respect to a coordinate reference system:
      • a definition of the OSGB CRS
    • jonathan: This type is not included in the model of ticket 68. We argue that coordinate systems are implicitly assembled by operations which want to use them, since they know what they are interested in, and/or implied by the Transforms of the Field. For instance, a Transform describes the OSGB CRS; it's a relationship between the map projection system and the latitude-longitude system.
  • CellMethod:
    • The values in the Field are aggregated over time, so the Field has:
      • CellMethod
        • a coordinate label of 'time'
        • an operator 'mean'
  • CellMeasure:
    • For instance,
      • identifies itself as containing cell areas
      • units of m2
      • 2D array of values (n,m) where n and m are Dimensions.

Attachments (3)

Download all attachments as: .zip