Re: Coordinate Systems Proposals

John Sheldon (jps@gfdl.gov)
Fri, 11 Jul 1997 16:35:40 -0400 (EDT) 

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