GRIB messages are at the moment exchanged in edition 1 or 2. Although the information content of two messages in different editions is almost the same, their binary format is very different and organised in a different way |
Converting edition 1 to 2
GRIB messages are at the moment exchanged in edition 1 or 2. Although the information content of two messages in different editions is almost the same, their binary format is very different and organised in a different way.
Since the new grib2 format is going to replace grib1 we will focus more on the grib1 to grib2 conversion rather than the opposite, which sometimes is not possible.
The conversion algorithm should be easy to implement, but there are some factors making it challenging. First of all the new designed grib2 is in some points semantically different from grib1. Therefore it doesn't allow an easy mapping of the meaning across the two versions. Moreover some of the numeric code tables semantically identical are numerically different, which again doesn't allow an easy mapping between them, because the numeric codes for the same information element are different. We refer in particular to the type of level which is numerically different in the two editions.
To convert a GRIB message from edition 1 to edition 2 it is enough to set the key edition=2 (see grib_set). The conversion is performed automatically provided that the library is configured properly to translate the parameter information. The information regarding time and space is always translated automatically, while the parameter information, which is sometime dependent on local tables, has to be configured by the user if it is not included in the main set of parameter conversion rules contained in ecCodes distribution.
A list of all the parameters recognised by ecCodes is reported for consultation. The list contains their representation in edition 1 and 2 and for some of them the NetCDF CF compliant name.
Each parameter is identified by a paramId, which is a valid ecCodes key, and is described through the keys shortName, name, units.
For each parameter we can have one or more grib1 and/or grib2 representations. A GRIB representation is a set of keys describing the parameter in the coding format (grib1 or grib2). If for a parameter the grib1 and grib2 representations are both present in the list then the conversion from grib1 to grib2 is defined and can be automatically performed by ecCodes just setting edition=2.
A parameter can have more than one representation for a single format, because local representations are allowed depending on the centre defined in the GRIB message.
A local description can be added just editing the following definition files: paramId.def, shortName.def, name.def, units.def. The syntax of these files is:
value = { key1=value1; key2=value2; key3=value3; ... }
grib[edition]/localConcepts/[centre:s]. Where [edition] is 1 or 2 and [centre:s] is the string describing the centre in the official table 0 of grib1 (e.g. centre code 98 is "ecmf")The files describing the local parameters for ECMWF grib1 are located in grib1/localConcepts/ecmf. If for example we need to define "2 metre temperature" for ECMWF we have to add the following lines to the corresponding files:
The same syntax can be used to describe the same parameter in grib2 to be able to convert the information from grib1 to grib2 and to be able to have the same paramId, name, shortName, units for both editions.
A site or user configuration is possible to allow interpretation and conversion of grib 1 messages encoded in non standard local ways. To separate the definition files contained in the installation directory from the definition files described in the previous section, in which the user can put some extra and local parameter definitions, the environment variable ECCODES_DEFINITION_PATH can be used.
To set this environment variable properly we have first to find the definitions files directory used by ecCodes. For this we can use the tool codes_info which provides some configuration information about the library:
> codes_info ecCodes Version 2.0.0 Default definition files path is used: /usr/local/apps/eccodes/2.0.0/share/eccodes/definitions Definition files path can be changed by setting ECCODES_DEFINITION_PATH environment variable Default SAMPLES path is used: /usr/local/apps/eccodes/2.0.0/share/eccodes/samples SAMPLES path can be changed by setting ECCODES_SAMPLES_PATH environment variable
To enable the parameter definitions described in the files contained in our directory
/home/u/definitions
we have to set the environment variable ECCODES_DEFINITION_PATH as follows:
export ECCODES_DEFINITION_PATH=/home/u/definitions:/usr/local/apps/eccodes/2.0.0/share/eccodes/definitions
so that our definition of the parameters will be read by ecCodes during run time. The content of the definition files in the directory /home/u/definitions has to be properly written following the instructions of the previous section.
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.