Re: [netcdf-java] Inverted vertical axis change in 4.3?

Hi Ian:

Not sure if its a bug or not. Do you have a sample file where the problem occurs?


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
(202) 404-3814

netcdf-java mailing list
For list information or to unsubscribe, visit:

  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: