Hi,
John Sheldon writes:
> The point here was that referential attributes provide a *mechanism*
> for associating variables.
My point was that u, p and vpt are already associated by virtue of having
identical dimension lists. The referential attribute provides no new
information in example 1.
I agree that referential attributes provide a mechanism for associating
variables, but they do not describe the relationships between variables so
associated.
> Your objection to the lack of an actual "z" cooridinate is
> solved by specifying the attribute as 'u:z = "vpt, p, alt" ', where a
> variable "alt" could be provided to document the actual altitude of the
> points. The variable "alt" would carry along its own metadata
> documenting how it was calculated (eg, hypsometric equation, virtual
> temperature correction, etc...).
In this example I believe that the existing convention for coordinate
variables is the method that should be used to define z.
> In all cases, one still has to know how to
> interpret the referenced variable (a bit complicated, but one could,
> conceivably, infer a relationship base on the shape of the referenced
> variable). There are no established conventions here - we're just
> suggesting some alternatives that fit within the conventions that have
> already been established WRT netCDF.
Exactly. And therein lies the problem. The conventions on these
relationships that would work for describing 2D coordinate variables won't
be the same as the one that would be required to describe what is meant by
e.g., 'u:z = "vpt, p, alt"'
> I see where you're going, but this is one solution that does *not* fit
> within the conventions that have already been established, because
> there is a long-standing convention that variables with the same name
> as a dimension are "coordinate variables", and should be one-
> dimensional vectors containing the coordinates of the points along that
> dimension.
The fact that netCDF's current convention for coordinate variables only
applies to 1D variables makes it easy for an application to recognize that
e.g., lon(lon,lat) is not a "coordinate variable" in the sense of the
current convention.
> This is not to say that you couldn't write your own
> application to use such data - all the information you need is, indeed,
> present. But you will have some difficulty getting any existing
> software to read it.
Any application that is looking for coordinate variables expects the
corresponding data to be on a rectilinear grid. If I need 2D coordinates
to describe the grid then it is not rectilinear and a package designed
to plot rectilinear data shouldn't be expected to work.
> Note that, in Example 6, there is also no explicit metatdata linking
> "mydata" with the variables "lat" and "lon". Assuming that an
> application could ignore the problem of violating the "coordinate
> variable" convention, for all it knows, the 3 variables "lat", "lon",
> and "mydata" could be temperature, humidity, and wind speed.
OK. Here is the unabridged version of Example 6.
dimensions:
lat = 4 ;
lon = 3 ;
variables:
float lat(lat,lon) ;
lat:long_name = "Latitude" ;
lat:units = "degrees_north" ;
float lon(lat,lon) ;
lon:long_name = "Longitude" ;
lon:units = "degrees_east" ;
float mydata(lat,lon) ;
mydata:long_name = "data description" ;
mydata:units = "whatever" ;
We use the units attributes of lat and lon to tell us that we are working
on a lat-lon grid (as in COARDS). That lat and lon are 2D arrays tells us
that the grid is not rectilinear.
By analogy to the current convention for coordinate variables example 6
would be interpreted as, e.g., the lat-lon coordinates of mydata(1,1)
are lat(1,1) and lon(1,1).
Brian Eaton
eaton@xxxxxxxxxxxxx
NCAR, Climate and Global Dynamics Division.
Boulder, CO.
