• Grib1 To Grib2 Converter Temperature In Fahrenheit
• Grib1 To Grib2 Converter Temperature Calculator

GRIB1 & GRIB2 Major Differences. One GRIB2 message can contain multiple fields.Sequences of GRIB sections 2 to 7, sections 3 to 7 or sections 4 to 7 may be repeated within a single GRIB message. Once a section is repeated all the following sections must appear in order.

I need to get data for my database from some GRIB files (binary), I downloaded wgrib2, which can export GRIB-2 files to .csv and csv is very suitable for me, but some GRIB files are GRIB-1, so I used wgrib2 on them and program wgrib2 told me: 'grib1 message ignored (use wgrib)', so I used wgrib, but wgrib can't export files to different format. So I tried to install recommended cnvgrib to convert GRIB-1 to GRIB-2, but still getting some errors during installation due different library versions, 32/64 bit problem, different directories etc., it's written in Fortran, that's also the problem I can't compile it easily...

So is there another way to convert GRIB-1 files to GRIB-2 (or to some non-binary format)? I can google many ways to do it, but I need help from some1 who have already converted GRIB-1 to another format, because there can be some easy way how to do that, but I have so much pain fixing installation problems, wrong configurations, Fortran version incompatibilities etc during installation of cvngrib, which I haven't even fixed and gave up...

EDIT: OK, my co-employee fixed degrib (it linked own libraries with newer system libraries), so I can run degrib now. So I run 'degrib 'GRIB file' -C -msg all -nMet -Csv' on GRIB-1 file and it failed the conversion to .csv with:

I try to fix it soon, but meanwhile you can help me again!

3 Answers

Try using degrib, which is a product of National Weather Service's Meteorological Development Lab (NWS MDL).

It can convert GRIB1 and GRIB2 to several different formats. It won't be able to convert GRIB1 directly to GRIB2, but you should be able to convert GRIB1 to CSV or another format. The tutorial page is the best source for usage information (follow the link to the man page for detailed usage info).

Use 'gdal_translate' see http://www.gdal.org/gdal_translate.html

should do the job for you.

will give the formats; GRIB is input-only; there are lotsof GIS formats available as outputs.

See http://www.gdal.org/index.html for GDAL, generally. It isa really powerful translator-library/utility-programs set.

ECMWF's GRIB API has a tool for this changing of GRIB files, called grib_set. According to example 5 at its manual page, you can set any GRIB 1 to GRIB 2 like this:

And the rest of the conversion will be mostly done correctly.

Not the answer you're looking for? Browse other questions tagged convertcsvgrib-2 or ask your own question.

A GUIDE TO THE CODE FORM FM 92-IX Ext. GRIB Edition 1

