NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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/
netcdf-java
archives: