[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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