William Weibel wrote:
>
> 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.
Yes, Im trying to get some of the associations of spatial coordinate
systems to rub off on the more general case by borrowing some of the
language of the former. The problem is making people think too
specifically of the spatial coordinate case, which seems to happen some.
I agree that "physical space" is too specific to spatial coordinates.
What I really want to say is that coordinate systems map indices to
"meaningful" values, but "meaning space" seems too vague and "semantic
space" too pretentious.
...
> > 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).
Since the u=x, v=y association is inherent in the data, and not just a
display issue, it seems appropriate to try to specify that in the netcdf
file. Its not strictly a coordinate system issue as we have defined it
so far, I guess.
>
> > > > 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)?
I didnt mean to propose the syntax year.day.second, just the idea that
you can construct a single value out of the 3-tuple. These tuples "mess
up" my identification of a coordinate function with a single axis; you
have to put them back together again (year.day.second) to get a single
time axis, which i assume is what you really want.
I see COORDS as a specialization, or restriction of this more general
coordinate system convention, and in that sense can be seen as
"compatible". Tentatively, it seems unlikely that COORDS can be
generalized in a backwards compatible way (Im a little fuzzy on that).
Astronomers and other disciplines I expect would adopt specializations
on top of a general convention, which would for example restrict the
time representation.
