Just some comments from an atmospheric science worker on a couple of items. I wanted to contribute to the ideas regarding syntax for referential attributes. But the discussion has gotten a bit too detailed for me to follow. John Caron's definition of a "coordinate system" seems nearly general enough. I would save terms such as "physical space" and "location" for the definitions of "spatial coordinate system" and the like. Unfortunately, I can't think of any more general alternatives at the moment. > > > > > > ... > > > ---------------------------------------------------------------------------- > > > > > > Examples > > > > > > Shorthand "solutions" of the motivating examples : > > > > I'll combine parts of your mail and offer an alternative set of > > solutions here. The two approaches are so close that I think little > > additional explanation is required. Basically, my approach differs > > in the following ways: > > ... > > a) define global "coordinate maps", a la Gary Granger > > > > b) the "coordinate map" name should have a prefix indicating the > > basic coordinate system (cartesian, cylindrical, spherical, > > geodetic, ...) One thing to keep in mind is a distinction between the specifying enough degrees of freedom to describe a field of data, and how some application may display the data. For nonspatial coordinates, such as frequency, magnetic field strength, or happiness, there is no inherent coordinate map. > > > > > > 7. vector valued variables, for example: > > > vector(lev, 3) > > > velocity(lat,lon,component) > > > component(3) = "u", "v", "w" > > > > Your solution: > > > :coordinates = "lev"; > > > :coordinates = "lat lon components"; > > My solution: > > This is not a "coordinates" issue. "Associating" separate scalar > > quantities into a vector quantity is a useful goal, but I haven't > > had time to give it enough thought. > > The u,v,w example is tricky because there is another level of > information we want to associate here, namely the spatial direction of > each of those components. All I intended here was to label the three > numbers. I think this is a case where the distinction between inherent degrees of freedom and display issues (or analysis issues) comes up again. > There is some interesting problem here on specifying a wind vector, > having both a location and a direction. Anyone want to offer an axample > and solution? I wonder if an attempt is being made to specify too much too soon. Typically, we declare each component of a vector field as a scalar variable. When we look at the data (in this case, using GrADS) we say display u;v so the user explicitly declares at display time that u is the x component and v is the y component (because cartesian coordinates are assumed). > > > 11. multiple time coordinates: > > > > > > var(time) > > > year(time) > > > day_of_year(time) > > > second_of_day(time) > > > > Your solution: > > > :coordinates = "year, day_of_year, second_of_day"; > > > > My solution: > > short time(time); // simply index values, unless you > > // have a traditional value, too > > time:component="year, day_of_year, second_of_day"; // a la GDT > > I admit I havent dealt with this example. > > In the GDT solution I dislike putting indices in the time(time) > variable; The semantics of "component" just gives you a 3-tuple so you > lose the fact that year.day.second is ordered. > I'm afraid others are much better qualified than me to comment on time. But the expression "year.day.second" looks a little scary. I doubt whether astronomers would adopt such a thing. Are these ideas compatible with the COARDS convention (http://ferret.wrc.noaa.gov/noaa_coop/coop_cdf_profile.html)? Sincerely, William Weibel |||| | | | | | | | | | | | | | | | | | | | | | | |||| William Weibel weibel@atmos.ucla.edu UCLA Department of Atmospheric Sciences Tel. (310)206-4441 \\\\/ Los Angeles, CA 90095-1565 Fax (310)206-5219 O-O U.S.A. | - ... to know even one life has breathed easier because you have lived; this is to have succeeded. --Ralph Waldo Emerson |||| | | | | | | | | | | | | | | | | | | | | | | ||||