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@gfdl.gov) 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