Re: netCDF Conventions

John Caron (caron@ucar.edu)
Wed, 16 Jul 1997 12:19:41 -0600 

Hi Harvey, welcome to the madhouse:

...
> COORDINATE VARIABLES
> 
> There is a need to allow string values (e.g. Station names) for coordinate
> variables.  But I disagree with Russ Rew on allowing 2D NUMERIC coordinate
> variables for such things as dates.
> 
> Such names are essentially nominal values with no inherant ordering.  But
> dates are ordered and more simply represented by a single number than by some
> kind of multi-base number.  I am yet to be convinced that any of the
> multi-dimensional coordinate variable ideas is basic enough to deserve
> adoption.

Russ's idea allows multiple coord. functions to specify, eg, the "time
axis". When we talk about a multi-Dimensional coord var, I think we mean
a variable with more than one dimension. Note that the two are
diffferent.

I would say that a "general" coord sys would allow Russ's suggestion.
However, we might want to define a special kind of coord system, eg the
"time coordinate" that requires a single, monotonic coordinate function
that corresponsd to our notion of "real time".

...
> JOHN CARON'S MOTIVATING EXAMPLES
> 
> John's examples 2 and 9 are both examples of non-gridded (irregular or
> scattered) data.  The same single index is used in separate vectors to get
> coordinates and data values.  Example 3 simply generalises this to
> multiple subscripts.  A satellite data example is:
> 
>     float radiance(line, pixel);
>     float latitude(line, pixel);
>     float longitude(line, pixel);
> 
> which is essentially the same as:
> 
>     float radiance(point);
>     float latitude(point);
>     float longitude(point);
> 
> It seems to me that examples 4 and 10 are just mixtures of these with the
> classical 1.

I should say that the intention is to capture examples of different
semantics,
regardless of the functional form. Then we try on different proposals,
to check existence and elegence of the solution.

> 
> Example 5 needs more detail.  I assume var has other dimensions.  I seem to
> remember Russ Rew suggesting a 2D coordinate variable for this case along the
> lines of:
> 
>     dimensions:
>         latitude = 56;
>         longitude = 64;
>         level = 10;
>         range = 2;
>     variables:
>         float level(level, range);  // level(k,0) = bottom, level(k,1) = top
>         float var(latitude, longitude, level);
> 
> This has some appeal, but it does not seem basic enough to justify
> generalising coordinate variables to 2D.
> 
> Example 6 has too little information for me to understand.  If you simply want
> a non-georeferencing example then why not use Steve Emmerson's (now already
> famous) spiral wire example.  But this is essentially the same as 2 and 9.

I will add the wire example.  

> 
> I found example 8 unnecessarily complex.  I assume corr_var(lat1, lon1, lat2,
> lon2) gives the correlation between the point (lat1, lon1) and the point
> (lat2, lon2).  A simpler case is the following involving annual precipitation
> measured at 100 stations:
> 
>     dimensions:
>         year = UNLIMITED;
>         station = 100;
>     variables:
>         float precipitation(year, station)
>         float precipitation.correlation(station, station)
> 
> where precipitation.correlation(i,j) is the correlation between precipitation
> at station i and precipitation at station j.
> 
> This could also be used in place of Example 7.  The precipitation for each
> year is a vector of 100 elements.  The calculation of a correlation matrix
> requires that these 100 all be in the same array, rather than 100 separate
> variables.

this is a better "real world" example and I will replace example 7.

> 
> An example I would like to add is the following, which is a variation of one
> someone (I forget who) posted recently.  Note that this is gridded data,
> unlike the above examples.  Let's call it the 'Sparce Gridded' example, which
> in this case obviates the need to store missing values for ocean points in the
> main array (at the lesser cost of storing missing values in a pointer array):
> 
>     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)

a proposal for sparse data probably could be seperated from coord sys.
proposals. However, I will include this so that we dont forget about
this problem.

...
> SECTION 8: Axes and dimensionality of a data variable
> 
> I like the distinction between 'axes' and 'dimensions'.  But it may be too
> late to change our terminology.  In fact, the very first sentence in this
> section uses 'dimensions' when 'axes' seems to be implied!
> 
> I would state that each axis is associated with a dimension and it is possible
> for several axes to share the same dimension.  I prefer the normal term 'rank'
> to the rather antiquated and clumsy term 'dimensionality'.
> 

can anyone give a precise definition of "axes" ?

in my definitions, rank probably has to mean the number of coord.
functions, while dimensionality might mean the number of dimensions.