Hi again to you!
> > 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.
so my point is this: what do you mean by the "lat axis"? Its well
defined by the coord function lat_coords(), but not well defined by the
index lat. Thus the association with the dimension lat is not precise.
The "hidden" semantic is that "lat_coords lon_coords" is the coord
system for the variable TEMP. Of course we already know that, so its
"obvious". I'm trying to make explicit the obvious.
I'm just pushing to see how precisely our syntax/conventions can reflect
our semantics.
>
> 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.
my comments would apply to both examples.
>
> > 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).
yes i'm beginning to see this point better; the question is, exactly
what information does it convey? Brian Eaton has pointed out that it
conveys connectivity information, which obviously is useful.
>
> > 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.
I would claim that neither does (in general). Consider a 45 deg rotated
coord sys.
In reality, x and y probably do mean something, namely km on a
projection plane. So I would advocate that the user specify:
x(x) // km
y(y) // km
lat(x,y) // deg N
lon(x,y) // deg E
and
: coordinates_xy = "x y";
: coordinates_latlon = "lat lon";
to emphasize we have specified two coordinate systems. Of course the
first attribute would likely be unnecessary by use of our (existing)
convention on coordinate variables, but I'd still recommend including it
(if it doesnt clutter things, eg as a global attribute). For that
reason I prefer it over the use of (i,j) because i(i) and j(j) hurt my
eyes :^). Of course these would be recommendations (by me) if someone
asked my opinion; it would not be my intention to disallow them.
Regards,
John Caron
