Changes between Version 26 and Version 27 of PotentialDataModelTypes


Ignore:
Timestamp:
09/21/12 04:07:15 (7 years ago)
Author:
markh
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PotentialDataModelTypes

    v26 v27  
    1818
    1919 * Anyone involved in the CF community is welcome to add an entry to the 'Types' list and 'definition'.
    20  * Creation of new entries is preferred to editing of current entries.
     20 * Creation of new entries is preferred to editing of current entries; please use unique names.
    2121 * If entries are to be edited, please use ~~strikethrough~~ to indicate text suggested to remove and __underline__ for text suggested to be added and add your ''trac user name'' beside the edit.
    2222
    2323== Types ==
    2424
    25  * Field:
    26   * a defined phenomenon with a multi-dimensional set of phenomenon values.
     25 * !ScalarField:
     26  * a defined scalar phenomenon with a multi-dimensional set of phenomenon values.
    2727 * Coordinate:
    2828  * a defined phenomenon, providing metadata to a Field.
     
    5959=== Example 1 ===
    6060
    61  * Field:
     61 * !ScalarField:
    6262  * A data variable in a CF NetCDF file is an example of a Field, e.g.:
    6363   * a standard name of 'specific_humidity'
     
    6868  * jonathan: This type is not included in the model of ticket 68.
    6969 * !DimensionCoordinate (Coordinate):
    70   * The example Field may be defined with respect to a regular horizontal grid; this Field would have:
     70  * The example ScalarField may be defined with respect to a regular horizontal grid; this Field would have:
    7171   * !DimensionCoordinate:
    7272    * a long name name of 'easting'
     
    7979  * 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.
    8080 * !AuxiliaryCoordinate (Coordinate):
    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:
     81  * 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:
    8282   * !AuxiliaryCoordiante:
    8383    * a standard name of 'time'
     
    9090    * 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.
    9191 * !CoordinateSystem:
    92   * The spatial Coordinates of the Field may be defined with respect to a coordinate reference system:
     92  * The spatial Coordinates of the ScalarField may be defined with respect to a coordinate reference system:
    9393   * a definition of the OSGB CRS
    9494  * 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.
    9595 * !CellMethod:
    96   * The values in the Field are aggregated over time, so the Field has:
     96  * The values in the ScalarField are aggregated over time, so the Field has:
    9797   * !CellMethod
    9898    * a coordinate label of 'time'