Hi Bob:
Thanks for reporting this problem. Im looking at it now. Do you have any
idea how these various parameters interact? They have first lat in north,
last lat in south, but a positive Dj. Then with scanMode 64, they say
"Points of first row or column scan in the +j (+y) direction". Seems
overspecified with the possibility of inconsistent results. Im looking
though my data samples now to see if I can detect if there is are problems,
but im not exactly sure what combinations should be legal. Any thoughts?
heres my dump on your record:
47: La1 - latitude
of first grid point == 89938000
56: La2 -
latitude of last grid point == -89938000
68: Dj -
j direction increment == 125000
72:
Scanning mode == 64
On Mon, Jan 12, 2015 at 4:02 PM, Bob Lipschutz - NOAA Affiliate <
Robert.C.Lipschutz@xxxxxxxx> wrote:
>
> Java NetCDF Folks,
>
> We have recently begun generating global 1/8 degree GRIB files
> using NCEP's grid 174 definition (
> http://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html#GRID174).
>
> Following that definition, we are setting the value of scanMode to 64,
> which
> per GRIB2 Table 3.4 indicates "points scan in the +j direction", and so
> filling
> the data arrays from south to north. However, the java-netCDF package
> (v4.5)
> does not seem to handle the scanMode flag properly, and consequently our
> grids appear flipped on display. Meanwhile, I understand that NCL does
> handle
> the data mapping correctly, from which we conclude that java-netCDF is has
> a
> problem with this grid definition.
>
> As a work-around, we will set scanMode to 0 and write from north to south,
> which will fix the problem for us. But, we'd also hope to have the tools
> work
> correctly, too so that we can use the NCEP's grid as specified -- which
> admittedly is strange in that it list the corner lons from north to south.
>
> I've posted a sample GRIB2 file and resulting flipped image here:
>
> ftp://aftp.fsl.noaa.gov/divisions/its/bob/grid174_scanmode_64_example.grb2
> ftp://aftp.fsl.noaa.gov/divisions/its/bob/flipped_174grid.jpg
>
> FWIW, here is the output from the (v4.3) Grib2Dump utility on that data
> file:
>
> Header : GRIB2
> Discipline : 0 Meteorological
> products
> GRIB Edition : 2
> GRIB length : 2808735
> Originating Center : 59 The NOAA Forecast Systems
> Laboratory
> Originating Sub-Center : 0
> Significance of Reference Time : 1 Start of forecast
> Reference Time : 2015-01-08T00:00:00Z
> Product Status : 0 Operational products
> Product Type : 1 Forecast products
> Number of data points : 4147200
> Grid Name : 0 Latitude_Longitude
> Grid Shape: 0 Earth spherical with
> radius = 6,367,470 m
> Number of points along parallel: 2880
> Number of points along meridian: 1440
> Basic angle : 0
> Subdivisions of basic angle: 0
> Latitude of first grid point : 89.938
> Longitude of first grid point : 0.062
> Resolution & Component flags : 48
> Winds : True
> Latitude of last grid point : -89.938
> Longitude of last grid point : 359.938
> i direction increment : 0.125
> j direction increment : 0.125
> Grid Units : degrees
> Scanning mode : 64
> Product Definition : 0 Analysis/forecast at
> horizontal level/layer at a point in time
> Parameter Category : 0 Temperature
> Parameter Name : 0 Temperature
> Parameter Units : K
> Generating Process Type : 2 Forecast
> ForecastTime : 240
> First Surface Type : 1 Ground or water surface
> First Surface value : 0.0
> Second Surface Type : 255 Missing
> Second Surface value : 0.0
>
> Thanks for any insights on this issue!
>
> Bob Lipschutz
> NOAA/ESRL/Global Systems Division
> IT Services/Data Services Group
>
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
