Hi John,
>Date: Tue, 15 Jul 1997 16:04:48 -0400 (EDT)
>From: jps@xxxxxxxx (John Sheldon)
>To: steve@xxxxxxxxxxxxxxxx (Steve Emmerson)
>Subject: Re: Coordinate Systems Proposals
In the above message, you wrote:
> > How do we identify the transformation from base coordinates to world
> > coordinates.
>
> Geesh - that makes it sound so "theoretical" and complicated!
> ...
> Now, go ahead laugh at my (tongue in cheek) visceral reaction above,
> but I said it for a reason. While it is good that there is some
> underlying principles for representing and converting information,
> potential users and app-developers are going to read this kind of stuff
> and give up. "All I want to do is be able to plot my data." What does
> it mean to say that "the data is either manipulated or displayed by
> some system that is outside the context of the data"? If I have
> lat-lon-height data, I may not care that it's projected onto a globe
> (or a Lambert conformal projection, or ...).
If you have (lat,lon) data, then it's *not* projected onto a globe (or a
Lambert conformal projection, or ...). What it is is data whose base
coordinate system is a geodetic (i.e. geographical) one.
> But I do want the points
> to be laid out with some care given to their relative placement (a
> 100x100 point array with 2deg-lon x 1deg-lat ought to be twice as long
> as it is high). Aren't 99% of plots in journal articles done this
> way?
If you want the above, then you want a coordinate transformation that
converts between the (lat,lon) coordinates of the base coordinate system
of the data and the (x,y) coordinates of a rectangular equidistant world
coordinate system. There are many other candidate world coordinate
systems and transformations (e.g. Lambert conformal, Mercator).
In my opinion, it is up to the application to choose the appropriate
world coordinate system. What the application needs to know, however,
is the nature of the base coordinate system so that the application can
choose an appropriate world coordinate system and transformation.
Thus, the problem is reduced to identifying the nature of the base
coordinate system to the application. If I told you that the
coordinates for some data were "lat" and "lon" in a geodetic coordinate
system, you would completely understand the system and would have
no problem converting to and from the (x,y) coordinates of a map.
Similarly, if I said that a set of coordinates were rho (in meters),
theta (in radians), and z (in meters) in a cylindrical coordinate
system, then you would again have no problem. The keywords in the above
(i.e. "geodetic", "cylindrical") have useful meaning. I believe that we
can make use of that meaning to identify the base coordinate system to
applications.
>
> Can't we just say that a variable has a "shape" given by the number and
> length of its dimensions, and its points can be located by "index"
> along its dimensions (ie, 1,2,3,...) or by "coordinate values" (eg,
> 1.25, 2.5,...)? Then, depending on the qualities of the coordinates,
> we can project the data onto/into whatever space is applicable.
Yes, we can do that. The trick is figuring out the nature of the base
coordinate system.
> > dimensions:
> > x = 5;
> > y = 10;
> > z = 12
> >
> > variables:
> > float p(x,y,z);
> > p:coordinates = "lat lon alt";
> > float lat(x,y);
> > lat:coordinate_type = "latitude";
> > float lon(x,y);
> > lon:coordinate_type = "longitude";
> > float alt(x,y,z);
> > alt:coordinate_type = "altitude";
>
> !Excellent example! Now, I'll ask this one more time...can my
> application infer that "lat lon alt" is an ordered list intended to
> point to variables containing coordinates for "(x,y,z)", respectively?
No, your application shouldn't make that inference from the above
example. Instead, your application would have to deduce from the
keywords "latitude", "longitude", and "altitude", that the base
coordinate system was a geodetic one. Your application would then
decide upon the world coordinate system in which to display the data
(Mercator, Lambert, etc.) and setup the appropriate transformations.
--------
Steve Emmerson <http://www.unidata.ucar.edu>
