= 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 ~~strikethrough~~ to indicate text suggested to remove and __underline__ for text suggested to be added.
== Types ==
* !ScalarField:
* a defined scalar phenomenon with a multi-dimensional 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.~~
* !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 numerical~~
* ~~a 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 [http://www.met.reading.ac.uk/~jonathan/CF_metadata/cfdm.html CF data model] proposed in [https://cf-pcmdi.llnl.gov/trac/ticket/68 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.
!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 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_mapping`s (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.
* 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 !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
* 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 !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.
* !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 latitude-longitude system.
* !CellMethod:
* The values in the !ScalarField 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.