(Technical Report No.17, Geneva, May 1994 (WMO TD-No.611)

TABLE OF CONTENTS

Introduction
GRIB Code Form
Section 0: The indicator section
Section 1: The product definition section
Section 2: Grid description section
Section 3: Bit map section
Section 4: Binary data section
Section 5: End section

The World Meteorological Organization (WMO) Commission for Basic Systems (CBS) Extraordinary Meeting Number VIII (1985) approved a general purpose, bit-oriented data exchange format, designated FM 92-VIII Ext. GRIB (GRIdded Binary). It is an efficient vehicle for transmitting large volumes of gridded data to automated centers over high-speed telecommunication lines using modern protocols. By packing information into the GRIB code, messages (or records - the terms are synonymous in this context) can be made more compact than character oriented bulletins, which will produce faster computer-to-computer transmissions. GRIB can equally well serve as a data storage format, generating the same efficiencies relative to information storage and retrieval devices.

Changes and extensions to GRIB were approved at the regular meeting of the WMO/CBS in February 1988; additional changes were introduced at the CBS/WGDM/Sub-Group on Data Representation (SGDR) meetings in May 1989 and in October 1990. The 1990 changes were of such structural magnitude as to require a new Edition of GRIB, Edition 1, which this document describes. The Sub-Group made further augmentations and interpretations on Data Representation and Codes (SGDRC) in September 1993, with approval by the WGDM in February 1994. These changes did not result in a new Edition to GRIB, but did change some of the Tables, resulting a new Version number for them. This brings us now to Table Version 2. The changes from Version 1 were mainly additions of new parameters or more precise definition of existing ones.

It is not anticipated that there will be any large-scale structural changes to GRIB for at least four to five years, or more. The SGDRC is undertaking a thorough review of the present and future requirements that GRIB is supposed to satisfy. The plan is to design a major revision of GRIB capable of accommodating these requirements and more, without 'straining' the structure of the data representation form. Some things are getting a little strained even now. See below.

Note: the Edition number is placed in the same location, relative to the start of the GRIB message, for all Editions. Thus, decoding programs can detect which Edition was used to construct a particular GRIB message and behave accordingly. This is useful for archives of messages encoded in earlier Editions or during transition periods. Of course, this requires that data centers retain copies of older editions of the code, and older versions of the parameter tables.

Each GRIB record intended for either transmission or storage contains a single parameter with values located at an array of grid points, or represented as a set of spectral coefficients, for a single level (or layer), encoded as a continuous bit stream. Logical divisions of the record are designated as 'sections', each of which provides control information and/or data. A GRIB record consists of six sections, two of which are optional:

(0) Indicator Section
(1) Product Definition Section (PDS)
(2) Grid Description Section (GDS) - optional
(3) Bit Map Section (BMS) - optional
(4) Binary Data Section (BDS)
(5) '7777' (ASCII Characters)

Although the Grid Description Section is indicated as optional, it is highly desirable that it be included in all messages. That way there will be no question about just what is the 'correct' geographical grid for a particular field.

Most centers require bulletin headers to enable them to receive, identify, and switch messages. The standard WMO abbreviated heading for GRIB is described in Appendix A.

In this documentation, certain symbols are used to clarify the contents of octets (groups of eight consecutive binary bits). If unadorned letters are used, they are symbolic and their meanings are described in the text; a decimal number is simply printed as is; a character or string of characters is represented inside single quote marks. International Alphabet No. 5, which is identical in its essential elements to the U.S. National Standard 7-bit ASCII, is used for character representation in the GRIB code.

Octets are numbered consecutively from the start of each section; bits within an octet are also numbered from left (the most significant bit) to right (the least significant bit). Thus an octet with bit 8 set to the value 1 would have the integer value 1; bit 7 set to one would have a value of 2, etc.

The numbering of Tables in the following text corresponds to the description of GRIB in the WMO Manual on Codes. Some additional tables not found in the WMO Manual are indicated by letters. These, generally, contain information unique to a particular processing center.

A caveat: The Official International Documentation for GRIB is the just referenced Manual on Codes. This document is, in part, intended to be a guide to the use of GRIB and may not include all of the features currently found in the Manual. The features described here are intended to be a completely consistent sub-set of the full WMO documentation; if there are any discrepancies the Manual on Codes is the final authority.

DATA PACKING METHODS

The code form represents numeric data as a series of binary digits (bits). Such data representation is independent of any particular machine representation; by convention data lengths are measured in octets. Data are coded as binary integers using the minimum number of bits required for the desired precision. Numeric values, with units as shown in Table 2, may first be scaled by a power of ten to achieve an appropriate decimal precision, a reference value is subtracted from them to reduce redundancy and eliminate negative values, and they may then be further scaled by a power of two to pack them into a pre-selected word length. The two scaling operations are independent; which, or both, are used in any given case depends upon choices made as to the method of packing. See below.

The representation of a single value is such that:

Y x 10^D = R + (X x 2^E)

Where

Y = original or unpacked value; units as in Table 2;
D = decimal scale factor, to achieve desired precision
(sign bit, followed by a 15-bit integer);
R = reference value (32 bits);
X = internal value (No. of bits varies for each record);
E = binary scale factor for variable bit word length packing
(sign bit, followed by a 15-bit integer).

The reference value (R) is the minimum value of the (possibly) decimally scaled data that is being encoded.

R is placed in the Binary Data Section in four octets as a single precision floating-point number:

sAAAAAAA BBBBBBBB BBBBBBBB BBBBBBBB

where s = sign bit, encoded as 0 => positive, 1 => negative
A = 7-bit binary integer, the characteristic
B = 24-bit binary integer, the mantissa.

The appropriate formula to recover the value of R is:

R = (-1)^s x 2^(-24) x B x 16^(A-64)

This formula is the standard IBM representation for a single precision (real) floating point number. (Consideration is being given to using the IEEE floating point representation in the future, in a later Edition of GRIB.)

If second order (or 'complex') packing is used (see the description of that later on) the internal value, X, will be made up of two values, a 'local minimum value', Xi, and a 'second order packed value', Xj. There will be one Xj for each grid point and a variable number of Xi values. This will all become clear later on when we get to the description of second-order packing.

What follows is a description, slightly simplified, of the process that one would go through to pack a (meteorological) field into a GRIB message, using 'simple packing'. It includes some explanations of why certain steps are taken, some of the consequences, and what choices have to be made. Some of the choices are interrelated; the relationships should be clear when the explanation is done. The additional features of complex or 'second order' packing will be dealt with in a later section.

Give that a full field is available, the first step, if necessary, is to convert the units of the parameter into those shown in Table 2, the SI standard units, also known as the mks system. Some of the units may seem a little peculiar (kg/m², for example, for precipitation - 1 kg/m² is equivalent to a water depth of 1 mm); others may seem inappropriate (Pa for pressure, for example, implies substantially greater precision than is typical in meteorological usage; inverse seconds are not nearly precise enough for divergence and vorticity) but they are all self consistent. The precision of the parameters, as actually packed in a message, can be set to any desired degree through the appropriate use of the power-of-10 ('D') scaling and the power-of-2 ('E') scaling. Just how this comes about will be described momentarily.

At this point there is a choice to be made. If it is desired to use a pre-selected bit word length for the packed variables, then just proceed on to the next step. However, if a variable bit word length is to be used, where the word length is adjusted to accommodate the data values, then it is necessary to undertake the power-of-ten scaling. The D value should be selected such that, when the original data, in the SI units of Table 2, is multiplied by 10^D, the integer part of the result will have enough precision to contain all the appropriate information of the variable. Anticipating things a little bit, the (scaled) value will be rounded to an integer as a part of the packing process; thus the 'significant part' of the value of the variable has to be moved to the left of the decimal point prior to the rounding. Temperature might be scaled with D=1, thus changing the units to deci-degrees; pressure, on the other hand, might be scaled with D=-2, thus actually reducing the precision to hectoPascals (mb), a more reasonable meteorological precision; vorticity would be scaled up by D=8, and so on.

The second step in the packing operation is to scan through the field, which may or may not have been 'D-scaled' at this point, find the minimum value of the parameter, and subtract that minimum - the reference value, R - from all the data points, leaving a residual of non-negative numbers. This step has two benefits. The first of these is convenience - making all the data points non-negative bypasses problems with different computer hardware that represent negatives in various ways: 1's complement, 2's complement, signed positive integers, whatever. The GRIB message is rendered just that much more machine independent by being non-negative throughout.

The second benefit is more consequential: it can result in a substantial compression of the bulletin size without any loss of information content. If a field has an appreciable bias away from zero, the residuals formed by the minimum removal operation will all be much smaller numbers than otherwise. Thus they will need fewer bits to contain them when they are, eventually, packed as integers.

The third step is simply to scan through the field of residuals and find the maximum value.

At this point another choice must be made, similar to the one made previously. This time, if a variable bit word length is to be used, then it is necessary to calculate how many bits (per word or per data grid point) are going to be needed to contain that largest data value, when the latter has been rounded to an integer. Recall that at the previous decision point, the variables were power-of-ten ('D') scaled such that a rounding operation will preserve all the significant part of the information. Discovering how many bits are needed is a simple scan through a table of powers of two, of course. The power-of-two-scaling is not employed and E is set equal to 0. Then go on to the fourth step.

If, alternatively, it is desired to use a pre-selected bit word length for the packed variables, the data must now be scaled, this time by a power of two (the 'E' scaling), sufficient to either reduce the maximum value down to just fit into the available number of bits, or enlarge the value to just fit. This latter step takes care of the problem of small numbers where the precision is all in the fractional part of the number. How much precision is retained, for the eventual rounding, is a function of the pre-selected bit word length and the 'typical' range, or maximum value with the minimum removed, of the particular variable. The choice of bit word length, which is made ahead of time, must be made with full knowledge of the characteristics of the particular variable that is to be packed and a prior assumption of how much precision needs to be retained for the largest likely value.

The fourth step is to round all the values to integers, now that they have all been scaled to appropriate units, and pack them in the specified bit length words.

The last step is then to set up the various identification fields and put the GRIB bulletin in proper form. We shall turn to this 'proper form' in the next section.

We have ended up with two alternate ways to construct a GRIB messages: a fixed bit word length method and a variable bit word length method. What are the relative advantages or disadvantages, or at least the differences, of one with respect to the other?

Message length: the fixed word length bulletins are always the same length, for a given parameter; the variable word length bulletins are, naturally, variable. The variation is driven by the range of the value of the parameter over the field (or the maximum value) which can change from day to day. Whether variations in message length is a problem or not depends on the computer systems used to work with the GRIB records.

Precision: The variable word length bulletins have a fixed and unchanging precision, determined by the 'D' scaling. This assures that the same information content is available day after day. It is straightforward to change the precision in a familiar manner, that is, simply by orders of magnitude, just by altering the D value. This comes at a cost, of course; increasing the precision by a power of 10 adds about 3.3 bits (average) to each data point in the message.

The fixed word length bulletins show a variable precision which is case by case data driven and is determined by the 'E' (power-of-two) scaling that was used to fit the numbers into the available space. This can happen even with the same data, on the same date, but at adjacent grid areas. If one area shows a low variability and the neighboring one a high variability such that a different power-of-two scaling is needed in the two areas, then, unfortunately, the values on a common boundary will not be exactly equal after they are unpacked. This can be disconcerting and a cause for confusion. It will not happen if D-scaling (only) is employed. On the other hand, the variable precision can be viewed as a strength: a data field with a low variability will be encoded at a higher precision, thus preserving the character of the field; a high variability field will be represented with less precision, but that is not a problem as the small, and possibly lost, variations will not matter in the presence of the large ones. The precision of the encoded field can be increased by adding bits to the fixed word length, but the degree of change (a power of 2 for each bit) may not be as easy to deal with (or explain to people) as the simple order of magnitude change afforded by the 'D' scaling method.

No matter which packing method was employed, a proper GRIB decoding program, that took account of the transmitted values of both 'D' and 'E', would return the correct unpacked numbers, regardless of which packing method was employed. It would be transparent to the user except for the questions of precision outlined above.

GRIB CODE FORM

With the exception of the first four octets of the Indicator Section, and the End Section, all octets contain binary values. All sections contain an even number of octets; the variable length sections are padded with zero values as necessary. These extra bits must be accounted for in finding one's way through the sections; their content should be ignored.

SECTION 0: THE INDICATOR SECTION (IS)

The indicator section serves to: identify the start of the record in a human readable form, indicate the total length of the message, and indicate the Edition number of GRIB used to construct or encode the message. The section is always eight octets long.

SECTION 1: THE PRODUCT DEFINITION SECTION (PDS).

The PDS contains indicators for the Parameter table Version, the originating center, the numerical model (or 'generating process') that created the data, the geographical area covered by the data, the parameter itself, the values for the appropriate vertical level or layer where the data reside, the decimal scale factor, and date/time information. The PDS is normally 28 octets long but it may be longer if an originating center chooses to make it so. Users of GRIB messages are strongly urged to use the length-of-section portion of the PDS to determine where the next section begins. Never assume a fixed octet length in this, or any other, section.

Note: Octet 8 may indicate the presence of the Grid Description Section (GDS) even though octet 7 specifies a predefined grid. In this case the GDS must describe that grid -this device serves as a mechanism for transmitting new 'predefined' grids to users prior to their formal publication in this or the official WMO documentation. It is, however, the desired practice to always include the GDS in GRIB bulletins.

Another Note: The use of octet 26 to indicate a 'sub-center' is not (yet) an officially sanctioned WMO practice. The Manual indicates the octet is to be 'reserved', and set to 0. The use arises out of an upcoming change in the Manual in which the 'originating centers' for both GRIB and BUFR (FM 94) will reference a single common table. The difficulty is that BUFR has two octets available for an originating center number while GRIB has only one. The compromise solution is to allow the use of octet 26 as the 'second' octet for GRIB, but only in a national context. The WMO will coordinate the assignment of the numbers for octet 5 for national and international centers (for both GRIB and BUFR), while each national center will then be free to assign sub-center numbers at will to be placed in the octet 26. A zero value in octet 26 will serve as the default indicating that there is no sub-center associated with a particular center. Table 0, in this document, shows, in Part 1, a selection of the WMO recognized originating centers (those that are currently active) as would be found in octet 5.

TABLES FOR THE PDS

TABLE 0 - Part 1

NATIONAL/INTERNATIONAL

ORIGINATING CENTERS

(Assigned By The WMO)

(PDS Octet 5)

TABLE 0 - Part 2

NATIONAL SUB-CENTERS

(Assigned By The Nation)

(PDS Octet 26)

National sub-centers, if any, would be found here.

TABLE A.Generating Process or Model

(PDS Octet 6)

VALUE MODEL

These values and model ('generating process') numbers would be supplied by the individual centers.

TABLE B. GRID IDENTIFICATION

(PDS Octet 7)

Various National Grids would be identified here by the Center International exchange grids are included here.

INTERNATIONAL EXCHANGE GRIDS

NOTES ON INTERNATIONAL EXCHANGE/FOS GRIDS:

(i) The grid points are laid out in a linear array such that the longitude index (the columns) is the most rapidly varying. For the northern hemisphere grids the first point in the record is at the intersection of the western-most meridian and southern-most circle of latitude; the last point is the single polar value (see note iii, below). For the southern hemisphere grids the first point in the record is the single polar value (see note iii, below); the last point is at the intersection of the eastern-most meridian and northern-most circle of latitude. For those familiar with FORTRAN subscripting conventions, longitude is the first subscript, latitude the second.

(ii) In grids 21 through 26, and 61 through 64, the values on the shared boundaries are included in each area.

(iii) The datum for the pole point is given only once in each grid. The user must expand, if desired, the single pole point value to all the pole 'points' at the pole row of a latitude-longitude grid. Scalar quantity values are the same for all pole points on a the grid. Wind components at the poles are given by the formulae:

u = -speed x sin(dd) & v = -speed x cos(dd)

where dd is the direction of the wind as reported according to the specification of wind direction at the poles (refer to WMO Manual on Codes <1>, code table 878).

The WMO convention can be given this operational definition: At the North Pole, face into the wind and report the value of the west longitude meridian along which the wind is coming at you; at the South Pole do likewise but report the east longitude meridian value. This is equivalent to placing the origin of a right-handed Cartesian coordinate system on the North Pole with the y-axis pointing to the prime (0 degree) meridian and the x-axis pointing to the 90 degrees west meridian, and then resolving any vector wind at the pole point into components along those axes. At the South Pole the coordinate axes are oriented such that the y-axis points toward 180 degrees west. Those components are the u- and v-values given as the single pair of pole point winds in the GRIB format.

In terms of a longitude/latitude grid these are the wind components for the pole point at the 180 degree meridian. For example, on a 2.5 x 2.5 degree northern hemisphere grid (145 x 37 points), with the abscissa along the equator and the ordinate along the prime meridian, the transmitted north pole wind components are those that belong at the grid point (73,37). The wind components at the other grid points along the pole row may be obtained through suitable rotation of the coordinate system. All the components at the pole row are, of course, simply representations of the same vector wind viewed from differing (rotated) coordinate systems. In the southern hemisphere the analogous situation holds; the single set of transmitted pole point wind components belong at the grid point (73,1).

WAFS/ICAO/INTERNATIONAL EXCHANGE/FOS GRIDS

(Grids 37 - 44)

Global Coverage of Grids

Octants of the Globe

In the figure the boxes indicate the location of the octants of the globe, the numbers are the corresponding grid identification numbers (PDS Octet 7), and the letters are the grid identification used in the WMO heading (see Appendix A). The left and right meridional columns of each octant/grid are shared with the neighbors.

The basic grid point separation is 1.25x1.25 deg. on a latitude/longitude array, but the grid is 'thinned' by reducing the number of points in each row as one goes northward (or southward) away from the equator. In GRIB terms, this is referred to as a 'quasi-regular' grid.

The latitudinal increment is always 1.25 deg.; this results in 73 rows where the pole is included as a 'row', not a single grid point.

The longitudinal spacing at the equator is also 1.25 deg.; thus there will be 73 grid points at the equator in each octant.

The number of points on each latitudinal row, other than the equator, is given by (using FORTRAN notation):

NPOINTS = IFIX(2.0 + (90.0/1.25) x COS(LATITUDE))

Thus at the pole there will be two grid points, one each at the meridians that delineate the edges of the octant. The formula was worked out so that there is (approximately) equal geographic separation between the grid points uniformly across the globe.

Because of variations in precision and round off error in different computers, the value of NPOINTS may vary by 1 at 'critical' latitudes when calculated on various hardware platforms. Here is a table of the exact values of NPOINTS as a function of latitude as used in the internationally exchanged grids. These numbers will, of course, be found in the Grid Description Section of each GRIB bulletin.

When all this is put together the result is that there are 3447 points of data actually transmitted in any individual GRIB bulletin containing one octant of the globe.

In the GRIB bulletins all of this information will be included in the Grid Description Section (GDS); the GDS must be included in order to describe the thinned or 'quasi-regular' grid structure. See Section 2 and Table C for the general description of the GDS; what follows are the specific values of the variables in the GDS that describe these eight grids.

GDS Contents

Details of Octets 7-32 - Grid Description

Note that the scanning direction is from the bottom (south edge) to the top of the octant grids, regardless of the hemisphere. Thus in the northern hemisphere the first 73 data points (in the BDS) will be the equatorial values and the last two will be the polar values. The PL counts in the GDS octets 33-178 will, of course, indicate contain these numbers.

In the southern hemisphere, the first two data points will be the south pole values, and the last 73 points will be the equatorial values. Octets 33-34 in the GDS will contain '2', octets 35-36 will contain a '3', and so on to octets 177-178 which will contain '73'.

TABLE 1. FLAG FOR GDS OR BMS

(PDS Octet 8)

The bit flag indicates the omission or inclusion of the Grid Description and/or Bit Map Sections.

TABLE 2. PARAMETERS & UNITS

Version 2

(PDS Octet 9)

Notes:

1. By convention, downward net fluxes of radiation or other quantities are assigned negative values; upward net fluxes of radiation or other quantities are assigned positive values.
2. Unidirectional flux values, where the direction of flow is indicated in the name of the parameter shall all have positive values irrespective of the direction of flow. Net (vertical) fluxes shall be calculated by subtracting the downward flux values from the upward flux values
3. The u and v components of vector quantities are defined with reference to GDS Octet 17 and Table 7. However, if the GDS is not included in a message, then any wind components are assumed to be resolved relative to the grid specified in the PDS with u and v defined as positive in the direction of increasing x and y (or i and j) coordinates respectively.
4. Provision is made for three types of spectra:

1) Direction and Frequency
2) Direction and radial number
3) Radial number and radial number

