> Date: Tue, 15 Jul 1997 00:07:04 +1000
> To: netcdfgroup@xxxxxxxxxxxxxxxx
>
> From: Harvey DAVIES <hld@xxxxxxxxxxxx>
> Subject: netCDF Conventions
>
> dimensions:
> time = UNLIMITED;
> latitude = 56;
> longitude = 64;
> land_point = 1100; // about 30% of 56*64
> variables:
> float latitude(latitude);
> float longitude(longitude);
> short land_index(latitude, longitude); // value of 'land_point' index
> land_index:valid_min = 0;
> land_index:missing_value = -1; // -1 = ocean point
> float soil.temperature(time,land_point)
I tried this example out using the "global map attributes" ideas with the
"sub-map" or direct indexing extension. I asterisked the added lines:
dimensions:
time = UNLIMITED;
latitude = 56;
longitude = 64;
land_point = 1100; // about 30% of 56*64
variables:
float latitude(latitude);
float longitude(longitude);
* short land_point_lat(land_point);
* short land_point_lon(land_point);
short land_index(latitude, longitude); // value of 'land_point' index
* land_index:land_index = "lat-lon-map";
land_index:valid_min = 0;
land_index:missing_value = -1; // -1 = ocean point
float soil.temperature(time,land_point);
* soil.temperature:soil.temperature = "land-point-map";
* :lat-lon-map = "latitude longitude";
* :land-point-map = "land_point_lat:latitude land_point_lon:longitude";
This was tougher than I thought it would be. It is different from my
original example in which the "sub-map" attribute just indicated which
variables would map directly into each dimension of a given variable. In
this case the name to the right of the ':' is a variable and not a
dimension, but the association still makes sense to me. The
"land-point-map" coordinate system referenced by the soil temperature
variable gives the lat/lon coordinates of soil.temperature(time,i):
(latitude(land_point_lat(i)), longitude(land_point_lon(i)))
An application (and a human) can determine that this mapping is possible
because land_point_lat and land_point_lon are defined over the same
dimensions as soil.temperature.
This example did suggest a weakness in my original example, included below:
dimensions:
i = 10; // Whole grid
j = 100;
k = 100;
i2 = 10; // Region of grid
j2 = 20;
k2 = 20;
float temp (time, i, j, k);
temp:temp = "subgrid-map particle-trace-map lat-lon-map";
float depth(time, i,j,k);
depth:depth = "particle-trace-map";
float lat(j, k);
lat:lat = "particle-trace-map";
float lon(j, k);
lon:lon = "particle-trace-map";
int a (i2, j2, k2);
int b (i2, j2, k2);
int c (i2, j2, k2);
int particle_i (time);
int particle_j (time);
int particle_k (time);
:subgrid-map = "a:i b:j c:k";
:particle-trace-map = "particle_i:i particle_j:j particle_k:k";
:lat-lon-map = "lon lat";
An application can get temperatures over a sub-grid or along a particle
track, but to associate a coordinate system with that sub-map it needs to
choose one of the other coordinate systems which is not a sub-map, such as
'lat-lon-map'.
Note that I'm not suggesting any way to indicate that the variable
'latitude' is an 'Earth latitude'. Without interpreting the variable name,
an application wouldn't know the word 'latitude' from 'altitude above
Barnacle Bill'. That sort of definition will require more specific
attributes which others like Harvey are already working out. Once a
convention is chosen for attaching the concept 'this is a geographical
altitude coordinate' to a variable, then all I'm suggesting is a way to
attach a coordinate system -- which includes that coordinate variable -- to
other variables.
> In cases where there is a need to distinguish between similar variables,
> there could be a convention specifying part of the name.
> E.g. temperatures could be indicated by the suffix '.temperature' as in:
>
> float surface.air.temperature;
> float soil.temperature;
I agree that orthogonality should be one of the objectives, but I see a
'dot' convention as contrary to that. A variable name is just that, an
identifier to distinguish variables. If you want to qualify a variable as
a particular physical quantity (eg, temperature) or as coordinate values in
geographic space (eg, latitude) or whatever, then I think that
qualification is an attribute of the variable and not part of its name. If
down the road more qualifiers were added, would there be a convention for
the order of the dot-separated portions? Complicated wording and parsing
will make file and application designer errors more likely. My preference
would be putting attributes where they've been specially accomodated: in
the variable and global attributes, with names as simple (not compound) as
possible. The same preference applies to standardizing variable names: if
a name must be standardized to be definitive, then that's a qualification
which belongs instead in the attributes.
gary
