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; please use unique names.
 If entries are to be edited, please use
strikethroughto indicate text suggested to remove and underline for text suggested to be added.
Types
 ScalarField:
 a defined scalar phenomenon with a multidimensional set of phenomenon values and metadata describing the phenomenon values.
 Coord
Coordinate: a defined phenomenon, providing metadata to a Field.
abstract, not to be explicitly provided by an implementation
 Coordinate (Coord)
DimensionCoordinate (Coordinate): a 1 dimensional, monotonic, numerical Coord
coordinate describing one dimension of a Field.
 a 1 dimensional, monotonic, numerical Coord
 AuxiliaryCoordinate (Coord)
(Coordinate): a Coord, owned by a Field and referenced by dimensions of that Field
a coord which does not have to be 1 dimensional, monotonic or numericala coordinate describing one or more dimensions of a Field
 !DimensionCoordinate:
 a Coordinate, owned by a Field and used by the Field to uniquely define one of its dimensions
 CoordinateRefSystem:
 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 CFnetCDF 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 multidimensional 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 onedimensional monotonic numerical coordinate array of that size, a twodimensional 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.
 CellMeasure
 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 CFnetCDF apparatus for dimensionless vertical coordinates (e.g. to compute a pressure coordinate from the sigma and pressure parts of a hybrid sigmapressure 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
 ScalarField:
 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.
 A data variable in a CF NetCDF file is an example of a Field, e.g.:
 Coordinate:
 This type does not have an example, it can be thought of as an abstract type, which provides common functionality to its tangible subtypes.
 jonathan: This type is not included in the model of ticket 68.
 DimensionCoordinate (Coordinate):
 The example ScalarField 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
 DimensionCoordinate:
 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.
 The example ScalarField may be defined with respect to a regular horizontal grid; this Field would have:
 AuxiliaryCoordinate (Coordinate):
 The example ScalarField 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.
 AuxiliaryCoordiante:
 The example ScalarField may be defined at an instant in time, with a set of height values, one for each data value; this Field would have:
 CoordinateSystem:
 The spatial Coordinates of the ScalarField 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 latitudelongitude system.
 The spatial Coordinates of the ScalarField may be defined with respect to a coordinate reference system:
 CellMethod:
 The values in the ScalarField are aggregated over time, so the Field has:
 CellMethod
 a coordinate label of 'time'
 an operator 'mean'
 CellMethod
 The values in the ScalarField are aggregated over time, so the Field has:
 CellMeasure:
 For instance,
 identifies itself as containing cell areas
 units of m2
 2D array of values (n,m) where n and m are Dimensions.
 For instance,
Attachments (3)

coord_subcf1.5.png
(36.4 KB) 
added by markh 7 years ago.
potential_coord_relation

CDMimplementationCF1.5.png
(83.3 KB) 
added by markh 7 years ago.
example of CDM implementation of CF
 coord_cf1.5.png (50.5 KB)  added by markh 7 years ago.
Download all attachments as: .zip