Re: NetCDF Digest - Vol 1 : Issue 261

John Caron (caron@dilbert.acd.ucar.edu)
Mon, 19 Jun 1995 11:02:14 -0600 (MDT) 

> On Thu, 15 Jun 1995, Jason Levit wrote:
> 
> >   Hi everyone,
> > 
> >   I'm trying to define a coordinate system in a netCDF data file
> > which includes a stretched vertical grid **with terrain**.  This
> > means that the vertical coordinate is not uniform over the entire
> > domain *or* in a 2-D x-y plane.  In other words, a point at 
> > 3,5,18 will have a physical height of 4.0, but a point at
> > 6,12,18 will have a physical height of 12.0.  If I can use the
> > physical height to define the 3-D coordinate system, that would
> > be great, but I have yet to find a way to define this coordinate
> > system in netCDF.  Does anyone have experience in defining a
> > stretched vertical grid w/terrain in a netCDF file?  If you do,
> > please let me know!  Thanks very much for your help!!
> > 
> >   Jason Levit
> > 

I agree with everything Steve Hankin <hankin@rogue.pmel.noaa.gov> said
about this. I just wanted to give it a more abstract spin:

Your data has a "natural" vertical coordinate system, probably pressure,
or sigma or something.  Your problem is that your application wants it
in a different coordinate system, say km above MSL.  So you need to 1)
code the coordinate transformation routine, and 2) add enough
information to your file so that the transformation routine can be
generic, and the file "self describing". In your case, it might be
putting in the Surface Pressure field, and/or a 3D Pressure field. In
this case you have established a convention for what a file needs to
have in it to be able to work with your application code. So if you are
doing this for long-term problems, you need to document whatever
convention you establish.

A simpler route (from your application point of view) is to do the
coordinate transformation in the process that generates the file.  So
then you would add a 3D field of vertical heights (km above MSL) for
each time step.

There are advantages and disadvantages to each way. I think its useful
to see the problem as a coordinate transformation problem, since other
things such as projective geometry can be viewed similarly.