Hi John,
>Date: Fri, 11 Jul 1997 16:35:40 -0400 (EDT)
>From: jps@xxxxxxxx (John Sheldon)
>To: steve@xxxxxxxxxxxxxxxx (Steve Emmerson)
>Subject: Re: Coordinate Systems Proposals
In the above message, you wrote:
> The only remaining heartburn I have is with the implementation you and
> John Caron seem to come back to. I addressed this in my previous
> mail, but let me briefly mention it again....In your example:
>
> > dimensions:
> > i = 5;
> > j = 6;
> >
> > variables:
> > float temp(i,j);
> > temp:coordinates = "lat, lon";
> > float lat(i,j);
> > float lon(i,j);
>
> there is nothing to tell an application whether the contents of "lat"
> should be used as coordinates along the i-dimension of "temp" or the
> j-dimension.
As far as I can see, there is no reason "to tell an application
whether the contents of `lat' should be used as coordinates along
the i-dimension of `temp' or the j-dimension". Indeed, I'm not even
sure what you mean by that statement. Applications typically need to
convert between manifold coordinates and base coordinates. In the
above example, an application might need to find the (base coordinates)
(lat,lon) corresponding to the (manifold coordinates) (2,4). This
would be done by forming the base coordinates (lat(2,4),lon(2,4)). The
inverse computation (finding the manifold coordinates corresponding to a
base (e.g. (lat,lon)) position) is a bit trickier. In the general case,
this would involve a search of the base coordinates to locate the set of
manifold coordinates (e.g. (i,j)'s) closest to the base coordinate point
in question. Still, it's no big deal.
> In addition, it introduces another attribute when it's not
> necessary. Isn't this cleaner and less ambiguous:
>
> dimensions:
> i = 5;
> j = 6;
>
> variables:
> float temp(i,j);
> temp:i = "lat";
> temp:j = "lon";
> float lat(i,j);
> float lon(i,j);
I'm afraid I don't know what it means to have "i" and "j" associated
with "lat" and "lon", respectively. Why not the reverse, i.e.
float temp(i,j);
temp:i = "lon";
temp:j = "lat";
In general, a manifold coordinate system and a base coordinate system
are completely independent of one another: it makes no sense (at least
to me) to attempt to associate a coordinate in one system with a
coordinate in another.
> First, I would restate this example like so:
>
> > dimensions:
> > s = 100;
> >
> > variables:
> > float temp(s); // temperature along spiral
> > temp:s = "z, rho, theta";
> > // cylindrical coordinate system (CCS)
> > float rho(s); // distance from CCS center axis
> > float theta(s); // CCS azimuth
> > float z(s); // CCS height
>
> so that the rule about interpreting referential attributes (same name
> as a dimension) continues to work.
I agree that the above would be necessary in order to be consistent
with your proposed syntax. It wouldn't be necessary, however, in the
syntax I presented (which, BTW, is merely an example) because the
attribute "coordinates" would be a keyword (similar to "_fillvalue");
> BUT, I think the *new* problem you raise here (please forgive my poor
> memory if it has been mentioned before) is that we have been too
> geo-centric. Now, maybe we can be forgiven since most of us are
> probably earth scientists anyway. I think we need a way to specify the
> coordinate system for which the ancillary coordinates apply (spherical,
> Cartesian, cylindrical,...). A generic application needs to know that
> "rho", "theta", and "z" are not lat-lon-z, or x-y-z. Suppose some one
> instead used the names "coord1", coord2", and "coord3"? We'd have no
> idea!
>
> I think part of what John Caron was getting at with his proposal had to
> do with this. Perhaps he was suggesting that part of his proposed
> "coordinates_xy" and "coordinates_latlon" attributes contained the
> substring necessary to infer this. I don't particularly like this
> implementation - in this case, i *would* I'd prefer to add a new
> attribute like "coord_system".
Yes, some way of identifying the base coordinate system would be
appropriate. It could either be implicit (by recognizing certain names
like "lat" and "lon") or explicit (by defining another attribute keyword
which would contain the description).
> BTW, I agree with your list of conditions for expanding the conventions
> regarding coordinate variables. It always seems like a good idea to
> "first, do no harm".
Thanks.
--------
Steve Emmerson <http://www.unidata.ucar.edu>
