Re: 2D coordinate variables

John Sheldon (jps@gfdl.gov)
Thu, 15 May 1997 15:08:33 -0400 (EDT) 

> Hmmm, I was wondering what happened to this group....

It has been pretty quiet lately...maybe the new release (3.3) will
spark an increase in activity!...

> Heres a belated comment on the problem of 2d coordinate varibales:
> 
> > > I was wondering if there was any way in the netCDF standard to have a 2-d dim-
> > > ension grid, ie, N "coordinates" each of which is a lat-lon pair, and then each
> > > field is defined on that grid.
> > 
> > Yes, I did something like this for the UWM/COADS data set (see CDL
> > below). The problem is that no software appear able to read it
> > directly. In retrospect, I believe it was a mistake, we should have
> > adopted something like the COARDS conventions (which I don't whether it
> > existed back in 1990).
> 
> I dont see anything in COARDS that deals with this. I have the May 1995
> doc. Is there something more recent?

Not that I'm aware of...(Steve Hankin...You out there?)  
(---but I'd be interested to hear from anybody out there who has come
up with a scheme for storing time-averaged data!...)

> > Actually, this idea goes back quite a way.  The concept of "referential
> > attributes" was laid out in a report from the NetCDF Users Working
> > Group (NUWG) back in 1992.... 
> 
> A more obvious generalization of coordinate variables to the 2D case I
> think is:
> 
> 	float mydata(time, lev, lat, lon);
> 
> // coordinate system
> 	float lev(lev);
> 	float lat(lat, lon);
> 	float lon(lat, lon);
> 
> I would like to hear any arguments against this idea, other than the
> obvious that its not (yet) a convention.

Well, the biggest problem with it is that most software out there will
choke on it.  This is mainly because there is already a very strong
convention about how to interpret "coordinate variables".  From the
netCDF manual:

 (http://www.unidata.ucar.edu/software/netcdf/guide_4.html#SEC21)

  "A variable with the same name as a dimension is called a coordinate
   variable. It typically defines a physical coordinate corresponding
   to that dimension."..."Note that each coordinate variable is a
   vector and has a shape consisting of just the dimension with the
   same name."..."Current application packages that make use of
   coordinate variables commonly assume they are numeric vectors and
   strictly monotonic (all values are different and either increasing
   or decreasing). There are plans to define more general conventions
   to allow such things as text labels as values of coordinate
   variables."

Now, that last line does seem to leave open the possibility of changing
how coordinate variables are interpreted, and there is certainly
nothing to stop you from storing your data in the proposed fashion
(technically, your approach works, as can be verified with the attached
"sample_1" CDL file).  But I suspect that most applications will not be
able to deal with it (at least not the way you expect!).  

There is one other mention in the manual that application developers
are likely to point to if you try to "change the rules" on them:

 (http://www.unidata.ucar.edu/software/netcdf/guide_12.html#IDX747)

  "A variable may have the same name as a dimension; by convention such
   a variable contains coordinates of the dimension it names."

Referential attributes, on the other hand, offer fertile ground for
expanding the documentation of the content of netCDF files, and would
offer a perfectly acceptable way to document the hypothesized data.
I'd suggest you take that route and try to get others to follow you,
rather that trying to double back against traffic :-)

John P. Sheldon

PS: I am also attaching a "ref_atts" CDL file which is an additional
alternative to the solution posed back in March.  Note that this has
the advantage that the variable "mydata" retains its 4-D character,
which could make later interpretation easier. In any case, the
downstream application(s) will have to be able to figure out how to
use the information you are giving to it.

======================================================================
netcdf sample_1 {
dimensions:
        lon = 4 ;
        lat = 3 ;
        lev = 2 ;
        time = UNLIMITED ; // (1 currently)
variables:
        float lon(lat,lon) ;
        float lat(lat,lon) ;
        float lev(lev) ;
        double time(time) ;
	float mydata(time, lev, lat, lon) ;

data:
 
 lev = 1000, 2000 ;
 
 time = 24 ;

 lon = 10, 20, 30, 40,
       11, 21, 31, 41,
       12, 22, 32, 42 ;

 lat = 1.0, 2.0, 3.0, 4.0,
       1.1, 2.1, 3.1, 4.1,
       1.2, 2.2, 3.2, 4.2 ;
 
 mydata = 1,2,3,4,
          5,6,7,8,
	  9,10,11,12,
	  13,14,15,16,
	  17,18,19,20,
	  21,22,23,24 ;
}

======================================================================
netcdf ref_atts {
dimensions:
        ni = 4 ;
        nj = 3 ;
        lev = 2 ;
        time = UNLIMITED ; // (1 currently)
variables:
        float lev(lev) ;
        double time(time) ;
	float mydata(time, lev, nj, ni) ;  // this def'n retains 4-D shape
	   mydata:nj = "latarr";   // => get latitudes from variable "latarr"
	   mydata:ni = "lonarr";   // => get longitudes from variable "lonarr"
	float latarr(ni,nj) ;	 // you'll have to be smart enuough to realize
	float lonarr(ni,nj) ;    // how to interpret this (ie, from its shape)

data:
 
 lev = 1000, 2000 ;
 
 time = 24 ;

 lonarr = 10, 20, 30, 40,
          11, 21, 31, 41,
          12, 22, 32, 42 ;

 latarr = 1.0, 2.0, 3.0, 4.0,
          1.1, 2.1, 3.1, 4.1,
          1.2, 2.2, 3.2, 4.2 ;

 mydata = 1,2,3,4,
          5,6,7,8,
	  9,10,11,12,
	  13,14,15,16,
	  17,18,19,20,
	  21,22,23,24 ;
}