5. Parameters 81 and 91 show the units as 'fraction', thus allowing for a range of coverage. It is up to the user to employ the D (power of ten) scaling to assure that the necessary precision is retained in the numeric values.

TABLE 3. TYPE AND VALUE OF LEVEL

(PDS Octets 10, 11, & 12)

Note: The numbering allows for additions within this framework:

100-119 normal precision

120-139 high precision

140-159 mixed precision

TABLE 3a. SPECIAL LEVELS

(PDS Octet 10)

TABLE 4. FORECAST TIME UNIT

(PDS Octet 18)

TABLE 5.

Grib1 To Grib2 Converter Temperature In Fahrenheit

TIME RANGE INDICATOR

(PDS Octet 21)

NOTES:

1. For analysis products, or the first of a series of analysis products, the reference time (octets 13 to 17) indicates the valid time.
2. For forecast products, or the first of a series of forecast products, the reference time indicates the valid time of the analysis upon which the (first) forecast is based.
3. Initialized analysis products are allocated numbers distinct from those allocated to uninitialized analysis products.
4. A value of 10 allows the period of a forecast to be extended over two octets; this accommodates extended range forecasts.
5. Where products or a series of products are averaged or accumulated, the number involved is to be represented in octets 22-23 of Section 1, while any number missing is to be represented in octet 24.
6. Forecasts of the accumulation or difference of some quantity (e.g. quantitative precipitation forecasts), indicated by values of 4 or 5 in octet 21, have a product valid time given by the reference time + P2; the period of accumulation, or difference, can be calculated as P2 - P1.

