Guide to WMO Table Driven Code Forms:
FM 94 BUFR
and
FM 95 CREX
Layer 1: Basic Aspects of BUFR and CREX
and
Layer 2: Layout, Functionality and Application of BUFR and CREX
Geneva, 1 January 2002
Preface
This guide has been
prepared to assist experts who wish to use the WMO Table Driven Data
Representation Forms BUFR and CREX.
This guide is designed
in three layers to accommodate users who require different levels of
understanding.
Layer 1 is a general
description designed for those who need to become familiar with the table
driven code forms but do not need a detailed understanding. Layer 2 focuses on the functionality
and application of BUFR and CREX, and is intended for those who must use
software that encodes and/or decodes BUFR or CREX, but will not actually write
the software.
Layer 3 is intended for
those who must actually write BUFR or CREX encoding and/or decoding software,
although those wishing to study table driven codes in depth, will find it
equally useful.
The WMO gratefully
acknowledges the contributions of the experts who developed this guidance
material. The Guide was prepared
by Dr. Clifford H. Dey of the U. S. A. National Centre for Environmental
Prediction. Contributions were
also received in particular from Charles Sanders - Australia, Eva Cervena -
Czech Republic, Chris Long - U.K., Jeff Ator - USA and Milan Dragosavac, ECMWF.
Contents
Layer
1: Basic
Aspects of BUFR and CREX
Page
1.1 Overview L1- 2
1.2 General
Description............................................................................................ L1- 2
1.2.1 Self-description....................................................................................... L1- 2
1.2.2 Code Structures...................................................................................... L1- 4
1.2.3 BUFR and CREX Tables......................................................................... L1- 5
1.2.4 Features common to BUFR and
CREX................................................ L1- 8
1.2.5 Differences............................................................................................... L1-10
1.2.6 CREX Examples....................................................................................... L1-11
1.3 Updating
Procedures......................................................................................... L1-15
1.3.1 General Procedures................................................................................ L1-16
1.3.2 Updating the Structures........................................................................ L1-16
1.3.3 Updating the Tables............................................................................... L1-16
1.3.4 Validation of Updates............................................................................. L1-16
1.4 Migration
Guidance............................................................................................ L1-17
1.4.1 Training.................................................................................................... L1-17
1.4.2 Technical Issues..................................................................................... L1-17
1.4.3 Encoding vs. interpretation................................................................... L1-18
Layer 2: Layout,
Functionality and Application of BUFR and CREX........ L2-
1
Layer
3: Detailed
Description of the Code Forms
(See separate Volume
Layer 3 for programmers of encoder/decoder software)
Layer 1: Basic Aspects of BUFR and CREX
1.1 Overview
The table driven code forms BUFR (Binary Universal
Form for the Representation of meteorological data) and CREX (Character form for the Representation and EXchange of data) offer the great advantages of flexibility
and expandability compared with the traditional alphanumeric code forms. These
beneficial attributes arise because BUFR and CREX are self-descriptive. The term "self-descriptive"
means that the form and content of the data contained within a BUFR or CREX
message are described within the BUFR or CREX message itself. In addition, BUFR offers condensation,
or packing, while the alphanumeric code CREX provides human readability.
BUFR was first approved for operational use in
1988. Since that time, it has been
used for satellite, aircraft, wind profiler, and tropical cyclone observations,
as well as for archiving of all types of observational data. In 1994, CREX was approved as an experimental code form by
the WMO Commission on Basic Systems (CBS Ext.94). In 1998, CBS (CBS-Ext. 98) recommended CREX be approved as
an operational data representation code form as from 3 May 2000. In 1999, this recommendation was
endorsed by the WMO Executive Council (EC-LI (1999)). CREX is already used among centres for exchange of ozone,
radiological, hydrological, tide gauge, tropical cyclone, and soil temperature
data. BUFR should always be the
first choice for the international exchange of observational data. CREX should be used only when BUFR
cannot. BUFR and CREX are the only
code forms the WMO needs for the representation and exchange of observational
data and are recommended for all present and future WMO applications.
This guide to Table Driven Code Forms is
designed in three layers to accommodate users who require different levels of
understanding. Layer 1 is a
general description designed for those who need to become familiar with the
table driven code forms but do not need a detailed understanding. Layer 2 focuses on the functionality
and application of BUFR and CREX, and is intended for those who must use software
that encodes and/or decodes BUFR or CREX, but will not actually write the
software. Layer 3 is intended for
those who must actually write BUFR or CREX encoding and/or decoding software,
although those wishing to study table driven codes in depth, will find it
equally useful.
1.2 General
Description
1.2.1 Self-definition
Nddff 1snTTT
,
where N = total cloud cover, dd = wind direction, ff = wind
speed, 1 is a group indicator, and TTT = air temperature, where the sign of TTT
is given by sn.
However, only after looking further at the code book to find the full
meanings and coding conventions of this symbolic form, can we determine that
the sky is 3/8 covered with clouds, the wind is blowing from 230 degrees at 25
knots, and the air temperature is - 2.7 oC. Thus, the position within the report
and the coding convention (in this example, the symbolic form Nddff 1snTTT)
assigned to that position of the report define the data contained within
traditional alphanumeric code forms.
Furthermore, if a new group of information were to be inserted before
the second and third mandatory groups in Section 1, the positions of these two
groups would change. Such a
modification would require a corresponding update to all software programs that
encode or decode such reports or the software would either give incorrect
values or fail completely. The
reason is that the coding conventions used to describe the data are built into
the processing software, not included with the data. It is this fact that renders the traditional alphanumeric
code forms incapable of accommodating new types of data.
In a table driven code form, there are also position rules,
but they apply only to the shape of the ÇcontainerÈ (or code structure) rather
than to the content of the ÇcontainerÈ.
The presence and form of the data are described within the ÇcontainerÈ
itself. This is the concept of
self-description. In order to
accomplish it, there is a section (the Data Description Section) in BUFR and
CREX messages in which the type and form of the data contained within the
message are defined. Here is an
example of a simple self-described message:
Data Description:
Position: Element Parameter
Unit Data
Reference
Name
Width
Number (characters)
1 B
01 001 Block
number Numeric 2
2 B
01 002 Station
number Numeric 3
3 B
04 004 Hour Hour 2
4 B
12 001 Temperature Tenth ¡C 3
5 B
11 002 Wind
Speed m/sec. 3
6 B
11 003 Wind
direction Degree 3
Data:
07 444 06 154 003 230
We can see here that the station is 07444, the
hour is 06, the temperature is 15.4¡C, the speed of wind is 3 meter/sec and its
direction is 230 degree. The first
section of the message contains the data description, which is in itself very
long relative to the data values.
To make this more efficient, standards (unit, data width, scale, etc..)
for coding the values are defined for various physical parameters and kept in
the WMO Code Tables. Thus, instead
of writing all the detailed definitions within the message, one will just write
a number (called above in this example: Element Reference Number) identifying the
parameter with its descriptions.
Then in that case the message would be:
Data Description: 001002 004004 012001 011002
011003
Data: 07444 06 154 003 230
In WMO table driven codes, the Data Description Section
contains a sequence of data descriptors, which is like a set of
"pointers" towards elements in predefined and internationally agreed
tables (stored in the official WMO Manual on Codes). By definition these descriptors are six digits reference
numbers (or six characters for CREX); they are defined in the code tables that
are explained further in section 1.2.3 below. Once the Data Description Section is read, the following
section containing the data itself (the Data Section), can be understood. Indeed, the characteristics of the
parameters to be transmitted must already be defined in the tables of the WMO
Manual before data containing those parameters can be exchanged in BUFR or CREX
messages.
1.2.2 Code Structures
The structures of the
BUFR and CREX code forms are the following:
CREX
The Indicator Sections and the BUFR Identification Section
are short sections, which identify the message. The list of descriptors, pointing towards elements in
predefined and internationally agreed tables that are stored in the official
WMO Manual on Codes (described previously), are contained in the Data
Description Section. These
descriptors describe the type of data contained in the Data Section and the
order in which the data appear there.
The Optional Section can be used to transmit any information or
parameters for national purpose.
The End Section contains the four alphanumeric characters
"7777" to denote the end of the BUFR or CREX message.
Since the data in a CREX message are laid out one after the
other, and since the data values of the parameters in a CREX message are
transmitted in a set of characters, it is very simple to read a CREX
message. While the order of the
data contained in a BUFR message is likewise described by the BUFR Data
Description Section, the data values of the parameters in a BUFR message are
translated in a set of bits in BUFR.
Consequently, a BUFR message is not human readable, or extremely
difficult to decipher without the help of a computer program. CREX can be looked upon as the image in
characters of BUFR bit fields.
When there is a requirement for transmission of new
parameters or new data types, new elements are simply added to the WMO BUFR and
CREX tables, after approval by the CBS.
Since table driven code forms can thus describe any new parameter by the
simple addition of a new entry to the appropriate code table, table driven code
forms possess the flexibility to transmit an infinite variety of information. Therefore, definition of new Çcode
formsÈ is no longer necessary.
Furthermore, procedures and regulations are fixed. A new edition number is assigned every
time the BUFR or CREX code structure is changed. Although these edition changes require an update to BUFR or
CREX encoding or decoding software, such changes are infrequent (the BUFR
Edition Number has changed only twice since 1988 – see Section 1.3). Likewise, a new version number is
assigned every time additions are made to BUFR or CREX code tables. Although version number changes are
more frequent than edition number changes, they do not require modifications to
the processing software. The
edition number of the format (structure of the message) and version number of
the tables are transmitted in the message itself (in the Indicator and
Identification sections for BUFR, in the Data Description section for CREX) and
enable the treatment of old archived data.
Tables define how the parameters (or elements) shall be
coded as data items in a BUFR or CREX message (i.e. units, size, scale). They are recorded in the WMO Manual on
Codes, Volume I.2 (International Codes), Parts B (Binary Codes) and C (Common
Features to Binary and Alphanumeric Codes). The Manual on Codes also comprises Volume I.1 (international
Codes), Part A (Alphanumeric Codes) and Volume II: Regional Codes and National
Coding Practices. These three
volumes are collectively referred to as WMO Publication No. 306. The Tables defining BUFR and CREX
coding are Tables A, B, C, and D.
Table A
subdivides data into a number of discrete categories (e.g. Surface data –
land, Surface data - sea, Vertical soundings (other than satellite), Vertical
soundings (satellite), etc.).
While not technically essential for BUFR or CREX encoding/decoding systems,
the data categories in Table A are useful for telecommunications purposes and
for storage of data in and retrieval of data from a data base.
Table B
describes how individual parameters, or elements, are to be encoded and
decoded in BUFR and CREX. For each element, the table lists the
reference number (or element descriptor number, which is used in the
description section of the code like a "pointer", as explained
earlier), the element name, and the information needed to encode or decode the
element. For BUFR, this
information consists of the units to be used, scale and reference values to
apply to the element, and the number of bits used to describe the value of the
element (the BUFR data width). For
CREX, this information consists of units to be used, the scale value to apply
to the value of the element, and the number of characters used to describe the
value of the element (the CREX data width). Although the same elements are found in both BUFR and CREX
Tables B, their unit may differ (BUFR units are SI, while CREX units are more
user oriented). For example, the
unit used for temperature is Kelvin in BUFR but Celsius in CREX. The data items transmitted in a report
will have their descriptor numbers listed in the Data Description Section. As an example, extracts of BUFR and
CREX Table B for Temperature is given below.
Table B is fundamental to encoding and decoding in both
BUFR and CREX.
Class 12 - Temperature
|
TABLE REFERENCE |
TABLE ELEMENT NAME |
BUFR |
CREX |
|||||||
|
|
|
UNIT |
SCALE |
REFERENCE VALUE |
DATA WIDTH (Bits) |
UNIT |
SCALE |
DATA WIDTH (Characters) |
||
|
F |
X |
Y |
|
|
|
|
|
|
|
|
|
0 |
12 |
001 |
Temperature/dry-bulb
temperature |
K |
1 |
0 |
12 |
¡C |
||