⇐ ⇒

[CF-metadata] scalar coordinates

From: Hedley, Mark <mark.hedley>
Date: Fri, 24 May 2013 08:23:19 +0000

Hello Nan

Thank you for identifying where I am not being clear, I will try to clarify.

> First, what do you mean by the ordering of dimensions of size 1?

I am referring to the definition of a data variable, which defines the ordering of it's dimensions. If dimensions of length 1 are defined, then the data variable defines the order they appear in in the data array:

If scalar coordinates are used then there are no dimensions in the file for these coordinates so the data variable does not have to define an order

> And, can you please elaborate on the last sentence - is the goal to indicate that there's a relationship between sets of scalar coordinates that represent the same axis?

My goal is to ensure that scalar coordinates do not define the relationships that exist between them. It has been suggested that by defining a number of scalar coordinates the data creator is also defining that these coordinates are independent of each other. I would like to guard against this assertion, I don't think scalar coordinatess should do this.

> Don't we provide that by using the 'axis' attribute? Is there some other rationale for this?

I think Chapter 4 limits the axis attribute to being used on one and only one coordinate variable per value and data variable.

   'The attribute axis may be attached to a coordinate variable and given one of the values X, Y, Z or T which stand for a longitude, latitude, vertical, or time axis respectively.'

If this is the case, we cannot use axis to identify multiple scalar coordinates linking to one degree of freedom. Additionally, axis labels for non-x|y|z|t axes are not supported, as far as I can see, so issue such as unspecified degrees of freedom related to multi-model data sets are not supported by this.

I hope this helps, not hinders, understanding of my perspective

mark

________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Nan Galbraith [ngalbraith at whoi.edu]
Sent: 23 May 2013 13:48
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] scalar coordinates

Scalar coordinates are not just a convenience, they are the clearest way to locate
the data in time and space, in some cases - as the CF document (5.7) says, sometimes
'there is no associated dimension.'

I'm truly confused by Mark's statement:
 'Scalar coordinate variables have the same information content and can be used in the same contexts as a size one coordinate variable.'

But this statement is not quite true: the ordering of dimensions is not encoded, and the ability to link many coordinates to the same dimension is lost. The assumption in this statement is an aspiration which I think cannot be delivered without particularly strict limitations on the use of scalars during encoding.

Nowhere in the conventions does it state that if more than one single-valued coordinate is related to the same degree of freedom, a dimension must be declared for these and this relationship explicitly encoded.

First, what do you mean by the ordering of dimensions of size 1?

And, can you please elaborate on the last sentence - is the goal to indicate that there's
a relationship between sets of scalar coordinates that represent the same axis? Don't we
provide that by using the 'axis' attribute? Is there some other rationale for this?

For our meteorology time series data, we have singleton latitude and longitude, unlimited
time, and numerous sensor heights. We provide time as a dimension and the others as
scalar coordinates. I don't think we would gain clarity by creating a height dimension
for each instrument's Z position. Our data is really a 1 dimensional array where the
Z coordinate is slightly different for each variable, and that's what we code it as.

Cheers - Nan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130524/47f70af6/attachment.html>
Received on Fri May 24 2013 - 02:23:19 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