A few examples may help to clarify the use of Table 5:

For analysis products P1 is zero and the time range indicator is also zero; for initialized products (sometimes called 'zero hour forecasts') P1 is zero, but octet 21 is set to 1.

For forecasts, typically, P1 contains the number of hours of the forecast (the unit indicator given in octet 18 would be 1) and octet 21 contains a zero.

Value 51 allows for the identification of the most common climatological entities. With P1=0, it could represent (or identify) the multiple year climatology of anything from daily means (or less) to semi-annual means (or more, up to a full year). The assumption is that all the available values within the basic period P2 are averaged together. (An 'annual mean climatology' would just be an average over the total climatological period - Table 5, entry 3.) P1=1 allows for a diurnal sub-stratification of the data within the P2 period, such as 30-year climatology of February mean 00Z temperature starting at a date certain, or all the 12Z surface radiation fluxes averaged for all the days in a season, or whatever. If other sub-stratifications are appropriate they could be identified by different values of P1. No others have been proposed at this time.

Value 115 would be used, typically, for multiple day mean forecasts, all derived from the same initial conditions.

Value 117 would be used, typically, for Monte Carlo type calculations: many forecasts valid at the same time from different initial (reference) times.

Averages, accumulations, and differences get a somewhat specialized treatment. If octet 21 (Table 5) has a value between 2 and 5 (inclusive) then the reference time + P1 is the initial date/time and the reference time + P2 is the final date/time of the period over which averaging or accumulation takes place. If, however, octet 21 has a value of 113, 114, 115, 116, 117, 118, 123, or 124 then P2 specifies the time interval between each of the fields (or the forecast initial times) that have been averaged or accumulated. These latter values of octet 21 require the quantities averaged to be equally separated in time; the former values, 3 and 4 in particular, allow for irregular or unspecified intervals of time between the fields that are averaged or accumulated.

