Re: [netcdf-java] 2 fix on GRIB1 reader

The first part of the patch is ok. (the copy/paste error)
For the second part I not sure anymore, you can leave it aside for the moment. 
Someone with a better knowledge of grib will have to verify it.

Johann Sorel
Geomatys


On 02/11/2012 21:07, John Caron wrote:

Hi johan:
netcdf doesnt care what order the data is in. i dont think GRIB does either, but im not as sure. The only criterion is that the coordinate indices must match the data, eg lat(i), lon(j) correctly matches data(i,j). 

with that understanding, does the patch for GRIB-1 need to be revised?

On 11/2/2012 9:18 AM, johann sorel wrote:

I guess I understand what's going on, Grib and Netcdf conventions
declare their datas in a different order.

So what do we choose ?
1 - leave it like it is and it's the user work to iterator in the
inverse order if file_format = "GRIB-X"
2 - flip the datas directly in the reader to match netcdf order, ( for
all grib projections, painful job )

Does someone know how it's handle in other readers ?

Johann Sorel
Geomatys


On 02/11/2012 12:25, johann sorel wrote:

Hello again,

I have a similar problem, this time on NOAA grib 2 data with LatLon
projection.
values are flipped along the latitude axis again (same as bug 2 I
reported previously)

this starts to make me think the problem might be in geotoolkit.
But usual netcdf files are displayed properly ...

I would like to have a confirmation, here is a partial dump obtained
with class NCDumpW :
What I would like to know is : the line marked #1 is for latitude +78
or -78 ?

netcdf /..../somegrib.grib2 {
 dimensions:
   lon = 288;
   lat = 157;
   time = 61;
 variables:
   float lat(lat=157);
     :units = "degrees_north";
   float lon(lon=288);
     :units = "degrees_east";
   int time(time=61);
     :units = "Hour since 2012-10-30T06:00:00.000Z";
     :standard_name = "time";
   float
Wind_direction_from_which_blowing_degree_true_surface(time=61,
lat=157, lon=288);
     :long_name = "Wind direction (from which blowing) (degree true) @
Ground or water surface";
     :units = "deg";
     :missing_value = NaNf; // float
     :abbreviation = "WDIR";
     :grid_mapping = "LatLon_Projection";
     :Grib_Variable_Id = "VAR_0-2-0_L1";
     :Grib2_Parameter = 0, 2, 0; // int
     :Grib2_Level_Type = 1; // int
     :Grib2_Generating_Process_Type = "Forecast";
....

 data:
lat =
  {78.0, 77.0, 76.0, 75.0, 74.0, 73.0, 72.0, 71.0, ... , -74.0, -75.0,
-76.0, -77.0, -78.0}
lon =
  {0.0, 1.25, 2.5, 3.75, 5.0, 6.25, 7.5, 8.75, 10.0, ... , 355.0,
356.25, 357.5, 358.75}
time =
  {0, 3, 6, 9, 12, 15, 18, 21, 24, ... , 174, 177, 180}
Wind_direction_from_which_blowing_degree_true_surface =
  {
    {
      {56.78, 57.72, 61.87,... },    #1
      {56.78, 57.72, 61.87,... },
      {107.14, ... },
      ...
   }
}


thanks.

Johann Sorel




On 02/11/2012 02:18, John Caron wrote:

Hi johann :

Thanks very much, these fixes will be in target-4.3.14 later tonight.

John

On 10/31/2012 5:41 AM, johann sorel wrote:

Hello,

I work with martin desruisseaux on the geotoolkit.org project.

While trying to access datas from :
http://www.globalmarinenet.com/grib_downloads.php I found a few bugs in 
the grib1 to netcdf metamodel.
Those are GRIB 1 files with LatLon projections.

grib/src/main/java/ucar/nc2/grib/grib1/Grib1Gds.java$LatLon

There was 2 bugs in this projection creation :

1 - a copy/paste error when calculating the latitude delta.

if (!Misc.closeEnough(deltaLat, calcDelta)) {
   log.debug("deltaLat != calcDeltaLat");
   deltaLat = calcDelta;  ----> was deltaLon = calcDelta;
}

2 - wrong value order when datas start by the lower values.

BEFORE
   if (deltaLat != GribNumbers.UNDEFINED) {
         deltaLat *= scale3; // undefined for thin grids
         if (la2 < la1) deltaLat *= -1.0;
   } else deltaLat = calcDelta;

AFTER
     if (deltaLat != GribNumbers.UNDEFINED) {
         deltaLat *= scale3; // undefined for thin grids
         if (la2 < la1) {
             //flip declaration order
             float latemp = la1;
             la1 = la2;
             la2 = latemp;
             calcDelta *= -1.0;
//we must also consider the cell corner, since we flipped 
the order
             //we should specify that the true value is at the
BOTTOM-LEFT corner
//but we can't show this information so we make a one cell 
displacement
             //to move the value on a TOP-LEFT corner.
             la1 -= calcDelta;
             la2 -= calcDelta;
         }
       } else {
           deltaLat = calcDelta;
       }
I attached a snapshot of the visualized datas before and after fix over 
the indian ocean and the patched java class.


Johann Sorel
Geomatys





_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/



_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/


_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/