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