Version 25 (modified by markh, 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
strikethroughto 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 multidimensional 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.
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)
 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 it's tangible subtypes.
 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
 DimensionCoordinate:
 The example Field may be defined with respect to a regular horizontal grid; this Field would have:
 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
 AuxiliaryCoordiante:
 a standard name of 'height_above_reference_ellipsoid'
 a unit of 'm'
 a 2D array of values, size:(n,m)
 AuxiliaryCoordiante:
 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:
 CoordinateSystem:
 The spatial Coordinates of the Field may be defined with respect to a coordinate reference system:
 a definition of the OSGB CRS
 The spatial Coordinates of the Field may be defined with respect to a coordinate reference system:
 CellMethod:
 The values in the Field are aggregated over time, so the Field has:
 CellMethod
 a coordinate label of 'time'
 an operator 'mean'
 CellMethod
 The values in the Field are aggregated over time, so the Field has:
Attachments (3)

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

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