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" <[email protected]> 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 >[email protected] >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
