[CF-metadata] scalar coordinates

From: Jonathan Gregory <j.m.gregory>
Date: Tue, 21 May 2013 18:37:21 +0100

Dear Mark

As when we have discussed this before, I am certain that when we introduced
scalar coordinate variables, we intended them to mean the same thing as
size-one coordinate variables. Though I do not remember the actual discussions
I am sure that's what we had in mind, and it is quite likely that it was me
who drafted the words currently in the document with that intention.

I agree that subsequently the introduction of string-valued scalar coordinate
variables muddied the picture. Again it was probably me who drafted the words
and I'm sorry those words are a bit careless and not clearer. However, I am
sure, again, this was intended as a convenience feature, not intended to imply
any new sort of information. For example, if you want to label a geographical
region with a string-valued coordinate of region, having value atlantic_ocean
for example, this must be an auxiliary coordinate variable, because it is
string-valued. The idea is that

  basin=1;
  maxlength=30;
  float sf(basin,depth,latitude);
    sf:standard_name="ocean_meridional_overturning_streamfunction";
    sf:units="1e6 m3 s-1";
    sf:coordinates="basinname";
  char basinname(basin,maxlength);
    basinname:standard_name="region";

can be more conveniently encoded as

  maxlength=30;
  float sf(depth,latitude);
    sf:standard_name="ocean_meridional_overturning_streamfunction";
    sf:units="1e6 m3 s-1";
    sf:coordinates="basinname";
  char basinname(maxlength);
    basinname:standard_name="region";

which fairly obviously means the same thing, I would say, so it is reasonable
to regard basinname as an auxiliary coordinate variable of a size-one dimension
which has been omitted for convenience. I didn't write this down in my last
posting, for the sake of simplicity.

You argue that because the words are unclear people have made use of the
flexibility to introduce scalar coordinates without deciding whether they are
functionally equivalent to (Unidata) coordinate variables or auxiliary
coordinate variables. As I argued in my last posting, I think there is an
advantage if the data-writer indicates the association between these size-one
coordinates, if there is one, by using a size-one dimension. However, the
data-writer may choose not to do so, and that's fine. In that case, the
data-writer has decided to omit some potentially useful information.

My interpretation, if there are n scalar coordinates, is that they imply n
independent dimensions. However, it seems to me that it is no big deal, when
you read the file, to decide you don't like that interpretation, and instead
group them in some way of your choice into m (Unidata) coordinate variables
and p auxiliary coordinate variables, with m+p=n. This will not affect the
data, so it is easy to do.

The difference between our points of view is this, as far as I understand:

* I think there are (Unidata) coordinate variables, and auxiliary coordinate
variables, and scalar coordinate variables are a way to encode these without
defining a netCDF dimension of size one.

* You think that scalar coordinate variables are in a third class of their own.

We agree that it makes no difference to the data. It's just a matter of
interpretation. I favour my interpretation because it has one fewer abstract
concept (so it is simpler), and because I think it is the most obvious
interpretation of what the standard means by saying scalar coordinates are
functionally equivalent to size-one coordinates (as well as being certain that
is what the standard was *intended* to mean, when the words were written).

Best wishes

Jonathan
Received on Tue May 21 2013 - 11:37:21 BST