Russ (and everyone else, too):
Boy, it's starting to get tiring keeping up with everything going on
here! Still, it's heartening to see that people are as involved as
they are...
> > "From a purely mathematical (and esthetic) point of view, we also find
> > the implied statement that d1, for example, depends on things other than
> > d1, is confusing and illogical. There is a real temptation here to
> > confuse the role of data dimensions and coordinates."
>
> I'll yield to the temptation, because I think it's useful to extend the
> notion of a coordinate to serve as "the value associated with a data
> dimension index" in a way that preserves a crucial property of
> coordinates: a coordinate value uniquely determines the index of its
> associated dimension. I think it would be desirable to extend "value"
> in the above definition to include text strings or tuples with a fixed
> number of components.
Don't yield yet! I am still of the opinion (and it seems John Caron is
also starting to think this way, too) that "main coordinate variables"
ought to be 1-D. There will be cases where the "real" coordinates are
simply not representable in 1-D, in which case the main coordinate
variable could just be "1,2,3,...". What we really need are
well-defined *mechanisms* for specifying just what those "real"
coordinates are. In fact, there may be *several* "real" coordinates
(eg, the vertical position of point in a sigma-coordinate model could
be expressed as height, pressure, potential temperature,...). This
way, generic applications could treat the data as simply or as
completely as it wanted. (ie, apps like NCVIEW and Freud will still
work!)
I think your example will still work in this context:
> For example, a "time" dimension might have three associated coordinate
> variables:
>
> dimensions:
> time = UNLIMITED;
> ...
> variables:
> int year(time);
> int day_of_year(time);
> float second_of_day(time);
> ... [many other variables that use the time dimension]
>
> where a (year, day_of_year, second_of_day) tuple uniquely determines the
> time dimension index.
A generic application will, as an initial guess, set up the "time" axis
coordinates to be "1,2,3,...". A more sophisticated application could
make use of "year", "day of year", and "second_of_day", but only if
there is something to tell it about the association.
However, I have a feeling that the first step that a lot of existing
applications take is to look for a 1-D main coordinate variable from
which to retrieve more useful coordinates. I'm afraid they'll choke if
they see a 2-D coordinate variable like that in your 3rd option:
> 3. A multidimensional time coordinate variable, but now all its values
> have to be of the same type, e.g. float:
>
> variables:
> ...
> float time(time,3);
> time:components = "year day_of_year second_of_day"
> // no good way to include units for components
Who's going to back and recode all those apps? (I know that Freud
has no funding, despite its usefulness...)
Also, the 3 variables you use in your examples have the potential to
a) be constant for some stretch of point, and b) cycle around and
repeat. A "modulo" attribute would be useful (though not essential).
Something like the "wrt" attribute proposed by Gregory, Drach, and Tett
could be useful here, too, if the "days" and "seconds" follow a fixed
pattern.
BUT, I am still left wondering what is wrong with the "referential
attributes" approach as proposed years ago:
dimensions:
time = UNLIMITED;
...
variables:
int time(time); // "1,2,3,..."; a place to hang attributes
time:time="year, day_of_year, second_of_day"
int year(time);
int day_of_year(time);
float second_of_day(time);
You don't *need* a new attribute, global or variable-based.
(Of course, your application will need the same smarts as any other
method to make use of it.)
John P. Sheldon
(jps@xxxxxxxx)
Geophysical Fluid Dynamics Laboratory/NOAA
Princeton University/Forrestal Campus/Rte. 1
P.O. Box 308
Princeton, NJ, USA 08542
(609) 987-5053 office
(609) 987-5063 fax
