I'll agree with option A.
I can think of a number of cases where scalar coordinate variables
are a convenient way to record metadata about the positioning
of the data in space-time, but it's not like the data at other
positions actually exists and isn't recorded in this file; it's just a
way of formatting the metadata. Which makes it a bit weird to
insist that there's always a degenerate dimension associated
with the scalar coordinate.
Consider surface observations. A scalar coordinate is a sensible
way to record e.g. the height of the observation (2-m screen
height for temps & humidity vs 10-m anemometer height for winds),
but it's not as if there's an entire spectrum of different heights
for the observations that you're sampling from; those heights are
the only ones that there were or ever will be.
So I can't see any utility in requiring the height to be treated as a
dimension in that case. But there is some potential disutility, in that
if you've got software that slices and dices the data along different
dimensions, adding in a degenerate dimension for the height is
likely to just clutter things up and confuse the issue.
Cheers,
--Seth
On Fri, 10 May 2013 08:56:40 +0000
"Hattersley, Richard" <richard.hattersley at metoffice.gov.uk> wrote:
>Perhaps it might be helpful to add some context, i.e. "Why do I care?"
>
>My understanding is, Jonathan Gregory and Mark Hedley intended to
>resolve this ambiguity in a subsequent revision of CF. And that
>resolution will have an impact on both data producers and data
>consumers.
>
>As a data producer you might care because you're producing data which
>will become invalid. As a data consumer you might find that software
>tools interpret data differently, and hence you might have to change
>your code.
>
>
>> The question is this: "Does a Scalar Coordinate Variable....":
>>
>> Option A: Represent either a Coordinate Variable or an Auxiliary
>> Coordinate? The presence of a scalar does not mandate the existence of
>> a new dimension; it can imply an undeclared dimension of size one
>> that is not explicitly defined in the file but it does not have to.
>>
>> Or
>>
>> Option B: Always represent a Coordinate variable which explicitly
>> declares a dimension of size one, where this dimension is not stated
>> in the file? An exception is provided for string scalar coordinate
>> variables only, which are defined as Auxiliary Coordinates but also
>> mandate a new dimension of size one.
>
>It seems the difference hinges around the concept of "degrees of
>freedom". In those terms...
>
>Option A lets the data producer say, "Here are some scalar pieces of
>metadata - data consumers can choose what to do with them."
>
>Whereas option B implies, "These are the degrees of freedom - no more,
>no less."
>
>
>One impact of this is in the overdetermined case of time,
>forecast_reference_time, and forecast_period. Even when a data variable
>contains data for a single point in time, option B would require the
>*producer* to decide which two variables describe the two degrees of
>freedom, and which variable is the dependent variable.
>
>But as a consumer I might choose to aggregate a collection of these
>single-time-point data variables which are best parameterised by a
>*different* pair of time, forecast_reference_time, or forecast_period.
>In general, it's not possible for the data producer to know in advance
>which two variables best parameterise the collection I'm interested in.
>
>
>For this, and other related reasons involving ensembles, I'm in favour
>of option A.
>
>
>Richard Hattersley
>Iris Benevolent Dictator
>Met Office
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri May 10 2013 - 08:20:07 BST
