Re: 2D coord variables

John Caron (caron@ucar.edu)
Fri, 16 May 1997 11:03:40 -0600 

> > 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".
> ...
> 
> 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 :-)

I agree that existing applications that assume 1D coordinate variables
will break, as evidenced by Steve Hankin's post about Ferret (hey - how
come his post isnt in the digest?). I agree that this is a Bad Thing.

But let me argue the point, to try to state what I perceive the
trade-offs to be.

Consider the problem of using 2D coordinate variables.  Applications are
going to have to be extended in order to do this.  What happens when an
old application runs across a 2D coord field? Either it barfs or it
ignores the coordinate field. Which is more correct depends on what the
application is doing with the coordinate information.  For
georeferencing, which was the original question and the only example I
have in my mind of 2D coord vars, it probably might as well barf.  

If you agree we have to recode in all cases, why not do it right?  2D
coordinates are better than a referential attribute because its
simpler.  So I would advocate adding this convention right into the
netcdf manual paragraphs on conventions about coord vars. (You note that
I havent actually tried to say what the convention is).  Hey, its only a
convention, were not asking for any API changes!! :^)

Having said that,  I understand that referential attributes are already
in use and an elegent solution for problems where you need two 1D
coordinates (eg reference time, forecast time) which by the way is the
problem that the NUWG actually solved, not 2D coordinates.  I see from
your example below that you realized this and made the obvious
generalization to the 2D case.

So its not that I dislike referential attributes, although I would like
their semantics more clearly and more generally stated than the NUWG has
done so far.    

Lest you think this is pure abstraction, the CSM netdf conventions group
has discussed this very topic and will have to make some decisions soon
on it.  The problem comes up (among others) when your data is on a
projection surface, and you want to specify the coordinate system in
lat/lon.


> 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 ;
> }