[CF-metadata] CF-1.6 DSG clarification: time series & lat/lon coordinates

From: John Caron <caron>
Date: Tue, 04 Jun 2013 10:54:45 -0600

Hi Jonathan:

On 6/4/2013 4:17 AM, Jonathan Gregory wrote:
> Dear John Caron and John Maurer
>
> I agree with John C that the problem arises when the coordinate variables
> are not size one. John M's example
>
>>> float lon(lon) ;
>>> float lat(lat) ;
>>> float alt(alt) ;
>>> float temp(time, alt, lat, lon) ;
>>> temp:standard_name = ?air_temperature? ;
>>> temp:units = "Celsius" ;
>>> temp:coordinates = "time lat lon alt" ;
>>> temp:_FillValue = -999.9;
>
> with alt=lat=lon=1 is legal in CF. In fact the coordinates attribute is not
> needed, because these are all (Unidata) coordinate variables (1D, with name
> of the variable equal to the name of the dimension). Ignoring the coordinates
> attribute, this example is fine in COARDS as well. In the data model, lon lat
> alt time are all dimension coordinate constructs with separate domain axes.
>
> But when there are *two* timeseries, you would not have alt=lat=lon=2. That
> would mean three independent size-2 dimensions. This would also be legal in
> CF and COARDS, but it means timeseries at a grid of 8 points, not two points.
> To deal with this situation, we introduce an index dimension of size 2, and
> make alt lat lon auxiliary coordinate variables of this single dimension. In
> the data model, there is then only one domain axis for alt lat lon.
>
> Back to the case of one timeseries: Example H4 shows scalar coordinate
> variables for alt lat lon. That is, these size-1 dimensions have been omitted.
> In this case, the coordinates attribute is needed; that's how scalar coordinate
> variables are attached to the data variable. In the data model (in my opinion)
> this is logically equivalent including the size-1 dimensions.

Lets see, its currently not legal as a DSG file, according to the spec.
The CDM will barf on it, though I could put in a workaround.

Should it be legal? That is, should people be "allowed" to put in
extraneous dimensions that only make sense for some values of the
dimension length (eg 1 but not >1) ? I think it would be a rather ugly
wart, and you would gain no new functionality.

I also think it would confuse dimensions with coordinates (which has
already happened because the distinction isnt obvious). I think we
should try to be clear about the use of dimensions because it makes the
data model more powerful. So I would prefer not.

>
> Maybe this question raises an issue for chapter 9 and Example H4. The example
> is following Section 9.2:
>
> "If there is only a single feature to be stored in a data variable, there is no
> need for an instance dimension and it is permitted to omit it. The data will
> then be one-dimensional, which is a special (degenerate) case of the
> multidimensional array representation. The instance variables will be scalar
> coordinate variables; the data variable and other auxiliary coordinate
> variables will have only an element dimension and not have an instance
> dimension, e.g. data(o) and t(o) for a single timeSeries."
>
> In the multidimensional array representation, featureType doesn't have to be
> coded, because this representation has always existed in CF. We could say that
> *if* you encode featureType, there *must* be an instance dimension (of size 1
> if appropriate) and that alt lat lon must be auxiliary coordinate variables
> with this dimension. That would be a restriction we don't have in CF 1.6, so
> it would be a change to CF. What do you think, John C?

I think this is a seperate question yes?

 From my POV, its just a practical question to make things clear between
data producer and consumer. I think we allowed the scalar instance
coordinates because it was a natural way for producers to think when
there was only one feature in the file, ie "why do you want me to add
this extra dimension?" As long as the "featureType" attribute is
present, as well as the "coordinates" attribute I think the meaning is
unambiguous. Requiring a dimension=1 is maybe a bit simpler, but i would
still have to deal with the scalar case for versions before we change,
so its not really better for me.

John Caron
Received on Tue Jun 04 2013 - 10:54:45 BST