Hi Ian:
Not sure if its a bug or not. Do you have a sample file where the
problem occurs?
John
On 7/10/2013 7:05 AM, Ian Will wrote:
I've been using Netcdf Java 4.2 to read GRIB files for a number of
years. I'm excited to try 4.3. One observation when making the switch
is that inverted vertical axes (e.g. Sigma coordinate systems) seem to
have switched natural z ordering in 4.3.
Example, with a sigma coordinate system where positive is down, in 4.2 z
index 29 would provide the lowest layer value. Now it appears that
index 0 provides the lowest layer value.
float sigma(sigma=30);
:units = "sigma";
:long_name = "Sigma level";
:positive = "down";
:Grib1_level_code = 107; // int
:_CoordinateAxisType = "GeoZ";
:_CoordinateZisPositive = "down";
getCoordinateValue(0) returns 10
getCoordinateValue(29) returns 31050
Similarly, an altitude about MSL layer type with positive="up" returns
the highest layer value for index 0 and the lowest for index 29.
float altitude_above_msl(altitude_above_msl=30);
:units = "m";
:long_name = "Altitude above mean sea level";
:positive = "up";
:Grib1_level_code = 103; // int
:datum = "mean sea level";
:_CoordinateAxisType = "Height";
:_CoordinateZisPositive = "up";
getCoordinateValue(0) returns 31050
getCoordinateValue(29) returns 10
I don't mind adapting to the change if its intentional, but the behavior
runs counter to my intuition regarding positive="up" or "down." Does
anyone know anything about this change?
--
Ian Will
Computer Scientist
ian.will@xxxxxxxxxxxx
will@xxxxxxxxxxxxxxxxxxxx
(202) 404-3814
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