SECTION 2: GRID DESCRIPTION SECTION (GDS)

The purpose of the (optional) GDS is to provide a grid description for grids not defined by number in Table 3.

Note: NV and PV relate to features of GRIB not, at present, in use in international exchange. See the WMO Manual on Codes for the descriptions of those features.

PL is used for 'quasi-regular' or 'thinned' grids; e.g., a lat/lon grid where the number of points in each row is reduced as one moves poleward from the equator. The reduction usually follows some mathematical formula involving the cosine of the latitude, to generate an (approximately) equally spaced grid array. The association of the numbers in octet PL (and following) with the particular row follows the scanning mode specification in Table 8.

TABLES FOR THE GDS

TABLE 6. DATA REPRESENTATION TYPE

(GDS Octet 6)

TABLE C. Sundry Grid Definitions

LATITUDE/LONGITUDE GRIDS

INCLUDING GAUSSIAN

(GDS Octets 7 - 32)

Notes:

1. The latitude and longitude of the first and last grid points should always be given, for regular grids.
2. If a quasi-regular grid is to be described, in which all the rows or columns do not necessarily have the same number of grid points, either Ni (octets 7-8) or Nj (octets 9-10) and the corresponding Di (octets 24-25) or Dj (octets 26-27) shall be coded with all bits set to 1 (missing).
3. A quasi-regular grid can be defined only for rows or columns, but not both simultaneously. The first point in each row (column) shall be positioned at the meridian (parallel) indicated in octets 11-16. The grid points shall be evenly spaced in latitude (longitude).
4. For Gaussian grids only the rows can be rendered quasi-regular; the first point shall be located at the meridian given in octets 14-16 and the last point at the meridian given in octets 21-23.

