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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
