20030326: netCDF axes out of order

Hi John-

Donahue, John F. wrote:
>         I sent you an e-mail a few weeks ago, at the suggestion of Capt.
> Gonzalez at AFIT, about problems I'm having reading in a netCDF data set. I
> sent you a small cdl file to illustrate the problem, but unfortunately it
> had a bug in it, too. That's been taken care of in this example. 
> You may recall the problem I have is that the netCDF file has its axis order
> in satellite-data order - the Z axis is the most-rapidly varying one, the
> data is a presented as a set of soundings, instead of the more set of 2-d
> sheets. When I read in the data, the 2-D data (shelter temperature) is
> displayed OK, and the
> 3-D Temperature data displays ok if you do a color-shaded plan view, though
> the data is scrambled. I get the follwing an error if I try to do a
> color-shaded vertical cross section:
>
> ERROR ucar.unidata.idv.control.GridDisplayControl - An exception has
> occurred
> Initializing the csSelector
> visad.RealTuple
> java.lang.ClassCastException: visad.RealTuple
>         at
> ucar.unidata.idv.control.CrossSectionControl.make2DData(CrossSectionControl.
> java:563)
>         at
> ucar.unidata.idv.control.CrossSectionControl.loadData(CrossSectionControl.ja
> va:447)
>         at
> ucar.unidata.idv.control.CrossSectionControl.loadDataFromLine(CrossSectionCo
> ntrol.java:432)
>         at
> ucar.unidata.idv.control.CrossSectionControl.initDone(CrossSectionControl.ja
> va:175)
>         at
> ucar.unidata.idv.control.DisplayControlImpl.init(DisplayControlImpl.java:451
> )
>         at
> ucar.unidata.idv.ControlDescriptor.initControl(ControlDescriptor.java:236)
>         at
> ucar.unidata.idv.ControlDescriptor.access$000(ControlDescriptor.java:63)
>         at
> ucar.unidata.idv.ControlDescriptor$1.run(ControlDescriptor.java:221)
>         at ucar.unidata.util.Misc$1.run(Misc.java:778)
>
> The GDV conventions specify that the axes can be in any order by from
> looking at the IDV code it appears that X_DIM, Y_DIM, and Z_DIM are all
> hard-coded in  metapps/ucar/unidata/grid/GeoCoordSysImpl.java. If there is
> some simple fix to this, it would be greatly appreciated. I've been able to
> convince the supplier of the nerCDF file to add GDV conventions to it, but
> the data order is fixed.

I'm not sure it's the order of axes that is screwing this up.
When the GeoCoordSysImpl is constructed, it sets the indices
of the axes for which is X, which is Y, etc.  The statics look
to be just used in the VMDConventions, not in GDV.

Is it possible for you to send me a file or put one out on
an FTP server instead of just the cdl?

The person who is the expert at this is out of town this week, but
if you can send me a file, I can see what I can do.

I think I mentioned it in a previous note, but we are going to
be revamping how we do the netCDF grid adapter in the next
few weeks to make it more robust.  This might clear up the
problems you are having if I can't fix the existing code.
Also, we are recommending that people migrate toward CF
conventions.  The next version of CF will include support for
projections specifications.  Basically, that's what you are
getting the most of in GDV Conventions.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
address@hidden                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************