POLAR STEREOGRAPHIC GRIDS

(GDS Octets 7 - 32)

Notes:

1. Latitude and longitude are in millidegrees (thousandths)
2. Grid lengths are in units of meters, at the 60 degree latitude circle nearest to the pole in the projection plane.
3. Latitude values are limited to the range 0 - 90,000. Bit 1 is set to 1 to indicate south latitude.
4. Longitude values are limited to the range 0 - 360,000. Bit one is set to 1 to indicate west longitude.
5. Octet 27:

Bit 1 set to 0 if the North pole is on the projection plane.

Bit 1 set to 1 if the South pole is on the projection plane.

6. The first and last grid points may not necessarily be the same as the first and last data points if the bit map section (BMS) is used.
7. The resolution flag (bit 1 of Table 7) is not applicable.

LAMBERT CONFORMAL SECANT OR TANGENT CONE GRIDS

(GDS Octets 7 - 42)

Notes:

1. Latitude and longitude are in millidegrees (thousandths)
2. Grid lengths are in units of meters, at the intersection latitude circle nearest to the pole in the projection plane.
3. Latitude values are limited to the range 0 - 90,000. Bit 1 is set to 1 to indicate south latitude.
4. Longitude values are limited to the range 0 - 360,000. Bit one is set to 1 to indicate west longitude.
5. Octet 27:
   Bit 1 set to 0 if the North pole is on the projection plane.
   Bit 1 set to 1 if the South pole is on the projection plane.
   Bit 2 set to 0 if only one projection center used
   Bit 2 set to 1 if projection is bipolar and symmetric
6. The first and last grid points may not necessarily be the same as the first and last data points if the bit map section (BMS) is used.
7. The resolution flag (bit 1 of Table 7) is not applicable.
8. If Latin 1 = Latin 2 then the projection is on a tangent cone.

MERCATOR GRIDS

(GDS Octets 7 - 42)

Notes:

1. Latitude and longitude are in millidegrees (thousandths)
2. Grid lengths are in units of meters, at the circle of latitude specified by Latin.
3. Latitude values are limited to the range 0 - 90,000. Bit 1 is set to 1 to indicate south latitude.
4. Longitude values are limited to the range 0 - 360,000. Bit one is set to 1 to indicate west longitude.
5. The latitude and longitude of the last grid point should always be given.
6. The first and last grid points may not necessarily be the same as the first and last data points if the bit map section (BMS) is used.

SPACE VIEW PERSPECTIVE OR ORTHOGRQAPHIC

(GDS Octets 7-44)

Notes:

1. It is assumed that the satellite is at its nominal position, i.e., it is looking directly at its sub-satellite point.
2. Octet 32-34 shall be set to all ones (missing) to indicate the orthographic view (from infinite distance).
3. It is the angle between increasing y axis and the meridian 180 degrees east if the sub-satellite point is the North pole; or the meridian 0 degrees, if the sub-satellite point is the south pole.
4. The apparent angular size of the earth will be given by 2 x asin(1/Nr).
5. The horizontal and vertical angular resolutions of he sensor (Rx and Ry), needed for navigation equations, can be calculated from the following

Rx = 2 x asin(1/Nr) / dx

Ry = 2 x asin(1/Nr) / dy

SPHERICAL HARMONIC COEFFICIENTS

(GDS Octets 7 - 32)

TABLE 7 - RESOLUTION AND COMPONENT FLAGS

