wiki:markhDataModelDrafting

Version 9 (modified by markh, 5 years ago) (diff)

--

Properties

Properties recognised by the CF data model correspond to attributes listed in the CF for NetCDF files: Appendix A.

  • standard_name
  • units
  • comment
    • valid for:
      • field
  • history
    • valid for:
      • field
  • institution
    • valid for:
      • field
  • long_name
    • valid for:
      • field
      • dimension coordinate
      • auxiliary coordinate
      • cell measure
  • references
    • valid for:
      • field
  • source
    • valid for:
      • field
  • standard_error_multiplier
    • valid for:
      • field
  • title
    • valid for:
      • field
  • axis
    • In a field, a given value of the axis attribute can occur no more than once among all the dimension and auxiliary coordinates of that field.
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • calendar
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • leap_month
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • leap_year
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • month_lengths
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • positive
    • valid for:
      • dimension coordinate
      • auxiliary coordinate
  • climatology
    • valid for:
      • dimension coordinate
      • auxiliary coordinate

The attributes

  • valid_max
  • valid_min
  • valid_range

of data variables and coordinate variables are checks on the validity of the values, which could be verified on input and written on output. In this CF data model we assume they do not constrain any manipulations which might be done on the data in memory, and they are not part of the data model.

The attributes

  • _FillValue
  • missing_value

of data variables specify how missing data is indicated in the data array. This data model supports the idea of missing data, but does not depend on any particular method of indicating it, so these attributes are not part of the model. question: is this the case for coords too, auxiliary coords may contain missing data, I believe.

The attributes

  • add_offset
  • compress
  • flag_masks
  • flag_meanings
  • flag_values
  • scale_factor

are all used in methods of compressing the data to save space in CF-netCDF files, with or without loss of information. They are not part of this data model because these operations do not logically alter the data, except that the compress attribute implies two alternative interpretations of coordinates (compressed or uncompressed).

The featureType attribute and associated conventions provide a way of packing multiple fields of the same kind of discrete sampling geometry (timeseries, trajectories, etc.) into a single CF-netCDF data variable, in order to save space, since a multidimensional representation with common coordinate variables is typically very wasteful in such cases. This is a kind of compression. The data model regards each instance of the feature type as an independent field construct. The featureType attribute is a property of each of these field constructs.

The attributes:

  • bounds
  • cell_measures
  • cell_methods
  • climatology
  • Conventions
  • coordinates
  • formula_terms
  • grid_mapping

have various special or structural functions in the CF-netCDF file format. Their functions and the relationships they indicate are reflected in the structure of this data model. These attributes do not correspond to properties in the data model and should not be used ouside the context of CF-NetCDF.

The CF data model allows field, dimension and auxiliary coordinate constructs to have other properties not defined by CF, provided they do not conflict with CF. Since they are not part of the CF standard, the data model does not provide any interpretation of them. Question: can cell_measures, cell_methods use non-conflicting attributes?

CellMeasure

A CellMeasure describes a measurement or parameter for cells within a domain; one is commonly used where the defined measure is not inferable from coordinates.

A cell measure construct provides information about the size of the cells defined by an ordered list of one or more domain axes of the field. Where provided, the measure should be used in preference to calculating such a measure from other metadata.

A cell measure construct must contain:

  • A measure property, which indicates the metric of the domain it supplies (see <reference to properties>).
  • A units property, consistent with the measure property (see <reference to properties>).
  • A typed numeric array of metric values:
    • the array shape is determined by the relevant subset of the domain axes in the order listed.

A cell measure construct may contain further properties (see <reference to properties>).

CF NetCDF

In CF-netCDF files, cell measure constructs correspond to variables named by the cell_measures attribute of the data variable.