Grid Definition Template 3.30: It is wrong to refer to "a secant cone" in octet 66 and 70. All Lambert Conformal projections deal with a tangent cone. One can specify 2 different latitudes where the scale should be equal, which allows one to compute the correct tangent latitude to define the Lambert Conformal projection, in which case one could refer to them as equal scale latitudes. What is erroneous is the concept of some kind of "secant" cone that is going through those latitudes on the earth.
Not clear if in Template 4.8, forecast time is allowed to be negative.
Example: Forecast today's MaxTemp at 8 am. Period is from 7am to 7pm. Reference time is 8 am, Note (2) States that reference time and forecast time together define the beginning of the overall time interval. So "8am and X" = 7 am. One would think X is -1.
The problem comes about when one equates "forecast time" with "projection" which usually refers to the end of the period, in which case X would be 11. Unfortunately Note (2) seems to make this erroneous. Chose to go with forecast time as "projection" hence always positive.
What are the default units? One tends to assume Kelvin / Meters / Seconds / UTC, but as far as I can tell, it is not specified. (In particular with regards to radius of earth in km or m?) Chose to go with assumption
Number of Section("1") From the use of the ""s one might think this is the ASCII representation of 1. Alternatively the words "Number of Section" imply the unsigned integer value 1. The second choice seems to make more sense, since this is intended as a simple flag to the computer that it is in the correct section. Chose to go with the integer value 1
Bit flags: in the GRIB2 specification, bit 1 == 128:
Scan Mode: "bit 2" is: 1 if j increases, while "bit 1" is: 1 if i decreases.
People may specify radius of the earth in KM or M. Based on assumption about default units, we assume M.
If someone specifies shape of earth (octet 15 section 3) as 0, they may figure that they don't then need to provide the radius of the earth in (octet 16, 17-20)
Notes on MDL's GRIB2 Decoder Library
When extracting data using the GRIB2 Decoder library, the returned data has a scan mode = 0100. The library should do the work of rearranging the data from whatever scan mode it was in orginally. It notifies the driver that it has done so by setting the scan mode.
Each GRIB2 message is passed into the decoder library as a 4 byte (octet) integer array, and it must be in "Big Endian" (Most Significant Byte first) format.
Section 2 is packed:
"MDL GRIB2 decoding software examines octet 6 (byte 6) of Section 2 to determine if the local use data was packed by the MDL GRIB2 software."
"The local use data are packed using the simple packing method."
Section 2: IS2 should contain the "total number of groups of local use data". It doesn't (as of 2/21/2003). We don't really need it, because rdat and idat should finish with a "numElements in current group of 0".
Notes on NDFD use of GRIB2
For a single weather element, NDFD stores a 19 byte "Flag Field Separator", a 21 byte "Super Heading time reference", followed by another 19 byte "Flag Field Separator", and a 21 byte "specific heading time reference", and finally the first GRIB2 message. It then continues with a 19 byte "Flag Field Separator", and a 21 byte "specific heading time reference", and the second GRIB2 message. It then continues this way for the remainder of the messages. For multiple weather elements, they simply join the single weather element files together.
Within a given variable, the grids should be sorted with earliest (shortest) forecast time (projection) first.
The NDFD file is "Big Endian" (Most Significant Byte first), since each GRIB2 message is, and the flag fields and super headers are in ASCII.
Each GRIB2 message contains only one Grid.
Notes on degrib
Can't figure out the unpacked size of Section 2 before the call to the unpacker library, so it sets it to max (32 * packed size, 4000), calls the unpacker library, and checks for errors.
Currently does not have meta data support for the following templates:
GS3_ORTHOGRAPHIC = 90
GS3_EQUATOR_EQUIDIST = 110
GS3_AZIMUTH_RANGE = 120
GS4_RADAR = 20
ArcView 3: Can not handle 2 "." in a file name or a path.
Word Perfect 9: when pulling in '|' delimited files, it can't handle "WindDir_10080322.txt" but can handle (the shorter filename) "WindD_10080322.txt"
Some NFS mounted file systems seem to "time out" while writing the 20Meg .shp/.shx/.dbf file set.