© Northern Lighthouse Ltd - Last updated 1 Sep 2011
The reader is referred to WMO official documentation as the source of definitions of terms related to BUFR and CREX. The information about BUFR and CREX in this file is based on our interpretation of WMO documents, and in case of discrepancies, WMO documentation should be considered the valid one.
The aim of this introduction is to give a short description, using simple words, for those of you who are not familiar with CREX. If you like our introduction, or if you do not like it, or if you have suggestions about how it could be improved, please send us your comments.
Use our Glossary if you hit an unfamiliar term.
CREX stands for Character form for the Representation and EXchange of data.
The meteorological world is full of information exchange. All kinds of weather messages are continuously created, transmitted and stored all over the globe. These messages have very different contents: manual observations on the land and on the oceans, upper air soundings, satellite and radar observations, observations from aeroplanes, drifting buoys, constant level balloons, automatic weather stations etc.
All these different observation reports contain different kind of data and traditionally there has been a huge variety of different ways to code them. Too many different ways!
During the late 1980's a general table driven coding method, BUFR, was developed to unify
the way of coding weather information for transmission and/or storing. In BUFR the two
middle letters stand for
But the meteorological world was slow to accept BUFR, partly because it was binary and thus not human readable as such. In some parts of the WWW (World Weather Watch) network, the transmission of binary messages is still a problem and CREX was defined to complement BUFR in areas where BUFR was not feasible.
CREX was developed during the late 1990's. CREX is, like BUFR, a TDCF (table driven
code form), and it is in many ways similar to BUFR. However, unlike BUFR, CREX is
character-based. The first letter in CREX stands for
CREX code is
There is no need for a general CREX-coding library to know about the data contents of messages, whether it is temperatures or winds or something else. CREX messages contain metadata that tell what the actual data are and how they should be interpreted.
For the kernel coding library, a CREX message is just a stream of characters with a certain predefined, but not constant, structure. Using the metadata and external tables the coding library is able to find out what parameters are found in the message and how to decode their values.
Of course, application programs that use or create CREX messages need to know about the meteorological contents. But an application program does not need to know about the details of how the data values are encoded; it uses the API (Application Program Interface) of a CREX library, and lets the library do all the difficult work.
The mechanism of using external tables makes CREX and BUFR very versatile. Although CREX
was designed for meteorological data, the same CREX coding libraries can be used for other
sciences, or
The main CREX table, called Table B, contains
These descriptors are keys to the parameter values within a CREX message. Developers of
applications that handle CREX messages need to know the descriptors corresponding to the
parameters in which they are interested.
In this chapter we discuss the basics of the CREX coding mechanism:
In a CREX message, numeric data values are stored as integer values. Each data value occupies a predefined number of digits, depending on the precision and range of the data parameter. Text data occupies a predefined number of characters. Data values are separated by one or more spaces.
The number of characters or digits in each data value and the way to interpret the digits is defined in coding rules stored in Table B.
Most coding rules are stored in external CREX tables (files). To encode or decode CREX messages the coding software needs to have access to the table files.
A key to all information stored in CREX tables B, C and D are the
In addition to the character stream of data values, a CREX message contains also a sequence of
Descriptor values (or "names") are composed of three values
As an example, element descriptor
Descriptors are explained more in depth in the next chapter.
CREX Table B (in the format used in Cipher documentation) contains the following entry
for descriptor
B12004 Dry-bulb temperature at 2m
°C
1 3
The first number is the descriptor name, followed by the parameter name. The second line
contains the unit of the parameter (
The third line contains the coding rules. Values on the line are for
coded_value = original_value * 10^scale
Scale is used to multiply decimal numbers into integer values (scale > 0) or
to reduce precision of large values (scale < 0). Thus, in a way, scale tells
the length of the decimal fraction used.
Missing values are coded by filling all character positions with the character "
CREX Table B contains the following entry for descriptor
B10051 Pressure reduced to mean sea level
Pa
-1 5
i.e. unit is Pascal (Pa), stored value discards the last digit (-1). Five
digits are used to represent a value. For instance, 09876 represents 98760 Pa, i.e.
987.6 hPa, and a missing value is written as
Descriptor
B06002 Longitude (coarse accuracy)
Degree
2 5
i.e. longitude is given in degrees, the stored value retains two decimals, and five digits are used to represent the value. As an example, 123.4567°E would be coded as 12346, and 270°E should be coded as -09000 (longitude range is restricted to -180°...+180° by WMO).
This is the description part of of a simplified message which contains only temperature, pressure, location and time:
B05002 Latitude (coarse accuracy)
B06002 Longitude (coarse accuracy)
B04003 Day
B04004 Hour
B04005 Minute
B12004 2 meter temperature
B10051 Pressure reduced to msl
Note that in real messages we would do better by using sequence descriptors for location and time
(see 3.3).
In this chapter we discuss CREX descriptors more thoroughly.
Descriptors are written as 6 character strings
The character
Classes are used for grouping similar parameters together. For instance,
These are the basic key descriptors between data values and coded values. Element descriptor decoding rules are stored in CREX Table B.
These are shorthand notations for sequences of descriptors. CREX Table D and BUFR Table D contain rules that describe how a single sequence descriptor is expanded into a sequence of descriptors, which again may contain other sequence descriptors which must be expanded into a sequence of descriptors... This continues until the final sequence contains only element and operator descriptors.
As an example, we could describe the same structure of the example in 2.5 by using
sequence descriptor
B05002 Latitude (coarse accuracy)
B06002 Longitude (coarse accuracy)
B04003 Day
B04004 Hour
B04005 Minute
So we could describe the structure in example 2.5 by using:
D01025 (lat + lon + day + hour + minute)
B12004 2 meter temperature
B10051 pressure reduced to msl
These are shorthand notations for replicating a sequence of descriptors.
Descriptor
If
These are special descriptors used to alter normal coding rules.
In this chapter we discuss the physical structure of a CREX message.
You can use Cipher CREXtool demo program (downloadable from Northern Lighthouse website) to study structures of real CREX messages.
A CREX message starts with the characters "
You can use the demo program Cipher CREXtool (task
If several observation reports share the same structure, i.e. they have the same descriptors
in section 1, then it is possible to build a message that has the descriptors given only once but
with a data section containing several observation reports. In this case each report is said to
be a
Subsets are separated by a end-of-subset mark, which is a single "
It is possible to expand CREX capabilities locally, within a single data processing centre,
in a similar manner as described in our Introduction to BUFR. But as the usage of the
local extensions is strongly discouraged, we skip them for the time being.
© Northern Lighthouse Ltd - Last updated 1 Sep 2011
| | |