Robert B. Schmunk wrote:
John,
I had a query yesterday from someone trying to use Panoply to plot a
CCCma dataset variable, which despite having lon and lat dimensions
Panoply was apparently declaring unplottable. In trying to figure out
why, I discovered that it is being caused by a bug in determining the
coordinate systems for the variables in the dataset. However, I don't
know this is a bug in NJ22 or in Panoply interpretation of information
it gets from NJ22 methods. The problem occurs no matter whether I use
NJ 2.2.10, 2.2.12 or 2.2.14.
Following is the CDL header info for the dataset. I'll get to a specific
results and question afterword...
netcdf mrsos_a1_sresa2_1_cgcm3.1_t63_2001_2100.nc {
dimensions:
lon = 128; // (has coord.var)
lat = 64; // (has coord.var)
time = UNLIMITED; // (1200 currently) // (has coord.var)
bnds = 2;
variables:
double lon_bnds(lon, bnds);
double lat_bnds(lat, bnds);
double time_bnds(time, bnds);
double depth_bnds(bnds);
float mrsos(time, lat, lon);
:standard_name = "moisture_content_of_soil_layer";
:long_name = "Moisture in Upper 0.1 m of Soil Column";
:units = "kg m-2";
:cell_methods = "time: mean (interval: 15 minutes)";
:coordinates = "depth";
:original_name = "WGL+WGF (top lay";
:comment = "includes subsurface frozen water but not surface snow
and ice";
:history = " At 16:29:32 on 08/29/2005: CMOR altered the data in
the following ways: converted from type "double" to type "real";";
double lon(lon);
:standard_name = "longitude";
:long_name = "longitude";
:units = "degrees_east";
:axis = "X";
:bounds = "lon_bnds";
:_CoordinateAxisType = "Lon";
double lat(lat);
:standard_name = "latitude";
:long_name = "latitude";
:units = "degrees_north";
:axis = "Y";
:bounds = "lat_bnds";
:_CoordinateAxisType = "Lat";
double time(time);
:standard_name = "time";
:long_name = "time";
:units = "days since 1850-1-1";
:axis = "T";
:calendar = "365_day";
:bounds = "time_bnds";
:_CoordinateAxisType = "Time";
double depth;
:standard_name = "depth";
:long_name = "depth";
:units = "m";
:axis = "Z";
:positive = "down";
:bounds = "depth_bnds";
:_CoordinateAxisType = "Height";
:_CoordinateZisPositive = "down";
}
Okay, now here's what happens that I don't understand...
Panoply begins it examination each variable in this dataset by
constructing a VariableDS.
It then executes the getCoordinateSystems() method of that varDS.
The following variables are reported as having coordinate systems
of size 1 (all others are 0 size): lon_bnds, lat_bnds, time_bnds,
depth_bnds, mrsos.
Now here is what I don't understand, on each of these five variables
when Panoply extracts its CoordinateSystem and executes the
hasVerticalAxis() method, the answer coming back is _true_.
Further, calling CoordinateSystem's getPressureAxis, getHeightAxis,
and getZaxis methods to find out what this supposed vertical axis
might be, getHeightAxis() returns the "depth" variable.
Subsequently calling getShape() on the vertical axis, the result
coming back is an array as expected but it has length 0. (This is
where Panoply wiped out on a bad array index exception, as it was
trying to look up the first value in that array.)
So what is confusing me is, why does the CoordinateSystem for these
variables report that they have a vertical axis? And why do they
report that that axis is a dimension that they don't even use?
Is this expected behavior from NJ22 and am I mis-understanding
what a CoordinateSystem should include?
This is the correct behavior for the mrsos variable, which is the only data
variable. The depth coordinate happens to be a scalar, which is a valid rank
for a coordinate variable.
The depth coordinate should not have been assigned to the other variables, its an artifact of useing a greedy algorithm to assign coordinates. I would have thought that since you would have ignored these since they dont have isLatLon = true? Anyway, I have a note to see if I can eliminate this problem, but it will be a bit tricky to do so and not break some other cases. So best to work around it if you can.
Thanks for reporting the problem!
