Re: coordinate systems in netcdf (again)

Russ Rew (
Fri, 13 Jun 1997 10:58:41 -0600


Apologies again for sending the previous posting to the whole mailing
list.  The following is what I *intended* to post to the list:

Among other interesting points, John Caron wrote:

> The point is, until we can embed functions (methods) in our netcdf
> files, we cant really represent the above formula in the way it is
> written.  What we can do now, however, is to compute the field
> Pressure(x,y,z) and store it in the netcdf file, and it becomes a
> perfectly good coordinate function for the "altitude" coordinate of a
> georeferencing coordinate system. So the cost is that we have to store a
> 3D field, when all the info is really available in 2 1D fields (a and b)
> and 1 2D field (SurfacePressure).
> Which is just a long example to say that we currently have only arrays
> to represent functions.

This is one of the great promises of "executable content", using Java,
for example.  Data that is stored as an object can map itself to a
canonical coordinate system using a data-specific method, or interpolate
to return the data at a particular location and time.  

The necessary functions may be stored with the data as portable byte
codes that could be loaded into a convenient Java Virtual Machine
running where the data is used, or could reference a remote method that
is transparently downloaded and executed when needed to transform the

There is then no need for applications to support elaborate conventions
for parameterizing dozens of coordinate systems.  Instead, applications
would assume a simple Interface (in the Java sense) for georeferencing
the data, and the data Class would implement the Interface.

But this requires something beyond netCDF.  Unidata is planning to
make available, with help from external developers, the interfaces
necessary to make practical such a division of responsibilities between
data and applications.

In the meantime, well-designed conventions can limit the number of
representations for coordinate systems that applications must
understand.  So, we have to get by with arrays until we have functions



Russ Rew                                         UCAR Unidata Program