20030328: netCDF axes out of order

Hi John-

Just following up.

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)

This is a problem with the CrossSectionControl assuming that
a cross section grid always had time in it.  For your T variable,
there is not time dimension.

> 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.

As I mentioned previously, the conventions are handling this
okay.  The problem is with the GeoGridAdapter not handling the
reordered dimensions.  It was assuming t,z,y,x ordering.

Both problems were bugs and will be fixed in the next release.
The two files (ucar.unidata.idv.control.)CrossSectionControl
and (ucar.unidata.data.grid.)GeoGridAdapter were both updated and
can be found in the metapps_src.jar in the
ftp://ftp.unidata.ucar.edu/pub/metapps/untested directory.  Note
that files in this directory are not completely tested and are
not guaranteed to work with the version of IDV that you are using.
You could do diff's between the new versions and your existing versions
to see what changes have been made.  For CrossSectionControl, the
changes are confined to the make2DData method.  For GeoGridAdapter,
the changes are in the getFlatField and get1DValues methods.

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
*************************************************************