Hi again John-
> > 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.
>
> I think we all agree on the meaning of this example, and we are trying
> to decide on the best way to convey that meaning to an application, or a
> person reading our netcdf files who hasnt followed our discussion.
Sure, that goes without saying - regardless of the approach we take, we
need to explain the rules, and whether one needs to look for still more
attributes.
> A coordinate variable says "the variable lat is the coordinate function
> for the index lat", but in this example you cant say that,
That's correct, all they can assume at this point is that the
coordinates are 1,2,3...
> nor can you
> say "the variables lat_coords, lon_coords are the coordinate functions
> for the index lat".
Yes, I can! Again, here's the logic: TEMP employs the dimension
"lat". An attribute "lat" is attached to TEMP, so it must contain the
name of a variable from which I can get the coordinates of TEMP along
the "lat" direction.
If "lat_coords" is 1-D, all the points in a row at each level have the
same latitude.
If "lat_coords" is (lat,lon), then each point in a horizontal slab
could (potentially) have a different latitude, but there's no variation
from vertical level to vertical level.
If "lat_coords" is (height,lat,lon), then each and every point in the
entire 3-D array of TEMP could have a different latitude. Imagine
launching a 6x5 array of radiosondes. They may start out in a regular
latxlon grid at height=0, but they will all shortly have very unique
latitudes at each vertical level. This would go for longitude and
height, too, so you'd need a "lon_coords(height,lat,lon) and a
"height_coords(height,lat,lon)".
Completely general coordinates! A thing of beauty! With no additional
attributes to name. (BTW, this is exactly how "curvilinear
coordinates" work in the Iris Explorer 3-D visualization package.)
> What you can say is "the variables lat_coords,
> lon_coords are the coordinate functions for the variable TEMP".
Bingo! Even better (and more specifically), I can say that
"lat_coords" contains the coordinates (or coordinate function, if you
prefer) for TEMP along the "lat" axis, and "lon_coords" contains the
the coordinates for TEMP along the "lon" axis.
Note that this example was designed to show how to limit the
association to a specific variable. My second example (which you did
not address) showed how the method might be extended to apply to a
*coordinate* variable (even if it is only 1,2,3...). Then, by
inference, those coordinates would apply to any variable which employed
the dimension represented by that main coordinate variable.
> I want to claim that (lat, lon) are nothing but indices, and could just
> as well be written (npoints).
Absolutely not...this would represent a loss of information content.
The fact that TEMP is a 6x5 array is more informative that the fact
that there are 30 TEMP values (per horizontal slab).
> If theres a coordinate variable lat(lat), then we have some
> meaning. So the dimensions aren't fundamental to a coord system, the
> coord functions are.
No - they both are. Dimensions describe the shape of the variable,
coordinates describe its spatio-temporal placement.
> So in general, you can't define the coordinate
> system in reference to the dimensions (well, you can, but I claim its
> not the best).
Please, if there's an even better, clearer approach, I'd be very
interested in it!
> better is something like:
> float TEMP(height, lat, lon) ;
> TEMP:coordinates="lon_coords lat_coords" ;
> float lon_coords(lat,lon) ;
> float lat_coords(lat,lon) ;
>
> although I've come to favor:
> float TEMP(height,x,y) ;
> TEMP:coordinates="lon_coords lat_coords" ;
> float lon_coords(x,y) ;
> float lat_coords(x,y) ;
I don't see any difference in the information content of these two
examples. You've simply replaced "lat,lon" wih "x,y". Consider this
very generic version of your example, where all I've done is substitute
some strings:
float A(k, j, i) ;
A:quatluu="abc def" ;
float abc(j,i) ;
float def(j,i) ;
If I'm an application developer, I can see (having been told to look
for a specific attribute named "quatluu") that I am supposed to get
coordinate information from "abc" and "def". I can also see that,
since "abc" and "def" are dimensioned (j,i), that these are coordinates
for the i-j plane of points in "A". BUT, I *cannot* tell whether "abc"
or "def" gives me the points along the j-axis.
John
(jps@xxxxxxxx)
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
