[CF-metadata] CF-1.6 Conformance Requirements/Recommendations

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 28 Mar 2012 15:51:31 +0100

Dear Jim

> The only thing that designates a variable as an auxiliary coordinate
> variable is the presence of the variable name in a coordinates attribute on
> another variable.

Formally, that is right. By definition, a CF aux coord var is one which is
named by a coordinates attribute. The *purpose* of aux coord vars, like
1D coord vars, is to provide independent variables of which the data is a
dependent variable. Usually, these independent variables are spatial location.
There is no other formal distinction among variables in the file which
have the same dimensions as our data variable. For instance temperature(y,x),
latitude(y,x) and precipitation(y,x) all look formally similar. However, we
don't list precipitation as an aux coord var in the coordinates attribute of
the temperature data variable because it does not locate the temperature data.

Therefore if we decide to impose restrictions on aux coord vars, it relates to
whether they serve their purpose of locating the data (or providing other
non-spatiotemporal variables of which the data is a function).

> Can someone provide a real-world example of why allowing auxiliary
> coordinate variables to deviate from the true coordinate variable
> restrictions poses a problem great enough that it should be forbidden?

If a variable is listed as an aux coord var, it is very likely than a generic
application will use it to locate the data on a plot, or to calculate some
other derived quantity from it, for instance differentiating or integrating it.
This is what you generally expect to do with coordinates. If there is missing
data in it, it won't serve the purpose. That will be a problem. The question
is whether it's great enough a problem for us not to permit it. How many
applications would be broken by this problem?

It is not a problem if the data is also missing where the aux coord var is
missing, however.

Best wishes

Jonathan
Received on Wed Mar 28 2012 - 08:51:31 BST