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

Hi Ian:

Thanks for your test files and test code.

There is no ordering implied in the vertical coordinate (or any other coordinate, except for the time coordinate in some cases), other than it must be monotonic. So user code must be able to deal with ascending or descending coordinates. So the 4.3 code is technically correct.

However, you are right that its current sort order is nonintuitive, and a change from 4.2. In fact, I didnt intend to sort it the way that you see it in the 4.3 GRIB code. The GRIB records are not ordered, so one must do a sort on these records, so one might as well sort them in some intuitive way. (Note this is diferent from netcdf, where the writer has put the coordinates in one sorted way or the another, and the CDM wont change that.)

So I would just change it so that in the future the sort order is the intuitive one, but Im not sure what happens to GRIB collections if some of the files are sorted one way, and some the other. So I have to check that out before deciding if i can easily make this change.

Thanks for reporting this!


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: