Bufr Software Programs

The Binary Universal Form for the Representation of meteorological data, or BUFR, is a data format maintained by the WMO. It is used mainly for encoding meteorological observations of all sorts, including those from synoptical stations, radiosondes and satellites. Because BUFR is encoded in binary, it can be stored, transmitted and processed efficiently. It is table driven, so that it can encode data in a flexible fashion. This makes it easy to use BUFR to describe new types of observations or describe old types of observations in new ways. A short overview of the structure of BUFR is presented below. For more in-depth technical documentation of BUFR, see the WMO's.

Templates can be designed to meet the requirements of a specific data product (weather observations, for instance). Such templates can then be used to standardize the content and structure of BUFR data products. The WMO has released a number of BUFR templates for surface and upper air observational data.

BUFR is designed to be processed using machines, not directly by humans. Therefore, specialized software is required in order to work with it. Some available software packages at the end of this text. Structure of a BUFR message Data encoded in BUFR is called a message. A message consists of one or more subsets of related meteorological data. The structure of a BUFR message is described below, followed by a short example of how it could be read. Please note that this is intended to be a summary, not technical documentation. Raja nee hot ready rarbg.

If you need technical, in-depth information about the BUFR format, see the WMO's. • Section 0: Indicator section Contains the letters 'BUFR', the length of the message and the BUFR edition number. • Section 1: Identification section Contains information about the type of data contained in the BUFR. • Section 2: Optional section Contains local data that is not regulated by the WMO. • Section 3: Data description section Describes what variables the BUFR contains in the data section and where they are to be found. It also states how many times this description is repeated in the form of subsections. Elements in section 3 can be meteorological variables that were observed and other metadata, such as the instrument used to make the observation or data quality.

They can also signify known sequences of elements that occur commonly; it's possible to encode a sequence that always contains height, latitude and longitude, for example, rather than describing these elements individually. This saves space. Other elements in section 3 can be tell a processing program e.g. That multiple elements follow, that elements will follow in great precision than usual, etc. • Section 4: Data section This section contains the actual data described in section 3. • Section 5: End section This section contains the letters '7777', signifying that the message has come to an end.

It can be used together with the length of the message, encoded in section 0, to check that the BUFR was transferred properly. It may seem strange to format data like this.

Why does it make sense to describe the data in data description section and then write the data in another section? Other formats write data descriptions and data together. An extremely simple XML snippet, for example, could look like this: 296 K 85% 10.3 m/s 72° In this example, the metadata is stored next to the data it's referring to. The data is also quite verbose - 202 characters long. In BUFR, the same piece of message could be organized using the following logical structure expressed in XML (this is a representation of the message's logical content for simplicity's sake; in binary it would be different): 2968510.372 This is a lot shorter than the previous representation of the same data (125 characters). When interpreting the above message, the decoding software would first look up what the elements described in section 3 in a table stored elsewhere in order to find out the units and length of the data belonging to the element in section 4.

Again, this is an example of BUFR's logical structure - in the real BUFR tables the lengths and data types are expressed in bits, not characters: element length (characters) unit temperature 3 K humidity 2% wind speed 4 m/s wind direction 2 ° The data in section 4 ( 2968510.372) would then be partitioned according to the number of the characters and interpreted as instances of the elements in section 3: temperature (K) humidity (%) wind speed (m/s) wind direction (°) 296 85 10.3 72 As you can see, the BUFR way of storing the data is much more compact, but not as easy to read for a human. In reality, the BUFR could be much more complex than in this example, so that the advantages of using it compared to traditional codes would be more pronounced. Allowing software to find out how the data in the message is structured before having to process the data itself means that the software can create a strategy for decoding the data that is especially efficient. It also makes it possible to separate the data decoding from interpretation, so that one part could be delegated to another program. In general, with good software, storing data like this can make processing more efficient and allow it to take up less space. Software for working with BUFR There is no definitive software library for working with BUFR.