Re: Coordinate Systems Proposals

John Sheldon (jps@gfdl.gov)
Wed, 9 Jul 1997 14:46:52 -0400 (EDT)

Hi John-

> 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.

I have to admit that I'm probably missing some more theoretical point
in your last mail, but I'm not so sure we can't do something...

A simple example, first where the coordinate info is attached to a
specific data variable:

  dimensions:
        lon = 6 ;
        lat = 5 ;
	height = 30;

  variables:
        float TEMP(height, lat, lon) ;
	      TEMP:lon="lon_coords" ;
	      TEMP:lat="lat_coords" ;
	float lon_coords(lat,lon) ;
	float lat_coords(lat,lon) ;


Suppose we want to plot/analyze/examine/etc. variable "TEMP".  We
immediately see it is a 6x5x3 array of values.  Then, we want to find
out more about the coordinates corresponding to the datapoints of
"TEMP".  There are no variables "lon" and "lat", so we simply take the
coordinates to be "1,2,3,..." along each axis.

So what else can we deduce?  The rule for referential attributes is
that when there is a variable attribute by the same name as one of the
variable's dimensions, that attribute contains the name(s) of other
variables from which to get spatio-temporal coordinates for that
dimension.  In this case, the longitudes can be obtained from variable
"lon_coords".  When we go to look at "lon_coords", we see that it is
2-D, so we match up which dimensions it has in common with TEMP.  This
tells us that the longitudes for TEMP(*,j,i) are in lon_coords(j,i).
Likewise for latitudes.

It should be obvious that the usual 1-D coordinate variables are a
simpler case of this, and that "lon_coords" could even be 3-D if that
was needed, but that could get complicated. (I'll try to come up with
an example...)

I think that a logical extension of this would be to attach the
referential attributes to some bogus "lon" and "lat" coordinate
variables:

        long lon(lon) ;
	     lon:lon="lon_coords(lat,lon)" ;
        long lat(lat) ;
	     lat:lat="lat_coords(lat,lon)" ;

Variables "lon" and "lat" simply contain "1,2,3,..." - not much
information there, but it does give us something on which to hang
attributes. Then, any variable employing "lat" and/or "lon" would have
available the "real" coordinates stored in "lon_coords" and
"lat_coords".

See any holes in this?

John

(jps@gfdl.gov) 
Geophysical Fluid Dynamics Laboratory/NOAA 
Princeton University/Forrestal Campus/Rte. 1 
P.O. Box 308 
Princeton, NJ, USA  08542

(609) 987-5053 office
(609) 987-5063 fax