zyGrib

Hi Jacques,

I have noticed that the encoding of the jDirectionIncrementInDegrees within the GRIB record doesn't seem to be correct. As you can see below (decoded by the ECMWF GRIB API) it is showing as 33.268 degrees when I'm expecting 0.5 degrees. This is causing some issues when trying to use zyGrib GRIBs on other GRIB readers such as tablet and phones. Of course it's possible using the redundant information in the GRIB to avoid using this field but I was wondering for the sake of interoperability if you might consider correcting this?

Cheers,
Nicko

***** FILE: /Users/nicko/Documents/Weather/gribs/20131013_090605_.grb
#============== MESSAGE 1 ( length=3561 ) ==============
GRIB {
editionNumber = 1;
table2Version = 2;
# US National Weather Service - NCEP (WMC) (grib1/0.table)
centre = 7;
generatingProcessIdentifier = 81;
# MSL Mean sea level pressure Pa (grib1/2.0.2.table)
indicatorOfParameter = 2;
# Mean sea level 0 0 (grib1/3.table)
indicatorOfTypeOfLevel = 102;
level = 0;
# P1 occupies octets 19 and 20; product valid at reference time + P1 (grib1/5.table)
timeRangeIndicator = 10;
# Unknown code table entry ()
subCentre = 0;
paramId = 151;
#-READ ONLY- units = Pa;
#-READ ONLY- nameECMF = Mean sea level pressure;
#-READ ONLY- name = Mean sea level pressure;
decimalScaleFactor = 1;
dataDate = 20131013;
dataTime = 0;
# Hour (stepUnits.table)
stepUnits = 1;
stepRange = 0;
startStep = 0;
endStep = 0;
#-READ ONLY- marsParam = 2.2;
shortName = msl;
GDSPresent = 1;
bitmapPresent = 0;
numberOfVerticalCoordinateValues = 0;
Ni = 47;
Nj = 37;
latitudeOfFirstGridPointInDegrees = -26;
longitudeOfFirstGridPointInDegrees = 138;
earthIsOblate = 0;
uvRelativeToGrid = 0;
latitudeOfLastGridPointInDegrees = -44;
longitudeOfLastGridPointInDegrees = 161;
iScansNegatively = 0;
jScansPositively = 0;
jPointsAreConsecutive = 0;
#-READ ONLY- alternativeRowScanning = 0;
jDirectionIncrementInDegrees = 33.268;
iDirectionIncrementInDegrees = 0.5;
#-READ ONLY- numberOfDataPoints = 1739;
#-READ ONLY- numberOfValues = 1739;
missingValue = 9999;
#-READ ONLY- binaryScaleFactor = 1;
#-READ ONLY- referenceValue = 940665;
sphericalHarmonics = 0;
complexPacking = 0;
integerPointValues = 0;
additionalFlagPresent = 0;
packingType = grid_simple;
bitsPerValue = 16;

Hi,

jDirectionIncrementInDegrees is not a grib parameter, but a computed value by your application.
It is probably a bug here.

There is no inconsistencies in the grib header generated by the zyGrib server (this is regulary tested).

Hi Jacques,

These two fields correspond to Di and Dj (from the GRIB spec)
24-25 Di - i direction increment
26-27 Dj - j direction of increment
28 Scanning mode (flags - see Code table 8)

However looking around there is some difference of opinion as to whether these are signed two byte integers (as zyGrib assumes) OR unsigned two byte integers that use the scanning mode flags to determine sign/direction. ECMWF and jgrib assume unsigned. UCAR and wgrib assume signed. I guess given that it's unlikely that one will need a resolution of bigger than 32.767 (2^31/1000) it is better to assume that they are signed as you have done.

A+,
Nicko

Hi,
The zyGrib file generator is strictly compliant to the GRIB format definition of the World Meteorological Organization (FM 92-IX).
This definition is not ambiguous.
...
Octets 11 - 13 La1 - latitude of first grid point units: millidegrees (degrees x 1000)
values limited to range 0 - 90,000 bit 1 (leftmost) set to 1 for south latitude
...
Octets 26 - 27 Regular Lat/Lon Grid:
Dj - Latitudinal Direction Increment (same units as La1)
(if not given, all bits set = 1)
...