Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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!
netcdf-java archives: