Hi John, >Date: Tue, 15 Jul 1997 16:04:48 -0400 (EDT) >From: jps@GFDL.GOV (John Sheldon) >To: steve@unidata.ucar.edu (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>