NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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@gfdl.gov)
Geophysical Fluid Dynamics Laboratory/NOAA
Princeton University/Forrestal Campus/Rte. 1
P.O. Box 308
Princeton, NJ, USA 08542