(GDS Octet 17)

Note: If the GDS is not included in a message then any wind components are assumed to be resolved relative to the grid specified in the PDS with u and v defined as positive in the direction of increasing x and y (or i and j) coordinates respectively.

TABLE 8. SCANNING MODE FLAG

(GDS Octet 28)

Note: i direction is defined as west to east along a parallel of latitude, or left to right along an x axis.

j direction is defined as south to north along a meridian of longitude, or bottom to top along a y axis.

TABLE 9. SPECTRAL REPRESENTATION TYPE

(GDS Octet 13)

TABLE 10. COEFFICIENT STORAGE MODE

(GDS Octet 14)

NOTES ON SPECTRAL TRUNCATION:

Using the associated Legendre Polynomials of the First Kind, Pnm, as typical expansion functions, any variable x(l ,F), which is a function of longitude, l , and sin(latitude), F , can be represented by

In the summations, M is the maximum zonal wave number that is to be included, and K & J together define the maximum meridional total wave number N(m), which, it should be noted, is a function of m. A sketch shows the relationships:

In this figure, the ordinate is n the zonal wave number, the abscissa, m, is the total meridional wave number, the vertical line at m = M is the zonal truncation, and the diagonal passing through (0,0) is the line n = m. The Legendre Polynomials are defined only on or above this line, that is for n > m. On the n-axis, the horizontal line at n = K indicates the upper limit to n values, and the diagonal that intersects the n-axis at n = J indicates the upper limit of the area in which the Polynomials are defined. The shaded irregular pentagon defined by the n-axis, the diagonal from n = J, the horizontal n = K, the vertical m = M, and the other diagonal n = m surrounds the region of the (n x m) plane containing the Legendre Polynomials used in the expansion.

This general pentagonal truncation reduces to some familiar common truncations as special cases:

Triangular: K = J = M and N(m) = J

Rhomboidal: K = J + M and N(m) = J + m

Grib1 To Grib2 Converter Temperature Calculator

Trapezoidal: K = J, K > M and N(m) = J

In all of the above m can take on negative values to represent the imaginary part of the spectral coefficients.

SECTION 3: BIT MAP SECTION (BMS)

The purpose of the (optional) BMS is to provide either a bit map or a reference to a bit map pre-defined by the center. The bit map consists of contiguous bits with a bit-to-data-point correspondence as defined in the grid description. A bit set equal to 1 implies the presence of a datum for that grid point in the BDS; a value of zero implies the absence of such. This is useful in shrinking fields where fair portions of the field are not defined. An example would be global grids of sea surface temperature; the bit map would be used to suppress the 'data' at grid points over land. One would not want to use the BMS if the data were un-defined at only a small number of grid points as the overhead of adding the bit map array (one bit for each grid point) might add more bits to the overall message that were subtracted by the removal of a few data values.

SECTION 4: BINARY DATA SECTION (BDS).

The BDS contains the packed data and the binary scaling information needed to reconstruct the original data from the packed data. The required decimal scale factor is found in the PDS, above. The data stream is zero filled to an even number of octets.

Here are some of the various forms the binary data can take; the flag table in BDS octet 4, possibly extended into octet 14, identifies which variant is in use.

Grid-point data - Simple packing

Here the data simply begin in octet 12 and continue, packed according to the simple packing algorithm described above, without any particular regard for computer 'word' boundaries, until there is no more data. There may be some 'zero-fill' bits at the end.

If all the data in a grid point field happen to have the same value, then all of the deviations from the reference value are set to zero. Since a zero value requires no bits for packing, octet 11 is set to zero, thus indicating a field of constant data, the value of which is given by the reference value. Under these circumstances, octet 12 is set to zero (the required 'zero fill to an even number of octets') and bits 5-8 of octet 4 contain an 8. The number of data points in the field is implied by the grid identification given in the PDS and/or the GDS and BMS.

Spherical Harmonic Coefficients - Simple packing

Octets 12-15 contain the real part of the (0.0) coefficient in the same floating point format as the reference value in octets 7-10. The imaginary part of the (0.0) coefficient, mathematically, is always equal zero. Octets 16 to the end contain the remaining coefficients packed up as binary data with the same sort of scaling, reference value, and the like, as with grid-point numbers. Excluding the (0,0) coefficient, which is usually much larger than the others, from the packing operation means that the remaining coefficients can be packed to a given precision more efficiently (fewer bits per word) than would be the case otherwise.

Grid-Point Data - Second Order or Complex Packing

Before laying out where the various second order values, sub-parameters, counters, and what have you, go, it is appropriate to describe the second order packing method in an algorithmic manner.

Referring back to the description of simple packing, the encoding method is the same up to part way through the fourth step, stopping just short of the actual packing of the scaled integers into the 'words' of either a pre-specified or calculated bit length.

The basic outline of second order packing is to scan through the array of integers (one per grid point, or possibly less than that if the Bit Map Section has been employed to discard some of the null value points) and seek out sub-sections exhibiting relatively low variability within the sub-section. One then finds the (local) minimum value in that sub-section and subtracts it from the ('first order') integers in that sub-section, which leave a set of 'second order' integers. These numbers are then scanned to find the maximum value, which in turn is used to specify the minimum bit width for a 'word' necessary to contain the sub-section set of second order numbers.

The term 'first order' in this context refers to the integer variables that result from subtracting the overall (global) minimum from the original variables and then doing all scaling and rounding; 'second order' refers to the variables that result from subtracting the local minimum from the sub-set of first order variables. No further scaling is necessary or appropriate.

