Changes between Version 25 and Version 26 of PotentialDataModelTypes
 Timestamp:
 09/19/12 10:25:28 (7 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

PotentialDataModelTypes
v25 v26 34 34 * a frame of reference which spatial coordiantes may be defined with respect to. 35 35 * !CellMethod: 36 * a qualification of the phenomenon definition for a field. 36 * a qualification of the phenomenon definition for a field. 37 38 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://cfpcmdi.llnl.gov/trac/ticket/68 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): 39 40 Field:: 41 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). 42 Dimension:: 43 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. 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 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_mapping`s (e.g. to compute latitude and longitude coordinates from eastings and northings in a map projection). 37 52 38 53 == Relations == … … 48 63 * a standard name of 'specific_humidity' 49 64 * 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. 51 66 * 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 subtypes. 67 * This type does not have an example, it can be thought of as an abstract type, which provides common functionality to its tangible subtypes. 68 * jonathan: This type is not included in the model of ticket 68. 53 69 * !DimensionCoordinate (Coordinate): 54 70 * The example Field may be defined with respect to a regular horizontal grid; this Field would have: … … 61 77 * a unit of 'm' 62 78 * 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. 63 80 * !AuxiliaryCoordinate (Coordinate): 64 81 * 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: … … 68 85 * a single value 69 86 * a pair of bounds values 70 * !AuxiliaryCoordi ante:87 * !AuxiliaryCoordinate: 71 88 * a standard name of 'height_above_reference_ellipsoid' 72 89 * 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. 74 91 * !CoordinateSystem: 75 92 * The spatial Coordinates of the Field may be defined with respect to a coordinate reference system: 76 93 * 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 latitudelongitude system. 77 95 * !CellMethod: 78 96 * The values in the Field are aggregated over time, so the Field has: … … 80 98 * a coordinate label of 'time' 81 99 * 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.