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