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
On 5/21/13 7:22 AM, Kenneth S. Casey - NOAA Federal wrote:
> Hi Everyone,
>
> After spending 15 minutes reading this and Jonathan's previous post,
> and trying hard to be sure I really understand them, I am left
> wondering if a "convenience feature" is really a convenience at all.
> I know programmers don't like clutter in their code and have certain
> aesthetic to uphold (I used to do much more serious programming in my
> younger days, but am now just a lazy Matlaber), but is the added
> complexity of having these two options, copied from Jonathan's post:
>
> float height; // scalar coordinate variable
> height: standard_name="height";
> float temp(lat,lon);
> temp: standard_name="air_temperature";
> temp: coordinates="height";
>
> float height(height); // size-one coordinate var, with dimension
> height=1
> height: standard_name="height";
> float temp(height,lat,lon);
> temp: standard_name="air_temperature";
>
> really worth it? The manual must be longer to describe the
> "convenience", and the application programmers and downstream users of
> the data now have to build complexity into THEIR code to handle both
> cases. This list has to take time explaining and debating the options,
> and I have to take time explaining it to both data producers and data
> consumers who have never used netCDF or CF before. Maybe that is not
> such a big deal on a case by case basis, but in the broader picture
> when folks like me are trying to get everyone and their brothers and
> sisters and mothers and fathers using CF-netCDF, it is a real pain.
> My vote is to simplify. Use the second example, since it handles the
> case where height=1 as easily as the case where height=1000. I say be
> explicit. Does the first example gain us any functionality? If not,
> then don't use it and stay away from it. Encourage others to do the
> same.
>
> Ken
>
>
> On May 21, 2013, at 5:48 AM, "Hedley, Mark"
> <mark.hedley at metoffice.gov.uk <mailto:mark.hedley at metoffice.gov.uk>>
> wrote:
>
>> The term 'convenience feature' is mentioned in the conventions document:
>>
>> 'The new scalar coordinate variable is a convenience feature which
>> avoids adding size one dimensions to variables.'
>>
>> Data creators have seen the benefits in not encoding size one
>> dimensions and made use of this feature, it has proved very
>> convenient. The conventions go on to say:
>>
>> '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.
>>
>> Later, the case of character strings is addressed:
>>
>> 'If a character variable has only one dimension (the maximum length
>> of the string), it is regarded as a string-valued scalar coordinate
>> variable, analogous to a numeric scalar coordinate variable (see
>> Section 5.7, "Scalar Coordinate Variables") '
>>
>> which is a required feature, but the NUG only allows numerical valued
>> data arrays as Coordinate Variables, so a further section is added,
>> in the Terminology:
>>
>> 'scalar coordinate variable
>> A scalar variable that contains coordinate data. Functionally
>> equivalent to either a size one coordinate variable or a size one
>> auxiliary coordinate variable. '
>>
>> These statements together provide information on how to write files,
>> but they are limited in their assistance to file reading and
>> interpretation.
>>
>> The conventions are not clear how to, or whether to make a
>> distinction for a particular scalar coordinate: it does not say that
>> a scalar coordinate is a Coordinate Variable or an Auxiliary
>> Coordinate Variable, it says it is functionally equivalent to either
>> one or the other.
>>
>> I have read these sections to mean that by encoding a scalar
>> coordinate the data creator is not providing information about how
>> the coordinate is related to the dimensions in the file, other than
>> to say it applies to all of the cells currently in the file.
>>
>> As such, I disagree with the statement that that
>>
>> 'Scalar coordinate variables have the same information content and
>> can be used in the same contexts as a size one coordinate variable.'
>>
>> In many cases this will turn out to be a valid interpretation but it
>> is not the only one, and this nuance is a really useful feature,
>> which many data creators have benefited from.
>>
>> From one point of view, a third type of Coordinate exists in CF, the
>> Scalar Coordinate, which is neither a Coordinate Variable, nor an
>> Auxiliary Coordinate. From another point of view a Scalar Coordinate
>> is an Auxiliary Coordinates which has the potential to be an emergent
>> Coordinate Variable, if required and consistent for the data
>> consumer. (I am sure there are other useful perspectives we can
>> consider)
>>
>> We have come across many data sets from other data creators where a
>> considered reading of the data suggests that they have taken an
>> interpretation such as this as well. No distinction has been made
>> between scalars which represent a degree of freedom and scalars which
>> do not.
>>
>> The scalar coordinate is a convenient feature allowing metadata to be
>> simply encoded in a clear manner and I feel that the conventions
>> document should adapt to reflect the usage some sections of the
>> community have adopted. It is not ambiguous, it provides sufficient
>> information to work with the file and the data and metadata are well
>> specified.
>>
>> Indeed when converting from other formats (such as GRIB and BUFR) to
>> CF it is the logical way to encode the available metadata.
>>
>> I am concerned about the implications for these data sets if the
>> interpretation of scalar coordinates is tightened in a future version
>> of the conventions document to explicitly disallow this useful and
>> well used point of view. I would like to stress again Jonathan's
>> point, that all of this data is CF compliant, the question is how
>> consumers interpret the semantics of the data set.
>>
>> I think the utility of the scalar coordinate variable is
>> significantly diminished if Option B or some derivative of it is
>> pursued for the next version of the conventions. Option A preserves
>> all of the interpretations of Option B intact, but with caution
>> needed on loading and interpretation not to read too much information
>> into any scalar coordinates present.
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> Kenneth S. Casey, Ph.D.
> Technical Director
> NOAA National Oceanographic Data Center
> 1315 East-West Highway
> Silver Spring MD 20910
> 301-713-3272 x133
> http://www.nodc.noaa.gov <http://www.nodc.noaa.gov/>
>
> <https://www.facebook.com/noaa.nodc>
>
> <http://www.facebook.com/feeds/page.php?id=178512945559611&format=rss20>
> <http://www.facebook.com/feeds/page.php?id=178512945559611&format=rss20>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/8ecbb17d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 533 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/8ecbb17d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1654 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/8ecbb17d/attachment-0003.png>
Received on Thu May 23 2013 - 06:48:34 BST
