Hi Steve-
It seems that we are in very good agreement in principle by
recommending the "referential attributes" approach. It's nice to have
someone with a better mathematical background explain to us that what
we are debating does, indeed, have some roots in theory :-)...
The only remaining heartburn I have is with the implementation you and
John Caron seem to come back to. I addressed this in my previous
mail, but let me briefly mention it again....In your example:
> dimensions:
> i = 5;
> j = 6;
>
> variables:
> float temp(i,j);
> temp:coordinates = "lat, lon";
> float lat(i,j);
> float lon(i,j);
there is nothing to tell an application whether the contents of "lat"
should be used as coordinates along the i-dimension of "temp" or the
j-dimension. In addition, it introduces another attribute when it's not
necessary. Isn't this cleaner and less ambiguous:
dimensions:
i = 5;
j = 6;
variables:
float temp(i,j);
temp:i = "lat";
temp:j = "lon";
float lat(i,j);
float lon(i,j);
However, you have introduced something new with your second example:
> dimensions:
> s = 100;
>
> variables:
> float temp(s); // temperature along spiral
> temp:coordinates = "z, rho, theta";
> // cylindrical coordinate system (CCS)
> float rho(s); // distance from CCS center axis
> float theta(s); // CCS azimuth
> float z(s); // CCS height
First, I would restate this example like so:
> dimensions:
> s = 100;
>
> variables:
> float temp(s); // temperature along spiral
> temp:s = "z, rho, theta";
> // cylindrical coordinate system (CCS)
> float rho(s); // distance from CCS center axis
> float theta(s); // CCS azimuth
> float z(s); // CCS height
so that the rule about interpreting referential attributes (same name
as a dimension) continues to work.
BUT, I think the *new* problem you raise here (please forgive my poor
memory if it has been mentioned before) is that we have been too
geo-centric. Now, maybe we can be forgiven since most of us are
probably earth scientists anyway. I think we need a way to specify the
coordinate system for which the ancillary coordinates apply (spherical,
Cartesian, cylindrical,...). A generic application needs to know that
"rho", "theta", and "z" are not lat-lon-z, or x-y-z. Suppose some one
instead used the names "coord1", coord2", and "coord3"? We'd have no
idea!
I think part of what John Caron was getting at with his proposal had to
do with this. Perhaps he was suggesting that part of his proposed
"coordinates_xy" and "coordinates_latlon" attributes contained the
substring necessary to infer this. I don't particularly like this
implementation - in this case, i *would* I'd prefer to add a new
attribute like "coord_system".
Or maybe we should just punt on this and stay geocentric {:-)?
BTW, I agree with your list of conditions for expanding the conventions
regarding coordinate variables. It always seems like a good idea to
"first, do no harm".
John
(jps@xxxxxxxx)
Geophysical Fluid Dynamics Laboratory/NOAA
Princeton University/Forrestal Campus/Rte. 1
P.O. Box 308
Princeton, NJ, USA 08542
