Hello Rich, Tim, et. al.,
I agree, netCDF **needs** to provide a standardized mechanism for storing
vector
data (multiple compionents) and "irregular" grids (in the AVS sense you
described). I will incorporate your ideas (in bullet form) into the "straw
man"
conventions.
I would like to propose a variation on the theme you set out, Rich.
Your proposed "Convention 1" to accomodate vector components is:
dimensions:
lat=20,lon=20,components=3;
variables:
float velocity(lat,lon,components);
The difficulty with this is that it limits the richness of the file in
describing the individual components. For example, the Z velocity component
("W" in U,V,W) would often be determined by an entirely different means than U
and V. Since W is never broken out as a separate variable this becomes
difficult to document.
I suggest the use of "dummy" variables for the purpose of binding together
components:
dimensions:
lat=20,lon=20,depth=5,vector_def=1;
variables:
float u(lat,lon,depth);
u:long_name = "zonal speed";
float v(lat,lon,depth);
v:long_name = "meridional speed";
float w(lat,lon,depth);
w:long_name = "upwelling computed by divergence ...";
char velocity(vector_def); // ** dummy variable **//
velocity:long_name = "3-component velocity";
velocity:components = "u v w";
Besides the advantage of righ meta-data storage for the components this has
another major selling point: if the dummy variable is ignored this is a
completely conventional netCDF file. This means that generic, current netcdf
files could be converted to this form simply by adding dummy variables and
their
attributes.
I will include your "Convention 1" and this variation as Proposals in "A
Strawman Profile for Oceanographic NetCDF Files". I will also include
your (important) "Convention 2". It directly addresses the need for the
storage
of "irregular" data types like ship-track observations.
| NOAA/PMEL | ph. (206) 526-6080
Steve Hankin | 7600 Sand Point Way NE | FAX (206) 526-6744
| Seattle, WA 98115-0070 | hankin@xxxxxxxxxxxx
