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