> >
> > "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.
>
> 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. In this case, there is no single coordinate
> variable corresponding to the time dimension, but instead, a 3-tuple
> that serves as the time coordinate. This relation could be represented
> using any one of several proposed conventions:
>
> 1. A scalar "time" variable with a "coordinates" attribute:
>
> variables:
> ...
> int time; // a scalar on which to hang attributes for time dimension
> time:coordinates = "year day_of_year second_of_day";
>
> 2. A global "dimension attribute":
>
> :time = "year day_of_year second_of_day";
>
> 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
>
> I know the above example doesn't follow any approved conventions for
> handling time, and I don't want to start another discussion of how to
> handle time. It's just an example to illustrate what might be possible
> with a more general notion of coordinates.
Your example here is a good one that we should make sure works in any
convention we come up with, and i'll include it in my list of examples
that we should refer proposals against. My preference would be actually
both 1 and 2, that is name the coordinate functions in an agreed upon
attribute; allow a global attribute and/or a variable attribute that
overrides the global.
I haven't really explained my point against multi-D coordinate variables
yet, but briefly its the following observation:
Consider a variable on a projection surface, and specify the
coordinates in lat, lon. Currently I favor the following:
var(x,y)
lat(x,y)
lon(x,y)
Now, the problem is that we cannot assign one coordinate function to x,
and the other to y,
eg
:x = "lon";
:y = "lat";
is simply not particularly a true statement. In general, all we can do
is specify the coordinate functions for the complete coordinate system:
:coordinates = "lat lon";
In other words, in general we can't associate the coordinate functions
with a dimension, but only with the variables. The dimensions are merely
the domains of the coordinate functions; it is the values of the
coordinate functions that are the coordinates, not the dimensional
indices, thus the warning not to "confuse the role of data dimensions
and coordinates". For (1d) coordinate variables, the "confusion" is ok,
even helpful, but it doesnt generalize.
Perhaps when I can finish my more complete formalism, this will be more
clear, or at least ready for discussion.
