Re: coordinate systems
Stephen.Walker@marine.csiro.au
Wed, 23 Jul 1997 10:09:06 +1000
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
