Hi,
Rich Signell has suggested adding two new netCDF conventions to distinguish
between vector-variable component dimensions and coordinate dimensions and
to represent the mapping between data and coordinate spaces.
Regarding the first convention, he writes:
> *****************
> Convention 1: define a dimension named "components"
> *****************
>
> In netCDF, we know how many dimensions the variable has, but we don't
> know which of these dimensions correspond to data space and which
> dimensions correspons to components of a vector. For example, a
> three-component velocity vector defined on a 2D coordinate grid might
> be defined
>
> dimensions:
> lat=20,lon=20,components=3;
> variables:
> float velocity(lat,lon,components);
>
> A priori, we don't know that "components" doesn't refer to depth, or
> some other coordinate dimension. Luckily, netCDF uses named dimension,
> so all we need to adopt a convention that defines a special dimension
> name that tells the application "this dimension denotes the number of
> data components at each coordinate node". The design plan for the
> SIEVE system that is being developed by the USGS in Reston incorporates
> this convention, suggesting "components" as the special dimension
> name. Seems logical to me.
>
> By adopting this convension, we pick up two more critical pieces of
> information, numbers 1 and 2 on the list above: the dimensions of the
> data space and the number of components at each coordinate node.
The current alternative to this convention is to define the components
separately, giving each component a name, as in
dimensions:
lat=20,lon=20;
variables:
float velocity_x(lat,lon);
float velocity_y(lat,lon);
float velocity_z(lat,lon);
The advantages of the new "components" convention, as I see it, are
- fewer variables and attributes
- grouping of vector components that share the same attributes, e.g.
units
A disadvantage is that you have no handle with which to specify what the
individual components mean. For example, with the second alternative, it's
possible to use an attribute for each component to specify the axis
orientation. With the "component" convention, either the applications must
know what the components mean, or another attribute must be added to the
vector variable that specifies the meaning of the components.
Another problem with the "components dimension" proposal is what to do in
case you have multiple vector variables defined on the same nodes but with
different numbers of components. For example, what if in addition to
"velocity" you wanted to include "polarization" at each point, where
"polarization" was a vector variable with only two components. One
possibility is to extend the convention to permit multiple component
dimensions that all begin with the string "component_", as in:
dimensions:
lat=20,lon=20,components_vel=3, components_pol=2;
variables:
float velocity(lat,lon,components_vel);
float polarization(lat,lon,components_pol);
Another possibility is the use of two global attributes that list which
dimensions are coordinate dimensions and which are vector component
dimensions, as in:
dimensions:
lat=20,lon=20,vel=3, pol=2;
variables:
float velocity(lat,lon,vel);
float polarization(lat,lon,pol);
// global attributes
:component_dimensions="vel pol";
:coordinate_dimensions="lat lon";
In spite of this complication, I like the idea of the proposal and agree
that a convention distinguishing between vector variable component
dimensions and coordinate-space dimensions is a good idea.
I may comment on the "independent_variables" convention in a later posting,
after I've had time to understand it.
--Russ
