[CF-metadata] Encoding Errors on variables in CF

From: Jonathan Gregory <jonathan.gregory>
Date: Thu, 17 Apr 2003 09:36:18 +0100

Dear All

Despite all the discussion of (2), I forgot to include the standard_name in
John's example! Sorry.

(1) Point from a variable to its associated ancillary data variables (error
variables, data quality variables and others not yet thought of) through a
blank-separated list of variable names in a ancillary_variables attribute. Be
aware this link might get broken.

(2) Give an ancillary variable a standard_name which is constructed by adding
the prefix of "ancillary_data_for_" to the standard_name of its parent variable.
The ancillary variable should also have copies of all the other attributes of
its parent variable, so that it is fully self-describing.

(3) Give it also an intent attribute with a standardised value to define the
kind of ancillary data, and other attributes such as error_multiplier if
required to be precise.

(4) Use attributes flag_values and flag_meanings to provide interpretations of
ancillary variables containing flag data.

John's new example now looks like this:

  float wind_direction_uv(time, wind_depth, lat, lon) ;
    wind_direction_uv:standard_name = "wind_from_direction" ;
    wind_direction_uv:ancillary_variables=
      "wind_direction_uv_stddev wdir_uv_qc";
    wind_direction_uv:units="degree";
  float wind_direction_uv_stddev(time, wind_depth, lat, lon) ;
    wind_direction_uv_stddev:intent = "standard_error" ;
    wind_direction_uv_stddev:standard_name=
      "ancillary_data_for_wind_from_direction";
    wind_direction_uv_stddev:units="degree";
  byte wdir_uv_qc(time, wind_depth, lat, lon) ;
    wdir_uv_qc:intent = "data_quality" ;
    wdir_uv_qc:standard_name="ancillary_data_for_wind_from_direction";
    wdir_uv_qc:flag_values = 0b, 1b; 2b ;
    wdir_uv_qc:flag_values = "quality_good out_of_range sensor_nonfunctional" ;
    wdir_uv_qc:units="1";

The two ancillary variables have the same standard name but different units
(I have added the units to the example). This is the problem I was describing:
it would mean we couldn't state canonical units for these standard names.

My tentative suggestion is that we revert to putting the intent information
into the standard_name, but "ready-parsed", in order to indicate that it is
a standard_name with a qualification. Only the standard_name part of it would
have to appear in the standard_name table, and it could then have canonical
units as usual. The standard name table would therefore not get any bigger.
The intent part of it would have an implication for the units, just like the
cell_methods does.

In this example, the standard names would become something like:

    wind_direction_uv:standard_name = "wind_from_direction" ; // unchanged
    wind_direction_uv_stddev:standard_name="wind_from_direction standard_error";
    wdir_uv_qc:standard_name="wind_from_direction data_quality";

and we would tabulate e.g. in an appendix, that "standard_error" does not
affect the units, while "data_quality" implies a dimensionless quantity.

Any use?

Jonathan
Received on Thu Apr 17 2003 - 02:36:18 BST