John Thanks for your reply. My further comments are interspersed: ... > I was able to view it, no sweat. And it illustrates the problem quite > well. Is there some way to do this in ASCII so that others could see > it as part of some mail? Hmmm, something like... <ASCII art deleted> Yes - I like your ASCII diagrams. > > Take a netCDF fragment as follows: > > > > dimensions: > > i = 10; > > j = 5; > > > > variables: > > float temperature(j,i); > > temperature:coordinates = "x,y"; > > float x(j,i); > > float y(j,i); > > > > Note that I have used our suggested "coordinates" attribute, rather than > > Jonathan's "associate" one, but this is unimportant to what follows. > > > > Looking at my plot, the temperature values are on a grid containing 5 rows > > and 10 columns, and are located at the black dots. Each black dot has a location > > in (i,j) space, and also a location in (x,y) space. For example, the lowest > > dot on the page is located at (i=0, j=0), or alternatively (x=5, y=2). > > What you seem to want to do is to associate x with i and y with j. > > In this case, can you actually do it? Can you associate x with either i or j? > > Can you associate y with either i or j? I would argue that you cannot, because > > x values vary when you vary either i or j, and so do y values. > > Precisely! (Thank you!) Good - I'm glad you agree here. > Now, maybe such an example seems too obvious to everyone because the > coordinate variables are named "x" and "y", from which everyone > immediately infers a Cartesian location: > > temperature (2,3) has coordinates X=x(2,3) and Y=y(2,3) > > "Sure, I know where that goes!" they would say. But if I just change > the strings to something less "familiar", what would they say? : > > dimensions: > a = 10; > b = 5; > > variables: > float A(a,b); > A:coordinates = "abc,def"; > float abc(a,b); > float def(a,b); > > I haven't changed the data or "coordinates" a bit, but there's no > "obvious" inferences this time. This is what basic application > software would be faced with. Yes - I agree that this is a good, more general, example. <My stuff about using attributes of coordinate variables to give further information deleted> > Several useful concepts have been mentioned throughout these discussions, > and some of them are applicable here: > > 1. we need to know what the "correct" (ie, intended) coordinate > system is for the variable (eg, Cartesian, cylindrical, etc.) > (Not that you could "force" a different interpretation, but > one "system" ought to "natural".) I'm not sure that there always is a single 'natural' coordinate system. I spend a lot of time modelling bays and estuaries, ranging in size from hundreds of metres to tens of kilometres. I use both (lon,lat) and (X,Y) (where X and Y are coordinates in some sort of projection - usually some choice of Universal Transverse Mercator, with a specified spheroid, zone and false origin). At these scales, either system is a 'natural' choice. > > 2. to which axis does each "coordinate variable" (however they are > identified) apply? I'm not entirely sure what you mean here. I think that by 'axis', you mean one of the axes on the display screen or piece of paper upon which data is displayed. Is that right? If so, then a coordinate variable might not correspond to any such axis - the display software might need to make a further transformation in order to produce a plot. Here we need to be careful to distinguish between the coordinates which locate the data in the physical world, and the coordinates which locate a given line element or pixel on a plot. They are not always the same. As far as I understand it, most of the discussion about coordinates has been about coordinates which locate the data in the real physical world, not plot coordinates (which may or may not be related to real-world coordinates in a simple way). > > 3. if there are several "coordinate variables", which ones make sense > to use together as a "system"? Yes - I agree that this is an issue. > There seems to have been many objections to the use of "referential > attributes" raised to date, but I'm not sure any of them are > legitimate. You recently (in a recent mail) also raised an objection, > namely, that such an approach could not handle the case where the > dimensionality of the space in which that data resides exceeds the > dimensionality of the array containing the data because "you can't have > more coordinate variables than you have dimensions". No - I probably didn't make myself clear enough. The point is not that the data may reside in a space with higher dimensionality, but that there may be several equally valid coordinate systems. For example, I said above that I use both (X,Y) and (lon,lat) when modelling estuaries. A more general example of this is included below. > I may be wrong, > but I don't think the original idea of referential attributes mandates > such a restriction. Take, for example, temperature along a particle > trajectory: > > dimensions: > point = 100 ; > > variables: > float temp(point) ; > temp:point="lat,lon" ; > float lat(point) ; > float lon(point) ; > > Now, that pretty clearly says that "lat" and "lon" contain some sort of > coordinate information for "temp", without the need for a new > attribute. Well, yes, but this example is not like most of the prior explanations of the use of referential attributes. In fact, if you just re-name the "point" attribute to be "coordinates", then you have precisely our proposed scheme in this case. > This is not really *sufficient*, mind you, and it's not as > clear an association as this: > > dimensions: > i = 10 ; > j = 10 ; > > variables: > float temp(j,i) ; > temp:j="lat" ; > temp:i="lon" ; > float lat(j,i) ; > float lon(j,i) ; > > but it does get you part of the way there. This is where we part company. Looking again at my postscript diagram (and replacing Y by lat and X by lon), why should j be associated with lat, and why i with lon. To make it clearer, lets go back to your more general example, using abc and def above, and try to do it your way: Should we have: variables: float A(a,b); A:a = "abc"; A:b = "def"; float abc(a,b); float def(a,b); Or perhaps: variables: float A(a,b); A:a = "def"; A:b = "abc"; float abc(a,b); float def(a,b); Or, extrapolating your "point" example above, perhaps even: variables: float A(a,b); A:a = "abc,def"; A:b = "abc,def"; float abc(a,b); float def(a,b); I can't see how the referential attribute approach helps in this case. Even worse, lets now suppose that we are using my estuary model, and have 2 more or less equally valid coordinate systems. Here is our proposal, using the general example: dimensions: a = 10; b = 5; variables: float A(a,b); A:coordinates = "abc,def,ghi,jkl"; float abc(a,b); float def(a,b); float ghi(a,b); float jkl(a,b); I freely admit that this is pretty inscrutable as it stands. What it does achieve is to identify the coordinate variables associated with the data variable A. But an important point here is that I can't see how the referential attribute approach can achieve even that in this case. To alleviate the inscrutability, a number of people (including us) have suggested that the coordinate variables should have useful attributes. Our suggestion is to do something like the following: variables: float A(a,b); A:coordinates = "abc,def,ghi,jkl"; float abc(a,b); abc:coordinate_type = "X (AMG66 zone 55)"; float def(a,b); def:coordinate_type = "Y (AMG66 zone 55)"; float ghi(a,b); ghi:coordinate_type = "longitude"; float jkl(a,b); jkl:coordinate_type = "latitude"; There would preferably also be units and long_name attributes, etc, but I have left those out for clarity. Now an application has some useful information to go on. > In any case, we still need > to answers to questions 1-3 above. > <Your stuff about Explorer deleted> > Whew, I didn't mean to go on so long about that, but maybe it will > initiate some new line of thinking. (That's what most of these > exchanges are all about anyhow, right?) Yes - and I guess a certain amount of length is unavoidable to make sure that we are discussing the various issues clearly. Thanks again for your thoughts, Regards, Stephen Walker Email: Stephen.Walker@marine.csiro.au CSIRO Marine Research Fax: 03 6232 5123 GPO Box 1538, Hobart Phone: 03 6232 5298 Tasmania, AUSTRALIA