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@xxxxxxxxxxxxxx
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
|||| | | | | | | | | | | | | | | | | | | | | | | ||||
