Changes between Version 25 and Version 26 of PotentialDataModelTypes


Ignore:
Timestamp:
09/19/12 10:25:28 (7 years ago)
Author:
jonathan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PotentialDataModelTypes

    v25 v26  
    3434  * a frame of reference which spatial coordiantes may be defined with respect to.
    3535 * !CellMethod:
    36   * a qualification of the phenomenon definition for a field. 
     36  * a qualification of the phenomenon definition for a field.
     37
     38The 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):
     39
     40 Field::
     41  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).
     42 Dimension::
     43  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.
     44 !AuxiliaryCoordinate::
     45  a coordinate array having one or more dimensions of the Field, and optionally a boundary coordinate array and metadata properties.
     46 !CellMeasures::
     47  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.
     48 !CellMethods::
     49  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).
     50 Transform::
     51  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).
    3752
    3853== Relations ==
     
    4863   * a standard name of 'specific_humidity'
    4964   * a unit of '1'
    50    * a 2D array of data values, size: (n,m)
     65   * 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.
    5166 * Coordinate:
    52   * This type does not have an example, it can be thought of as an abstract type, which provides common functionality to it's tangible sub-types.
     67  * 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.
     68  * jonathan: This type is not included in the model of ticket 68.
    5369 * !DimensionCoordinate (Coordinate):
    5470  * The example Field may be defined with respect to a regular horizontal grid; this Field would have:
     
    6177    * a unit of 'm'
    6278    * a 1D array of values, size:m
     79  * 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.
    6380 * !AuxiliaryCoordinate (Coordinate):
    6481  * 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:
     
    6885    * a single value
    6986    * a pair of bounds values
    70    * !AuxiliaryCoordiante:
     87   * !AuxiliaryCoordinate:
    7188    * a standard name of 'height_above_reference_ellipsoid'
    7289    * a unit of 'm'
    73     * a 2D array of values, size:(n,m) 
     90    * 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.
    7491 * !CoordinateSystem:
    7592  * The spatial Coordinates of the Field may be defined with respect to a coordinate reference system:
    7693   * a definition of the OSGB CRS
     94  * 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.
    7795 * !CellMethod:
    7896  * The values in the Field are aggregated over time, so the Field has:
     
    8098    * a coordinate label of 'time'
    8199    * an operator 'mean'
     100 * !CellMeasure:
     101  * For instance,
     102   * identifies itself as containing cell areas
     103   * units of m2
     104   * 2D array of values (n,m) where n and m are Dimensions.