The sub-section set of numbers are then packed into 'words' of the just determined bit length. The overall savings in space comes about because the second order values are, usually, smaller than their first order counterparts. They have, after all, had two minima subtracted from the original values, the overall minimum and the local minimum, where the first order values have had only the overall minimum subtracted out. There is no guarantee, however, that the second order packing will compress a given field to a greater degree than the first order packing. If the first order field of integers is highly variable, or generally close to zero, then there will be no gain in compression. But if the field shows long runs of small variation, particularly if some of the runs are constant (zero variability), then the second order packing will contribute to the compression.

The process then repeats and a whole collection of sub-sections are found, their local minima are subtracted, etc. One of the tricky parts of this process is defining just what is meant by a 'sub-section of low variability'. The WMO Manual is silent on this as it only describes how the sub-sections and their ancillary data are to be packed in the message. The U.S. National Weather Service, the U.K. Meteorological Office, the European Centre for Medium-Range Weather Forecasts, and probably other groups have, independently, designed selection criteria and built them into GRIB encoders. It is beyond the scope of this document to attempt to describe them in any detail. These groups have all expressed their willingness to share their GRIB encoders with any who ask for them.

Before laying out where the second order values, etc., are placed in a message, we had best review just what information has to be saved. We need to include the following information:

1) How many sub-sections there are;

2) Where does each sub-section begin;

3) Where does each sub-section end; or, how many data points are in each sub-section;

4) That is the local minimum value (a first order value) that was found for each sub-section;

5) What is the bit width of the collection of first order values (the local minima) found for each sub-section;

6) What are the second order values for each sub-section;

7) What are the bit widths of the second order values appropriate for all the sub-section; and, finally,

8) Sufficient information to specify where the above information is located.

A moments consideration (a long moment, perhaps) will satisfy the reader that the information given will be sufficient to reconstruct the original data field.

The information needed for points 2) and 3), the beginning and end of the sub-sections, is presented in the form of a bit map, called a 'secondary bit map' to distinguish it from the bit map (optionally) contained in the BMS. There is one bit for each grid point containing data, ordered in the same way as the grid is laid out. The 'primary' bit map, the BMS bit map, may have been used to eliminate data at points where the data are meaningless - only the remaining 'real' data points are matched by the bits in the secondary bit map. This possibility is understood to exist throughout the following discussion. The start of each sub-section is indicated by the corresponding bit set to 'on' or to a value of 1. Clearly, the first bit in the secondary bit map will always be set on, since the first data point must be the start of the first sub-section. (If it is not, then something is wrong somewhere. Unfortunately it is not always easy to tell just where the error occurred.) The secondary bit map is then no more than a collection of 1s and 0s, indicating the start and the extent of each sub-section. It would be possible to scan through the secondary bit map and determine how many sub-sections there are; however, this number is explicitly included in the GRIB message to save one the trouble, and to serve as an internal self-checking mechanism.

At long last, then, here is the layout of the information, with further explanatory notes, when second order packing has been employed:

As usual, there may be padding by binary 0 bits sufficient to bring the entire section to an even number of octets.

There are a small number of special cases and variations on the above layout:

If the bit-width for a sub-section is zero, then no second order values for that sub-section are included in the part of the message starting at octet N2. This will happen is all the first order values in the sub-section are identical. This is a form of 'run-length encoding' and contributes greatly to packing efficiency if the original data contains strings of constant value (including zero).

Under some circumstances, it may turn out that there is no need to use different bit-widths for each of the sub-sections. In that case, a flag is set in bit 8 of the extended flags found in octet 14 (see table 11) indicating that all the sub-sections are packed with the same bit-width, and that the single value will be found in octet 22.

Row by row packing is defined as selecting entire rows (or columns) to serve as sub-sections, without regard to 'variability' determinations. It can have some compression value. If row by row packing is employed, this is indicated by setting a flag in bit 7 of the extended flags found in octet 14 (see table 11) and NOT including the secondary bit map in the message. It is unnecessary since the length of the rows (columns) is known from the grid specifications given elsewhere in the message.

TABLES FOR THE BDS

TABLE 11. FLAG

(BDS Octet 4 and, optionally, 14)

The following gives the meaning of the bits in octet 14 ONLY if bit 4 is set to 1. Otherwise octet 14 contains regular binary data.

Notes:

1. Bit 3 is set to 1 to indicate that the original data were integers; when this is the case any non-zero reference values should be rounded to an integer value prior to placing in the GRIB BDS.
2. Bit 4 is set to 1 to indicate that bits 5 to 12 are contained in octet 14 of the data section.
3. Although GRIB is not capable of representing a matrix of data values at each grid point, the meaning of bit 6 is retained in anticipation of a future capability.
4. When secondary bit maps are present in the data (used in association with second order packing) this is indicated by setting bit 7 to 1.
5. When octet 14 contains the extended flag information, octets 12 and 13 will also contain 'special' information; the actual data will begin in a subsequent octet. See above.

SECTION 5: END SECTION.

The end section serves a human readable indication of the end of a GRIB record. It can also be used for computer verification that a complete GRIB record is available for data extraction. It should not be used as a search target since a '7777' bit combination could exist anywhere in the binary data stream.

Octet no.

1-4 '7777' (Coded CCITT-ITA No. 5)