Guide on WWW Data Management (Chapters 1

PART 1.
    CHAPTER 1 - The WWW Data Management Concept
    CHAPTER 2 -Requirements for the Development of Specific Data Management Functions
    CHAPTER 3 - Meteorological Data Representation: Overview of Codes
    CHAPTER 4 - Meteorological Data Representation: Alphanumeric (character) Codes
    CHAPTER 5 - Meteorological Data Representation: Binary Representation Form

PART 2.
    CHAPTER 6 - The Use of Computer Graphics for Meteorological Data Representation
    CHAPTER 7 - Data Bases in a Meteorological Environment
    CHAPTER 8 - The Distributed Data Bases Concept
    CHAPTER 9 - Data Monitoring
    CHAPTER 10 - Computer Software Exchange
    CHAPTER 11 - Endnote
    LIST OF ACRONYMS

1.1 Purpose and Scope of WWWDM
1.2 Principal Long-term Objectives of the WWWDM
1.3 Programme Organization
1.4 Major Influences
1.5 Programme Components and Plans
1.6 Status of the WWWDM Activities

CHAPTER 2 -Requirements for the Development of Specific Data Management Functions

3.1 Introduction
3.2 The Manual on Codes
3.3 The Numbering System of Code Forms and Binary Representations
3.4 Code Issues

CHAPTER 4 - Meteorological Data Representation: Alphanumeric (character) Codes

4.1 Introduction
4.2 Code Forms
4.3 Coding Procedures
4.4 Aeronautical Meteorological Codes
4.5 Observing Station Identification
4.6 Dates and Changes in Meteorological Codes

5.1 Introduction
5.2 BUFR (FM 94)
5.3 GRIB (FM 92)
5.4 Issues Raised by the use of Binary Representation Codes

CHAPTER 6 - The Use of Computer Graphics for Meteorological Data Representation

6.1 Introduction
6.2 Current Graphics Systems and Techniques
6.3 The User Interface
6.4 Standards for Meteorological Graphics
6.5 Representation of Image Data
6.6 Standard Environments

7.1 Introduction
7.2 Database Technology
7.3 Query Languages
7.4 Data Base Technologies Employed by Meteorological Services
7.5 Storage of Quality Control Information in Meteorological Data Bases

8.1 Introduction
8.2 The Relationship of the DDBs to the Existing WWW Infra-structure
8.3 Implementation of the DDBs
8.4 A Possible Implementation Strategy
8.5 The Role of the DDBs in Data Collection

9.1 Introduction
9.2 The Identification of Errors and Deficiencies within the WWW
9.3 The Role of the GOS
9.4 The Role of the GTS
9.5 The Role of the GDPS
9.6 The Role of Data Management

World Weather Watch Data Management (WWWDM) is the component within the World Weather Watch (WWW) system which provides those support functions needed for the overall management of WWW data and products, the most economical use of the resources of the WWW system components, and for monitoring data and product availability and quality. The underlying principle in the WWWDM design is the integration of the Global Observing System (GOS), the Global Telecommunications System (GTS) and the Global Data Processing System (GDPS) facilities, services and functions into an efficient system which works as a single entity.

The concept of WWW Data Management can be illustrated through consideration of the Open Systems Interconnection (OSI) 7 layer reference model (shown in Figure 1.1). The GTS provides the functionality of the lowest 3 or 4 layers of the model (depending on the particular circuit being considered). That is, the GTS consists of physical links across which data frames may be transmitted and acknowledged, a system to determine how messages are routed, and possibly (but not always) offering host-to-host error free data transmission. The GOS and the GDPS provide the functionality of the Applications Layer.

As already noted, the concept of WWWDM is one of carrying out those activities required to optimise the integration of the GOS, GTS and GDPS. In essence this is to be done by carefully examining the ways data are presented (or represented), and the "session level" procedures of the WWW in the light of changing technologies and requirements. Presentation Level issues include consideration of codes issues and more broadly how data are represented at various stages in their transport and manipulation. Session Level issues include consideration of how a session is established between WWW centres. Currently bilateral communication between centres (usually by mail) is used to establish that one centre holds a bulletin required by an adjacent centre which then undertakes to routinely on-forward that message as soon as possible after receipt. A limited range of ad-hoc queries (generally limited to requests for re-runs of missed data) are catered for using service messages.

WWWDM is to define and design proper procedures and interfaces, particularly in the area of data processing and telecommunications, to allow Members to obtain the coherent and appropriate sets of data and products required, despite the disparity in the levels of sophistication of technology and techniques of various WWW centers. An important objective for WWWDM is to allow for suitable interfaces, transition arrangements and support as the system components evolve, with a view towards enabling all Members to participate in the WWW at a level commensurate with their abilities and requirements, and to attain the appropriate level of technology as is necessary.

WWWDM is to provide specifications for data representation, including codes and exchange formats, guidelines for the design of data bases and storage of observational data and processed information. Standards in data representation and operational procedures will be introduced on a broad scale. The monitoring of WWW operations and the quality of basic data and output products are activities essential to the development of better Data Management (DM) practices. Regular information will be provided to Members on the status of operation of the WWW system and methods will be developed to correct deficiencies promptly.

The WMO Second Long-term Plan 1988-1997 (SLTP) introduced the WWWDM concept into the WWW Programme. It was adopted by the tenth session of the WMO Congress (Cg-X) in 1987. The WMO Congress (Cg-XI) in 1991 extended and refined this concept in the WMO Third Long-term Plan 1992-2001 (TLTP). The Commission for Basic Systems, in its ninth session in 1988 (CBS-IX), organised the programme by establishing the CBS Working Group on Data Management (WGDM) together with its Subgroup on Data Representation (WGDM/SGDR) and its Subgroup on Codes (WGDM/SGC). The latter emerged from the previously existing CBS Working Group on Codes. The Commission, through the Working Group on Data Management, is responsible for:

Resolution 5 (CBS-IX) (1988), for the first time, defined the Terms of Reference of the Working Group on Data Management which are reviewed by the regular sessions of CBS. The WGDM/SGDR deals mainly with the WMO binary data representation and graphical representation forms/standards, data base management issues and the impact of industry computer standards on meteorological graphics, while the WGDM/SGC handles all issues related to WMO character codes. Expert meetings and seconded consultants provide the necessary input of technical expertise.

At global level, the implementation of DM functions is co-ordinated through co-ordination/implementation meetings on the Main Telecommunication Network (MTN). The regional associations play an active role through regional co-ordination/implementation meetings, through specific regional DM training events and through their respective Working Groups on the Planning and Implementation of the WWW.

The doubling time for the volume of data generated and exchanged within the WWW system is currently around five years. This is caused by the progressive use of automation in environmental observing systems, such as the surface-based remote-sensing systems Radar, Sodar, Lidar, and the automated in situ observation systems ASAP, ASDAR and drifting buoys, etc. More satellite data will be produced due to improved retrieval procedures which yield higher resolution and frequency of vertical soundings. Oceanographic satellites will add a new load of wave and surface wind data to the data traffic on the GTS. The data volume generated by numerical weather prediction (NWP) will expand sharply due to the increasing number of types of analysis and forecast products, extended forecasting periods, enlarged geographical coverage and better horizontal and vertical resolution.

The total amount of generally available data and products is expected to exceed, in many cases, the requirements of any individual Member.

Uncontrolled injection of information sets into the GTS can soon lead to an overloading of communications links and national data bases and will thus hinder the Members' timely access to those sets of information needed for the efficient performance of their operations.

The necessity to cope with the ever growing data volume and, at the same time, stringent constraints in funds will spur many Members into an accelerated cycle of employing more automation. This trend may deprive many developing countries of the benefits to be gained from meteorological improvements, because access to the necessary information requires suitable computer facilities and powerful communication links which may not be readily available and/or affordable.

The technology evolving for data processing and telecommunications makes it possible to design systems for the management of meteorological data which will enable better co-operation between Members who are operating at different levels of technological sophistication. The 25 Regional Specialised Meteorological Centers (RSMCs) with geographical specialisation, and four RSMCs with activity specialisation in concert with the three World Meteorological Centers (WMC), provide an ideal starting point for the co-ordination of data storage and data exchange on a higher level between each other and the efficient and effective support with data and products of all National Meteorological Centers (NMC).

The rapidly growing appreciation of international standards for telecommunications and computer technology in the meteorological community, particular for computer graphics, software management and information exchange, opens new and promising prospects for the WWW system.

A dual system of meteorological formats is available for the exchange and storage of data and products, i.e., binary data representation forms for exchanging large data volumes between automated centers, and a system of character-oriented codes for the data exchange with non-automated centers or where bit-oriented codes are not practical.

Other WMO Programmes (e.g., World Climate Programme, Global Atmospheric Water, Hydrology and Water Resources Programme, Environmental Programme, etc.) should also benefit from the basic systems for the support of their operational requirements.

The WWWDM Concept has been set up in five major programme segments. Cg-XI approved the general policies for their realization and requested the relevant bodies of the Organization to proceed accordingly. The programme components are:

Although WWWDM is a new concept within the WWW system several important functions and services have already been implemented. Schemes for real-time and non-real-time monitoring of the quality and availability of data and the verification of products are in place in many WWW centers, and so-called Lead Centers have accepted the responsibility for the monitoring of specific categories of observational data and for the regular feedback to Members. The DDBs Concept is beginning to take shape. Realization of the concept is expected to lead to an improvement in the overall exchange of, and access to, data. Binary representation forms are being generally accepted, but only a small number of WWW centers actually command the technology to use them to exchange data on the GTS or to employ them within their GDPS centers. The WWW is now in an open-ended transition period from character codes to binary representation forms and the first proposals are emerging for an interface between the representation forms. There is an urgent requirement to adopt a standard for the representation of image data. Automation is steadily advancing into the developing and less-developed countries allowing more efficient data handling and exploitation. The exchange of meteorological computer programs among the Members, which was re-activated by CBS-IX, supports this trend. Much more work is necessary to develop, co-ordinate and implement the data management concept as an integral part of WWW operations.

The role of DM is to develop a set of requirements that will ensure that functions and services related to DM within each WWW component are adequately provided. The functions to be provided naturally fall into one of several categories; data representation, data exchange, and data monitoring. Each of these categories is considered in turn in this chapter.

The first function of DM is to establish agreed-upon forms for the representation of meteorological data; observations, observational metadata, gridded products, image products, and informational messages. Much effort has long been devoted to some of these functions, while others have received less attention. For example, alpha-numeric representation forms for observational data have been established and maintained for decades, while binary forms for observational data have existed only for a few years. At the other end of the spectrum, there is as yet no international agreement on a standard form for vector graphic and image data. Although the binary forms are sufficiently general to describe all meteorological data and remain our goal for the future, not all centers can handle the binary forms as yet. Thus, both binary and alpha-numeric representation forms will have to be maintained for the foreseeable future, and the issue of transformation between binary and alpha-numeric forms will remain with us as well. The following requirements may therefore be recommended:

The best approach to accomplishing the rapid distribution of meteorological observations from the GOS to the GDPS and routinely disseminated analysis and forecast products from the GDPS to users, is the store-and-forward methodology. This approach is currently used on the GTS. In this methodology, the GTS can be viewed as one continuous circuit with many nodes. Each node receives all its information from the previous node, stores the information it receives, and then sends the information required by the next node to it according to the instructions stored in the node's switching directory.

On the other hand, the GDPS has begun to express the need to issue ad hoc requests for meteorological observations, observational metadata, and new forecast products from NWP centers and send ad hoc notifications of erroneous observations to the observational sites. These ad hoc transmissions are not well served by the store-and-forward switching directory methodology because by their very nature the GTS nodes are unable to efficiently respond to ad hoc messages. Rather, ad hoc requests are best accommodated by request/reply mechanisms.

Presently only re-transmission of previously sent messages are permitted on the GTS. The re-transmission function is limited to messages that previously were sent over the link and does not satisfy the ad hoc request/reply need. A different mechanism is needed so that the GTS node can recognize an ad hoc request, satisfy the request from its own limited database, if possible, or forward the ad hoc request to the associated GDPS facility for a response.

In order to maintain current functions and add the needed new ones, certain requirements must be satisfied by the GTS:

However, these requirements are not sufficient. Before the request/reply capability can be used to satisfy the needs expressed by the GDPS, both the GOS and also the GDPS must satisfy certain requirements as well:

There are two distinct aspects of data monitoring; data quantity monitoring and data quality monitoring. Data quantity monitoring is concerned with the timely receipt of observations and products, while data quality monitoring is concerned with the "goodness" of the observations and products. In organizations where the responsibility for communications is separate from the responsibility for processing and product creation, the two aspects of data monitoring are similarly split. Typically, the communication function is concerned with the quantity of data while the computation or processing function is concerned with the quality of the data. In the WMO context of a node on the GTS, the Regional Telecommunication Hub (RTH) is typically concerned with quantity of the data while the National Meteorological Center (NMC) is typically concerned with the quality of the data.

Data quantity monitoring has many different forms depending primarily on the timing of the monitoring information that is collected and the timing of the analyses performed on the collected data. The various forms of monitoring fall into four basic categories:

Data quality monitoring is performed at the observation sites and at the NMCs. The observation sites monitoring programme is performed to ensure that "gross" errors are eliminated from data transmitted on the GTS. Data quality monitoring is typically performed at an NMC for two purposes. First, it is desirable to insure that only correct observed values are used in data disseminated to field forecast offices or to the general public. Incorrect observations not only distract from the quality of plotted charts, they can distort contours that might have been generated for the display by objective methods. Such problems attract attention and can be quite noticeable. Second, it is not only desirable, but crucial to insure that only unique, high quality observations are submitted to objective analysis schemes whose task it is to provide initial conditions for numerical prediction models. Such data problems are not seen by the forecast offices or general public, for they are only manifested through a degraded objective analysis and ensuing forecast. Since numerical prediction models have deficiencies unrelated to incorrect data that also lead to incorrect forecasts, it can be difficult to determine whether a forecast problem was due to a data or model deficiency, even for personnel of the NMC.

Because of its importance, much attention is paid to data quality monitoring at a typical NMC, and a wide variety of checks have been developed to insure the highest quality observational database is prepared. These checks fall into one of several categories:

Parts of a rather comprehensive monitoring program are thus already in place. The task for DM is to:

In order to accomplish these objectives, we are led to a number of requirements:

An important aspect of data management for the WWW is to establish common procedures for data representation, i.e. "character codes" and "binary representations". Such procedures serve to facilitate the timely national and international exchange of the vast volume of meteorological, geophysical, and environmental information required by individual Members to meet their specific operational responsibilities. National and international research and application programmes are also served by the availability of observations in common data forms.

These common procedures for international data representation are based on the concept of using codes to describe weather conditions, reports of instrumental readings, and processed data, thereby considerably reducing the length of messages, avoiding language problems and facilitating automatic processing.

Coded bulletins are used for the international exchange of meteorological information comprising observational data provided by the WWW Global Observing System and processed data provided by the WWW Global Data-processing System. Coded messages are also used for the international exchange of observed and processed data required in specific applications of meteorology for various human activities and for exchanges of information related to meteorology.

Messages may take the form of either a set of code forms, defined by standard procedures, for alphanumeric data exchange (character codes) or a set of representation forms with their specifications and associated code tables for binary data exchange (binary representations). Rules concerning the selection of codes and representation forms for international exchange are specified in the WMO Technical Regulations, Volume I, Chapter A.2.3 (WMO Publication No.49, Ed.1988).

The code and representation forms are described in the Manual on Codes (WMO Publication No. 306), which comprises Volumes I (Parts A and B), and II, dealing with international and regional codes respectively.

The Manual on Codes, Volume I - International Codes - consists of Part A (Alphanumeric codes) and Part B (Binary representations). Together they form part of the Technical Regulations and are referred to as Annex II to the Technical Regulations. They contain international regulatory material stemming from recommendations of the WMO Commission for Basic Systems (CBS) and decisions taken by the Executive Council and the President of WMO.

National practices regarding the coding of certain elements in reports, analyses, or forecasts for international exchange are included in Volume I as an appendix. In addition, Volume I contains three attachments, printed on yellow paper, which are included for information only and do not have the status of WMO Technical Regulations.

The Manual on Codes, Volume II - Regional codes and national coding practices - consists of seven chapters, six of which are devoted to the six WMO Regions, and the seventh to the Antarctic.

Volume II is not part of the WMO Technical Regulations. It contains regional procedures for the use of international code forms as well as regional code forms which are intended only for exchanges within a given WMO Region, as formally adopted by the regional association concerned. Procedures and code forms for use in the Antarctic, are adopted by the WMO Executive Council on the advice of the EC Working Group on Antarctic Meteorology.

Volume II also contains national coding practices relating to the use of international or regional codes and information on national code forms which might be of interest to other countries. Some special codes which are used in messages exchanged over the WWW Global Telecommunications System circuits, which include ice coverage and satellite ephemeris, are included in Volume II as an appendix.

Each international code form and binary representation bears a unique number from 10 to 99, preceded by the indicator letters FM. This number is followed by a Roman numeral to identify the sessions of CBS (or CSM prior to 1974) which either approved the code form as a new one or made the latest amendment to the previous version.

A code form approved or amended by correspondence after a session of CBS receives the number of that session.

An FM number is allotted to an international code form or binary representation in accordance with the following categories:

10 to 29	code forms for surface reports
30 to 43	code forms for upper-air reports
44 to 59	code forms for analyses and forecasts
60 to 69	code forms for oceanographic and hydrological reports and forecasts
70 to 79	code forms for climatological reports
80 to 89	code forms for atmospherics and satellite reports
90 to 99	binary representation forms (reports, analyses, forecasts)

For regional code forms a different numbering system is used. It starts with the indicator letters RF and a number 1 to 6 corresponding to the WMO Region in which the code form may be used (or the number 7 if the code form is intended for use in the Antarctic), separated by a solidus (/) from a two-figure number, allotted in numerical order from 01 upwards for each WMO Region or the Antarctic.

This numbering enables the code forms and binary representations to be distinguished from one another and from the code tables, which are numbered with a four-figure number for international character codes and a three-figure number for regional character codes.

Furthermore, an indicator term consisting of one or a maximum of two words (preferably one word of no more than five letters) is used to designate the code form or binary representation colloquially and is therefore called a "code name". This abbreviated code name should, as far as possible, succinctly reflect the basic purpose of the code. In some cases it is included as a symbolic prefix in the code or representation form to assure identification in transmissions, e.g. CLIMAT or GRIB.

A reference list of the international code forms and binary representations, together with the corresponding FM numbers and the full code names (reflecting in a comprehensive manner the basic purpose of the code), is included in Volume I of the Manual on Codes. This list also indicates the decisions of the Executive Council or the President of WMO relevant to the particular alphanumeric code or binary representation.

A listing of regional code forms, together with the corresponding RF numbers and the full code names, is included separately in the chapters devoted to the particular Regions, or the Antarctic, in Volume II of the Manual on Codes.

As noted earlier, the WWW is now in an open ended transition period that began with the first use of a binary format for data transmission and will end when the last message is transmitted in a character code format, if ever. The WMO recognized the continued need for character codes for an unspecified period of time, stating in its long-term plan: "A dual system of meteorological formats will be used for the exchange and storage of data and products, namely bit-oriented codes for exchange of large data volumes between automated centres, and a system of character-oriented codes for the data exchange with non-automated centres where bit-oriented codes are not practical."

There is a potential demand for some centres to ingest BUFR (binary) messages and then reformat them back into (current) WMO character code forms for local transmission on character lines. Before undertaking such a course of action serious thought must be given to the purposes of such retransmissions. If they are undertaken to supply non-automated centers with "human-readable" information, then it makes more sense to drop the use of the sometimes complex WMO codes and instead send the information out in a simple tabular form, provided, however, that the telecommunications lines and receiving equipment can accommodate the larger volume of traffic that would result. Eventually, the adoption of suitable tabular formats would eliminate the need for training humans to decode the sometimes obscure WMO code forms. Programming to generate tables, for transmission and display, is much simpler than generating the current WMO character codes.

This chapter provides a detailed description of the alphanumeric codes used to transmit meteorological data. The material presented is not intended to supersede the Manual on Codes (WMO Publication No. 306) but rather provide an explanation of how these codes have evolved to their present formats and the nature of the inter-relationships between the various codes. This chapter also consolidates in a single location references to the source material required by a practitioner intending to use these codes in an operational centre.

Each alphanumeric code is designed to provide a particular type of information, which may be data obtained from an observing program or system as in SYNOP and TEMP, processed data in the form of statistics as in CLIMAT, processed data in the form of an analysis or forecast as in IAC and GRID, or forecast information as in TAF and ARFOR.

Coded bulletins may be divided into well defined Parts and/or Sections containing appropriate components of the information and identifying information included for regional or national use only. In the Manual, Regulations contain standard coding procedures to be observed and Notes provide additional guidance on the use of the code.

The code forms are designed to be as brief as possible, commensurate with relatively easy manual or automatic encoding and decoding. Unnecessary repetition of data, or the unnecessary inclusion of indicator or control groups or letters is avoided. Only letters from the Latin alphabet, Arabic numerals, and the solidus (/) are used in code forms. The ellipsis (...) may be used in the description of code forms to indicate omitted groups but will not be found in the transmitted codes themselves.

Symbolic words, symbolic figure groups, and code groups, including those which are included in the report only in certain circumstances, are placed in an appropriate position in the code form, so as to avoid the risk of confusion during transmission and to obviate the possibility of ambiguity during decoding. In accordance with WMO Technical Regulation [A.2.3.]1.2.2, symbolic words, groups, and letters (or groups of letters) required for regional or national purposes only are selected so as not to duplicate those used in international code forms.

Symbolic words and symbolic figure groups are used as code names, symbolic prefixes or indicator groups. Symbolic words (and indicator letters) are made up of upper case letters only. Whenever symbolic words and groups in regional codes are already used in international codes, they retain their international character.

Code words are included in a coded report, analysis, or forecast either as symbolic prefixes to identify particular information, e.g. ICE, NORMAL, or in place of certain code groups when specified conditions occur, for instance the code word CAVOK.

The meaning of symbolic words, figures, and groups used in international codes, together with reference to the particular code forms in which they are used, is contained in Volume I, Part A of the Manual on Codes. The meaning of symbolic words, figures, and groups used only in a WMO Region or the Antarctic, together with references to the particular code forms in which they are used, is contained in the chapter devoted to that Region or the Antarctic in Volume II of the Manual on Codes.

Code groups may be described solely with symbolic figures, or symbolic figures and symbolic letters (or groups of letters). In the latter case the symbolic figures are used to indicate that particular information follows. The symbolic letters (or groups of letters) in the code groups represent meteorological or other geophysical elements. In messages, these symbolic letters (or groups of letters) are transcribed into Arabic numerals indicating the value or the state of the elements described in accordance with the standard coding procedures contained in the relevant regulations and specifications.

Code groups put in round brackets are optional items that may or may not be included in the report, analysis, or forecast, depending on specific conditions. The absence of round brackets means that the inclusion of the groups concerned is determined by international or regional decision and is mandatory; these decisions are indicated in the regulations included with the description of each code form. When a code group, or a number of code groups, is used more than once under certain circumstances, it (they) are followed in the code form by a group (groups) of dots.

Except in aviation and radiological reports, analyses, or forecasts (see paragraph 4.4), code data groups are generally composed of not more than five characters, either figures or upper case letters. These limitations stem from historical ITU Telegraph Regulations for traffic subject to charge per word, in which code data groups in excess of five characters were counted as two (or more) words and that the mixed use of figures and letters in one code data group was prohibited. In 1981 these restrictive ITU Telegraph Regulations and the related CCITT Recommendations were eased to allow single "word" code data groups of up to 10 characters. This prompted the WMO Commission for Marine Meteorology to recommend the use of ten-figure groups for ship-to-shore transmissions of ships' weather reports (see WMO Publication No. 386, The Manual on the GTS, Attachment I-1, paragraph 2.2).

Code forms are built up from a number of well-defined components, each comprising a different type of coded information. Components which can be transmitted as a separate report are called parts and carry special identification groups. Code forms, or their parts, can be further divided into sections which must not be transmitted separately.

The first section of a code form, or its parts, should contain at least identification data (indicating the type of coded information) and begin with the code MiMiMjMj or the abbreviated name of the code. Position and time groups may, depending on the nature of the report, be included in the first (identification) and/or in the subsequent section(s).

Each subsequent section begins with one or more symbolic indicator figure(s) or an indicator group of at least two figures, preferably in some logical order. Sections which may be omitted from the report under certain conditions are placed in round brackets. In order to facilitate automatic processing, code forms do not normally provide for any written text unless in a separate section.

Brief explanations of the code form are included in a number of Notes under the code form, usually indicating the following: the parts and sections comprising the code form, what kind of data are to be transmitted in these parts and sections, as well as explanations and special features of the code form.

Regulations governing coding procedures and Notes on the use of the code are an essential part of the code form. Regulations indicate the circumstances under which particular parts, sections, code groups, and words should (or should not) be included in the report, analysis, or forecast. Regulations also contain procedures regarding the standard practice in the transcription of symbolic letters (or groups of letters) into figures indicating the value, or the state of, the element described.

For international codes, these regulations carry the same status as the WMO Technical Regulations. Consequently, the standard coding procedures are distinguished by the use of the term "shall" in the English text, and by suitable equivalent terms in the French, Spanish and Russian texts.

A similar practice is followed in regional coding procedures with regard to international code forms as well as in coding procedures related to regional code forms, although here the word "shall" in the English text (and the equivalent term in the French, Spanish and Russian texts) has its dictionary meaning and does not have the regulatory character as in the WMO Technical Regulations.

Notes providing additional explanation, information examples or cross-references, may be appended to the regulations. The word "shall" is not used in these notes.

Where national practices do not conform with the standard international or regional coding procedures, Members concerned shall formally notify the Secretary-General of the WMO for the benefit of other Members. Information on these practices is including in the WMO Manual on Codes, Volume II.

Symbolic letters (or groups of letters) are made up of either lower case or upper case letters, with or without subscript and/or superscripts. Whenever possible, the symbolic letters (with their subscripts) suggest the element or phenomenon being described. Subscripts may be made up of either lower case or upper case letters or figures, or any combination thereof but with a maximum of two characters. The use of superscripts is (generally) limited to the apostrophe (') to indicate an element or phenomenon which is (or was historically) related to another element or phenomenon indicated with a similar symbolic letter (or group of letters) but with some difference in its observing and/or reporting practice, e.g. V_s - Visibility seawards (from a coastal station), and V'_s - Visibility over the water surface of an alighting area. Superscripts are also used in code forms to indicate the repetitive use of certain code data groups or data lines, allowing the message, when in printed form, to have the characteristics of a table, e.g., the WINTEM message. In this case the superscripts used in the first code data group or data line(s) is the figure 1, in the subsequent data group or data line(s) it is the figure 2, to be followed by a group or line of dots and completed with the last code data group of the data line and/or the last code data line(s) with superscript lower case letters i,j,k,m or n, as the case may be.

The transcription of a symbolic letter (or group of letters) used in code forms into figures requires its unambiguous specification, indicating the meaning of the symbolic letter (or group of letters) and the units in which the element concerned is to be coded and/or reference made to the code table for the element or phenomenon in question. Only those units of measurement which have been approved by the WMO Congress are used in the codes.

In some cases the specification of the symbolic letter (or group of letters) is sufficient to permit a direct transcription into figures. However, when the number of significant figures of this value (expressed in the units given in the relevant specification) is lower than the number of symbolic letters reserved for this element, one or more zeros, as appropriate, must be inserted at the left of the significant figure(s) of the reported value.

Additional explanations, references, and/or standard coding procedures relating to the specification concerned are added, where appropriate, to the specification in the form of notes. Notes indicating standard coding procedures are distinguished from other notes by the use of the word "shall" in the English text, and by suitable equivalent terms in the French, Spanish and Russian texts (see paragraph 4.3.1).

A similar practice is followed in coding procedures related to specifications of symbolic letters (or groups of letters) used in regional code forms, although here formally the word "shall" in the English text (and the equivalent term in the French, Spanish and Russian texts) has its dictionary meaning and does not have the regulatory character as in the WMO Technical Regulations.

Clearly the same symbolic letter (or group of letters) cannot be used for specifying different types of information in one code form and, preferably, should have a unique definition for all code forms. However, in some cases the same symbolic letter (or group of letters) is used for different types of information in different code forms.

The specifications of symbolic letters (or groups of letters) used in international codes, together with reference to the code table for the element or phenomenon in question, where appropriate, and references to the particular code form (or group in that code form) in which these symbolic letters (or groups of letters) are used, is contained in Volume I, Part A of the Manual on Codes.

Where symbolic letters (or groups of letters) represent non-numeric coded information, code figures are required, the specifications of which are given in special code tables for each element or phenomenon.

Each code table bears a unique number. Code tables corresponding to symbolic letters (or groups of letters) used in international character codes are numbered with four figures from 0100 up to 5299 and allotted in the alphabetical order of the symbolic letters (or groups of letters) in accordance with the following scheme:

The numbers attributed to code tables corresponding to symbolic letters (or groups of letters) used in international character codes, are given in a table preceding the relevant individual code tables, which are included in Volume I, Part A of the Manual on Codes in accordance with WMO Technical Regulation [A.2.3.]1.3.1.

Code tables related to symbolic letters (or groups of letters) for regional use only, are numbered with three figures ranging from 120 to 799 as follows:

Within the range of code table numbers available for a Region or the Antarctic, individual regional code table numbers are allocated in the alphabetical order of the symbolic letters (or groups of letters) used in that particular Region or the Antarctic, although due to the limited numbers (80) available for allocation in each Region or the Antarctic, no rigid scheme has been developed for this purpose.

The numbers attributed to code tables corresponding to symbolic letters (or groups of letters) used only in a given WMO Region or the Antarctic, are listed in a table preceding the relevant individual code tables in the chapter devoted to the Region concerned or the Antarctic in Volume II of the Manual on Codes.

The code tables indicate the symbolic letter (or group of letters) with its specification, followed by a listing of code figures with their corresponding specifications, i.e. value of elements, type and/or state of phenomenon, etc. When appropriate, explanatory notes may be added to a code table. In principle, these notes should not contain regulations for the coding of phenomenon or elements.

All possible code figures are included in the tables. Code figures not presently used but available for future allocation are labeled with the word "reserved". Code figures which are not used and for technical reasons are not available for future allocation, are labeled with the words "not used". Code figures in some tables are supplemented, when appropriate, with a solidus (/), usually to indicate that for some reason particular information is not available or is undetermined. Otherwise the solidus is used in transmissions to indicate missing data.

Aeronautical meteorological codes (METAR, SPECI and TAF) have been developed, in conjunction with the CAEM and the ICAO, from specific aeronautical requirements as contained in WMO Technical Regulations [C.3.1] and with the realization that they are being used by both meteorological and non-meteorological personnel involved in aeronautical operations. Aeronautical meteorological codes, therefore, need to have a simple, self-evident and unambiguous direct-reading quality.

In view of the above, the structure of aeronautical meteorological codes is such that the individual code groups, following each other in the prescribed order, each contain a specific piece of information regardless of the number of characters required.

To allow for easy identification and to avoid misinterpretation, code groups or extensions thereof may include identifier letters (rather than figures) or standard abbreviations, when appropriate, e.g., the identifier "R" stands for runway visual range, "MPS" for meters per second, etc. Consequently, and contrary to the practice in other meteorological codes (see section 4.2.3), code groups in aeronautical meteorological codes contain a non-uniform number of characters (ranging from 2 to 15 characters) and the code data groups in these reports or forecasts may consist of figures or letters or any combination thereof. In addition, code data groups in aeronautical meteorological reports or forecasts indicating significant present or forecast weather (w'w') may be preceded by a plus (+) or minus (-) sign, indicating the intensity of a significant present or forecast weather phenomenon, as appropriate.

When a phenomenon does not occur, or the state of a phenomenon or the value of an element is of no significance to aeronautical operations, the corresponding group, or the extension of a group, is omitted from a particular report or forecast. Again contrary to the practice in other meteorological codes, these optional groups (or extensions of groups) are not distinguished in the code form. Round brackets put around groups in aeronautical meteorological codes serve a different purpose, i.e., to indicate that the use of the group(s) concerned is determined by regional or national decision.

Differences in coding procedures as just described with respect to the METAR, SPECI and TAF codes, are also applied in related meteorological codes (ARFOR, ROFOR), as well as in AMDAR and WINTEM, and the radiological codes (RADREP, RADOF).

Each code form provides for proper identification of the coded message and includes code groups for its positioning in space and time. For fixed observing stations, whose position cannot change with time, station index numbers permit the identification of the stations, including their location (and other particulars). For mobile observing stations, whose reports clearly require the full inclusion of

positioning groups, additional station identification allows meteorological services or centres to follow and recognize the successive reports from those stations.

Except in aeronautical meteorological codes (see paragraph 5.4), fixed land stations at which meteorological observations are made are identified by a five figure group consisting of a two figure block number (II) followed by a three figure station number (iii).

The block number defines the area in which the reporting station index is situated. The station index numbers have been allocated as follows:

Region I: Africa	60000 - 69999
	20000 - 20099
	20200 - 21999
	23000 - 25999
	28000 - 32999
Region II: Asia	35000 - 36999
	38000 - 39999
	40350 - 48599
	48800 - 49999
	50000 - 59999
Region III:South America	80000 - 88999
Region IV: North and Central America	70000 - 79999
Region V: South-West Pacific	48600 - 48799
	90000 - 98999
	00000 - 19999
	20100 - 20199
	22000 - 22999
Region VI: Europe	26000 - 27999
	33000 - 34999
	37000 - 37999
	40000 - 40349
Stations in the Antarctic	89000 - 89999

Block numbers are allotted to the services within each Region by regional agreement.

Station numbers (iii) corresponding to a common block number (II), except 89, are usually distributed so that the zone covered by this block number is divided into horizontal strips; e.g., one or several degrees of latitude. Where possible, station numbers within each strip increase from west to east and the first figure of the 3-figure station number increases from north to south.

Station index numbers for stations in the Antarctic (Block 89) are allocated by the Secretary-General in accordance with the following scheme:

Station index numbers consisting of one figure repeated five times, e.g. 55555, 77777, etc., or ending with 000 or 999, or duplicating special code indicators, e.g. 10001, 77744, 19191, 89998, etc., are not assigned to meteorological stations. The general list of station index numbers, together with information on name and location of the observing stations and their observing programmes, is published in Volume A of WMO Publication No. 9.

In aeronautical codes, fixed observing stations are identified by a 4-letter station indicator in the form CCCC, i.e., the ICAO international location indicator. ICAO Publication Doc. 7910 contains a description of the system of assignment and a complete listing of the ICAO international location indicators.

Mobile land station making an upper-air observation or issuing a radiological report on a routine or special basis, are identified by a call sign consisting of three or more characters. It is recommended that this group should be encoded in the form A1A2DDD, where A1A2 are the two-letter geographical designators related to countries or territories as specified in Table C1, Part I of Attachment II-6 of Volume I of the Manual on the GTS (WMO Publication No. 386). The DDD is a location designator composed of the first three letters of the name of the town or commune where the mobile land station made its observation.

Fixed sea stations (lightships and fixed platforms) at which meteorological observations are made and reported using land code forms, are included in the system of station index numbers described in paragraph 4.5.1, and are thus identified by the 5-figure station index number in the form IIiii. Otherwise, fixed meteorological observing sea stations are identified by either the call sign of the ship in the form D...D or an identification group in the form A₁b_wn_bn_bn_b, as appropriate (see paragraph 4.5.4, below).

Mobile sea stations (ships, buoys, rigs and platforms) making meteorological observations, are identified by either the call sign of the ship in the form D...D or, in the case of a drilling rig, oil- or gas-production platform, and drifting or moored buoys, an identification group in the form A₁b_wn_bn_bn_b. The call sign of a ship is composed of three or more alphanumeric characters.

In the identification group A₁b_wn_bn_bn_b, A₁b_w normally corresponds to the maritime zone in which the observing station has been deployed. A₁ being the number of the WMO Region (1 - Region I, 2 - Region II, etc.), and bw the number of a sub-area belonging to the area indicated by A₁ (see Manual on Codes, Volume I, Part A, code table 0161).

The WMO allocates to Members, who request and indicate the maritime zone(s) of interest, a block or blocks of serial numbers (nbnbnb) to be used by their drilling rigs, oil- or gas-production platforms and drifting or moored buoys. The Member concerned registers with the WMO the serial numbers actually assigned to individual stations together with their geographical position of deployment. The WMO then informs all concerned of the allocation of serial numbers and registrations made by individual Members.

In reports of sea stations other than buoys, drilling rigs and oil- or gas-production platforms, and in the absence of a ships' call sign, the word SHIP is used for D...D.

An international hydrological observing station identification number in the form (OOOAC_i) BBi_Hi_Hi_H is included in the reports of hydrological observation for a hydrological station and in a hydrological forecast. The two groups permit the identification of the WMO Region (A), country (C_i), river basin or group of basin (BB) and the station (i_Hi_Hi_H). The allocation of identification numbers is the responsibility of regional associations for C_i and BB, and Member countries for i_Hi_Hi_H.

A Region may have a maximum of 99 indicators for large basins or groups of small basins. The number BB=00 is not used. If a country straddles several basins (BB), it should nevertheless have only one and the same figure for C_i. If a basin BB comprises all or part of the territory of more than ten countries, C_i should be allocated starting with the largest countries, giving joint national numbers to others (the smallest). In the latter case the national identification numbers of the station (i_Hi_Hi_H) should be allocated by regional agreement.

Alternatively large river basins composed of more than nine countries may be divided into several sub-basins, each one of which may be allocated a separate BB; thus the number of countries will be less than ten in each BB. In each country and for a portion of a basin BB, the national identification numbers of stations (i_Hi_Hi_H) increase from 010 to 999 from west to east and from north to south. The numbers from i_Hi_Hi_H=000 to i_Hi_Hi_H=009 may be reserved to designate the identification of hydrological forecast centres.

The lists of Ci and BB are published in Volume II of the Manual on Codes and the lists of i_Hi_Hi_H will be published in a separate volume (Operational Hydrology Report No. ..., WMO Publication No. ...). (This publication will appear at a later stage.)

Transport aircraft in which upper air meteorological observations are made and reported using the AIREP message format, are identified by the call sign of the aircraft as the first group of the report. This call sign is normally composed of an ICAO three-letter designator indicating the aircraft operating agency, and a three- or four-figure flight number. In the absence of an aircraft call sign, the indicator letters ARP are used as the first group of the report. The ICAO designators for aircraft operating agencies are published in ICAO Publication Doc. 8585.

In reports of data derived from observations by meteorological satellites (SATOB, SARAD, SATEM), the group I₁I₂I₂ (completed with I₃I₄ or solidi) is used to identify the particular meteorological satellite. The symbolic letter I₁ gives the name of the country or international agency which operates the satellite (see Manual on Codes, Volume I, Part A, code table 1761) and the symbolic letters I₂I₂ is the indicator figure for satellite name (supplied by operator I₁) in which even deciles are used for geostationary satellites and odd deciles for polar-orbiting satellites.

In satellite ephemeris messages which are issued in national code forms by the USA (TBUS) and the (erstwhile) USSR (FANAS) to transmit information for predicting the path, or locating the position, of polar-orbiting environmental satellites, there is no standardized procedure for identification of meteorological satellites. In TBUS messages the meteorological satellite concerned is indicated by its national operational serial number (NOAA-N) in the first (identification) section of the message, whereas in FANAS messages the meteorological satellite concerned is indicated by the first group in Section 1 of the report, in the form 11L_sS_sS_s. Following the indicator figures 11, symbolic letter L_s indicates the launching country in a code similar to that of symbolic letter I₁ and symbolic letters S_sS_s give the number (series of the satellite) as follows:

A full description of the TBUS and FANAS codes is contained in the appendix to Volume II of the Manual on Codes.

In messages containing processed meteorological data in the form of grid-point values (GRID, GRAF) or radiological trajectory forecasts (RADOF), the first line of the text of the coded meteorological analysis or forecast contains an identification group in the form F₁F₂NNN or F₁F₂Y_rY_rG_rG_r respectively, consisting of an indication of the data-processing centre originating the product and a reference to grid system used (NNN) or the date and time of issue of the forecast (Y_rY_rG_rG_r). The allocation of centre identifiers F₁F₂ is listed in the Manual on the GTS, Volume I, Part II, Attachment II-9, Table A (WMO Publication No. 386).

There is a need for developing new or updating existing meteorological codes to meet new or changed requirements. For international meteorological codes it is the responsibility of CBS and its WGDM to review the stated requirements and to recommend appropriate action. It is the CBS policy not to change codes, or introduce new code forms, unless there are pressing needs.

Regional procedures for the use of international meteorological codes and meteorological codes which are intended only for exchanges within a given WMO Region or the Antarctic, are the responsibility of the regional associations concerned and their Rapporteurs on DM or, in the case of the Antarctic, the WMO Executive Council upon the advice of the EC Working Group on Antarctic Meteorology, to review the stated requirements and to decide on appropriate action.

The relevant decisions, taken by a regional association or, in the case of recommendations by the Commission for Basic Systems or the EC Working Group on Antarctic Meteorology, taken by the Executive Council or the President of WMO, as appropriate, also include a date of introduction for the new or amended code, which normally takes due account of the time frame required for proper world- or region-wide implementation, such as updating of national publications of coding instructions, training of personnel, adaptation of computer programmes, etc. This date of introduction should preferably be the first day of a month, but not coincide with an internationally recognized public holiday like New Year's Day, 1 January.

In order to provide Meteorological Services with advance notification of changes of operational importance (which include important changes in meteorological codes), the WMO Secretariat issues at weekly intervals (on Thursdays) telegraphic messages containing advance notification of such changes. These weekly telegraphic messages are identified by the code name METNO. Detailed description of the distribution, format and contents of METNO messages are given in the relevant parts of the Introduction to WMO Publication No. 9, Volumes A and C.

In addition to the METNO weekly telegraphic notifications, information on important changes, including meteorological codes and (binary) data representation forms, is included in the monthly letter on the operation of the World Weather Watch (WWW) and Marine Meteorological Services (MMS). The monthly letter is issued on the last working day of each month in English, French, Spanish and Russian.

Eventually, of course, all changes to meteorological codes are incorporated in the Manual on Codes, either through numbered supplements to the current (loose leaf) edition, containing replacement pages or instructions for manuscript corrections, or by the issuance of a new edition.

The Character Code Forms provided the means to overcome the barriers of language, and enabled meteorological information to be interpreted correctly and accurately by any person with sufficient knowledge, regardless of race or native tongue. With the advent of automated data processing it has been recognised that a corresponding need exists to represent meteorological data in a way which can be readily interpreted by any computer, irrespective of make, operating system, or internal data representation. Whereas the most generally recognised form of data representation among the peoples of the world is the numerical system based on the so called "Arabic" notation, for computer applications the most recognised form is based on the binary representation of whole numbers.

In developing binary representation forms for the representation of meteorological data it has been recognised that:

Ideally, a self defining binary representation form should be universal - capable of representing a required set of data. In practise, the last consideration in the previous paragraph has resulted in two forms being developed for the representation of meteorological data - FM 92 GRIB, used mainly for the representation of products, and FM 94 BUFR, used mainly for the representation of observational data.

Over the past few years the WMO, with assistance from a number of the world's operational meteorological/oceanographic processing centers, have been collectively developing a new system for the exchange and storage of meteorological, hydrological and oceanographic observations, known as BUFR, for Binary Universal Format for Representation of data. In so doing, they have developed a very flexible data representation system that is suitable for any kind of data, not just meteorological information.

The key to understanding the power of BUFR is the code's self- defining nature. A BUFR message not only contains meteorological data; it also includes a complete description of what those data are: the description includes identifying the parameter in question (height, temperature, latitude, whatever), the units, any decimal scaling that may have been employed to change the precision from that of the original units, any data compression that may have been applied for efficiency, and includes specifying the number of binary bits used to contain the numeric value of the observation. This information, the "data description", is all contained in tables which are the major part of the BUFR documentation.

The strength of this self-defining feature is in accommodating change. For example, if new observations or observational platforms are developed, there is no need to invent a whole new code form to represent and transmit the new data; all that is necessary is the publication of additional data description tables. Similarly for the deletion of possibly outdated observations - instead of having to send "missing" indicators for a long period while awaiting a change to a fixed format code, the "missing" data are simply not sent in the message and the data description section is adjusted accordingly. The data description tables are not changed, however, so that archives of old data may be retrieved.

This self-descriptive feature leads to another major advantage over character oriented codes - the relative ease of decoding a BUFR message. Where a large number of specialised and complex programs are now needed to decode the plethora of character codes in current use, it is entirely feasible to write a single "universal BUFR decoder" program capable of decoding any BUFR message. Such has been done at ECMWF, NMC Washington and presumably at other centers. It is not a trivial exercise to write such a BUFR decoder, but once done, it is done virtually for all time (except for extensions which may be needed to accommodate new features). The program will not have to change with changes in observational practices; only the tables will be augmented, a relatively straight forward task.

The development of BUFR has been synonymous with the development of the data description language that is integral to it. Indeed the major portion of the full description of BUFR is a description of the vocabulary and syntax of the data description language. These are manifested in the tables of the BUFR documentation. The definition of the data description language, and the "descriptors" that are its vocabulary, are what give BUFR its "universal" aspect; any piece of information can be described in the language, not just meteorological observations. The full details of the data description language are available in WMO Publication No. 306, Volume 1, Part B.

Another major aspect of BUFR is reflected in the first initial, "B": BUFR is a pure binary or bit oriented form. All the numbers in a BUFR message, whether data descriptors or the data themselves, are binary integers; a paper representation of the contents would consist of a long string of 0 and 1 values, almost unintelligible to humans. Thus BUFR can only be assembled with the aid of a computer, and requires a computer for its meaning and contents to be displayed. Thus, some degree of automated data processing is essential for the support of binary representation forms such as BUFR.

Given that some form of automated data processing is widespread in the developed world, and seen as highly desirable in the developing nations, the true binary nature of BUFR has been deliberately developed to make it highly machine independent. Since BUFR is comprised entirely of binary integers any brand of machine can handle BUFR as well as any other.

The binary nature of BUFR leads to another advantage over character codes: the ease and speed of converting the message into an internally useful numeric format. With character codes the conversion from ASCII (or EBCDIC) to integer or floating point is expensive relative to the conversion from binary integers to floating point. The latter is all that BUFR requires. In some recent tests, the ECMWF found a speedup of better than 6 times in decoding BUFR messages over the corresponding TEMP (WMO radiosonde character code) messages. The BUFR data also required about half the machine memory as the character data.

All of this does assume the availability of well designed computer programs that will be capable of parsing the descriptors, which can be a complex task, matching them to the bit stream of data and extracting the numbers from it, responding properly to the arrival of new (or the departure of old) data descriptors, and reformatting the numbers in a way suitable for subsequent calculations. The bit oriented nature of the message also requires the availability of bit transparent communication systems such as the appropriate levels of the X.25 protocol. Such protocols have various error detecting schemes built in so there need be little concern for the garbling of information.

The vocabulary of data descriptors is given in terms of the tables that are the bulk of the BUFR definition. The table entries for each descriptor are:

The "parameters", as understood in the BUFR context, include not just the meteorological variables, but also such things as the four-dimensional location of the observation, the block/station number, the instrumentation, the "significance" of the observation, the quality, etc. In other words, all of the pieces of information, all of the "co-ordinates" in multidimensional space that describe an observation, are parameters embraced by BUFR.

As an example of the steps necessary to prepare a data element for a BUFR message, consider the latitude of an observation point, having a value of -45.76 degrees (south). The appropriate descriptor table reference (005012 for this example) shows that the units are degrees, and that the number is to be scaled by a factor of 100; thus the scaled value becomes -4576 centidegrees. The reference value for latitude is -9000, thus the element with the reference subtracted from it is 4424. The particular reference value was selected to ensure that all possible latitude values end up as positive, thus avoiding any machine dependency in the representation of negative numbers. The last step is then to place the 4424 value on a "word" 15 bits in length. The bit length was selected by considering the largest value that the scaled and referenced value might ever take on, and selecting a word-length sufficient to represent that value. This is trivial for latitude; some thought had to go into selecting scale factors, reference values, and word-lengths for other (e.g., meteorological) variables.

In BUFR, at present, there are some 22 separate classes within the table of descriptors, classified by their content. The first seven of the tables deal, in effect, with the "coordinates" of observations: their identification, instrument types, four dimensional location, and "significance", the last including such things as indicating mandatory or significant levels in RAOBs, land/sea distinctions, etc. The remaining tables specify actual measured parameters in logical groupings: vertical elements and pressure, wind, radiation, clouds, etc. Not all of the elements described are measured values; many of the "data" are references to code tables or bit flag tables, which allow current qualitative observational practices to be included in the essentially quantitative BUFR representation. The latter tables are also included in the BUFR documentation.

The use of code tables allows BUFR to describe qualitative information in a numeric form. The scaling employed within the BUFR tables has been selected to assure adequate precision for the values of the parameters in the BUFR message. If an alternative unit of measurement for a parameter, degree of precision desired, or other variables wanted, all that is necessary is to use operators to re-define precision, or add new descriptors to the table. Once a descriptor has been placed in a table it normally will not be changed; this ensures that archives will remain accessible.

In its most elemental form, then, the essential parts of a BUFR message are a collection of descriptors matched up one-for-one with the data elements described. The descriptors are all fixed length; the data elements have variable length, as specified in the tables. This could be very inefficient as the descriptor list could easily exceed the length of the data described, This potential for inefficiency is recognised in the BUFR system, which leads directly into the next topic.

The use of descriptors of type 1 and 3 make it possible to reduce greatly the overhead of including many descriptors in every message when the layout of the data is the same from observation to observation. One "standard" observation, no matter what its length or number of elements, can be described with one (type 3) descriptor. Indeed, that is the definition of "standard": the presence of a sequence of descriptors in the type 3 table establishes the standard. (Just how many such standard sequences should be defined has been a matter of some discussion.)

There are, naturally, a rather large number of rules that specify the use of these descriptors and how they interact. Reference to the Manual on Codes (WMO Publication No.306) provides details. The rules were crafted with some considerable care and seem to be free of inconsistencies. Taken together, they are a specification sufficient for writing computer programs to encode or decode BUFR messages.

There is a lot of room in the descriptor tables: X, the class, can range up to 63 (currently tables are defined through X = 31), and Y, the element entry, up to 255 (the largest in use is 63). The regions in the table from X = 54 to 63 and Y = 192 to 255 (inclusive) are reserved for local use and may contain any descriptors that the local center wants to put there; the contents of the rest of the table will be agreed upon by international convention and will be universally available. BUFR even includes a set of descriptors describing the descriptor tables themselves so that updates can be sent around in BUFR code. It is a "universal" format, after all.

BUFR makes quite efficient use of space by virtue of its use of binary numbers that take up only as many bits as are necessary to hold the largest expected value. However, when many reports all with the same layout of individual observations, are available, a further compression is possible. The technique similar to that used in GRIB (the WMO code form for GRIdded Binary fields) in that all the like elements from the full set of observations are collected together, their minimum values subtracted out, and the residuals are then represented as binary integers each with a bit length selected to hold the largest residual.

The number of separate reports (called data sub-sets in the BUFR definition) is then placed in the data description part of the message and the data descriptors are not repeated. Often the data descriptor is of type 3, so there will be but one two-octet descriptor in the message used in conjunction with tens or hundreds of compressed observations.

One BUFR message is divided into logical sections without any special characters or bit configurations to separate them. The contents are:

Section 0, the indicator section contains the letters BUFR (character coded according to the International Alphabet No. 5), total length of the message (including 'BUFR') and the BUFR edition number.

Section 1, the identification section, contains among other things, an indication of the particular BUFR message type (surface, upper air, etc.) to enable a decoding program to select a general category for information storage prior to looking in detail at the descriptors. The section also contains identification of the originating center, the date, a flag indicating the presence or absence of section 2, and other useful information.

Section 2, the optional section, is completely undefined at present, except for indicating its own length. It is intended for local use such as some sort of data base key.

Section 3, the data descriptors section, prefaces the collection of descriptors with the number of data sub-sets (used in the compression algorithm) and a flag to indicate whether the data are indeed compressed. They do not need to be.

Section 4, the data section, contains only its own length and the actual data described in section 3

Section 5, the end section contains the numbers 7777 (character coded according to the International Alphabet No.5)

As well as the total length of the message in section 0, sections 1 to 4 contain, in their first three octets, a count of how long the section is. Thus it is no problem for a computer to find its way through a BUFR message using 'BUFR' and '7777' as checkpoints.

GRIB (GRId in Binary) was designed to provide a common, global binary representation form for processed data, enabling faster transmissions and reducing storage requirements by packing those data types which are already arranged in a regular grid format, in a highly compacted form.

The WMO Commission for Basic Systems ISS Expert Meeting on Exchange Formats defined the first version of the GRIB in 1984, and this was then used experimentally by a number of centres. Following these trials, some changes were made and the code was adopted in 1985 by CBS. At its ninth session, in 1988, CBS adopted amendments and extensions to generalise the representation of spherical harmonic components and enable polar stereographic representation to be included. At an Expert Meeting of the CBS Working Group on Data Management Sub-group on Data Representation (October 1990) further amendments to GRIB were considered and subsequently approved for use by the president of CBS. They include the provision of decimal scaling, representation of a matrix of values at each grid point and the representation of image data such as satellite pictures.

Each field encoded in GRIB consists of one meteorological parameter at one level in the atmosphere. As well as the data, sufficient information is included to define the product and describe the data representation used. As with BUFR the representation form is independent of any particular machine representation. All lengths are given in octets (8 bits). A GRIB coded product consists of 6 logical sections, two of which are optional.

Section 0, the indicator section contains the letters GRIB (character coded according to the International Alphabet No. 5), total length of the message (including 'GRIB') and the GRIB edition number.

Section 1, the product definition section identifies the centre originating the data and the model used in generating the data. The data itself is described: time, parameter, level etc. A flag field is also included to indicate the presence or absence of sections 2 and 3.

Section 2, the grid description section is optional, but it is recommended that it usually be included. It may be omitted only if the grid description is published in Volume B of WMO Publication No. 9, and the appropriate catalogue number of the grid in this publication is included in the Product Definition section. The contents of this block vary, depending on the way data in the Data section (section 4) is represented. For a regular latitude/longitude grid it contains the latitude and longitude of the origin and the extreme point, the number of points along a latitude and along a meridian, and optionally the direction increments. It also identifies the grid point scanning mode e.g. West to East, North to South.

Section 3, the bit map section, if used, can contain either a bit map or a reference to a pre-defined bit map provided by the originating centre. The bit map consists of contiguous bits, with a bit to data point correspondence, ordered as defined in the grid definition.

Section 4, the data section contains the packed data. A number of formats are possible, depending on whether the data is in grid point or spherical harmonics and whether simple or complex packing methods are used. However, the fundamental principle in packing the data remains the same - data is coded in the form of non-negative scaled differences from a reference value. The reference value (R) is stored in four octets as a floating point number. The high order bit is a sign bit (sb), O indicating positive, 1 negative. The next seven bits are the characteristic (C) and the low order 24 bits the mantissa (B).

Data values transmitted (P_j) are coded in the number of bits required to achieve the required accuracy.

To optimise accuracy with respect to packing density, it is necessary to choose a suitable scale factor, s, give a packing density of i bits per packed value (see 6.3.3 below).

Section 5, the end section contains the numbers 7777 (character coded according to the International Alphabet No. 5).

As well as the total length of the message in section 0, sections 1 to 4 contain, in their first three octets, a count of how long the section is. Thus it is no problem for a computer to find its way through a GRIB message using 'GRIB' and '7777' as checkpoints

Equation (1) above defines the representation used in GRIB for floating point reference values. It is necessary to transform the floating point notation used within the data processing computer in which GRIB is being encoded into this representation.

It is not likely that BUFR and GRIB will replace the current WMO character oriented codes in any wholesale manner in the short term. There are simply too many character oriented communications lines in use, in both the developing and developed communities, for change to come rapidly.

One possible scenario for the development of the WWW is for regional centers to take in individual observations from an assortment of observation sites, combine them, convert them to the BUFR format, and pass them on to national or international centers for world wide distribution. At the same time these regional centres would be able to use their computing infra-structure to decode and display gridded fields transmitted in GRIB code.

It is to be hoped that rather than having each centre develop its own code for the manipulation of BUFR and GRIB messages, one, or at most two centres take on the responsibility for the development and maintenance of such software.

One issue, raised earlier, is the possible necessity for some centers to ingest BUFR messages and then reformat them back into (current) WMO character code forms for local transmission on character lines, However, before this gets extensive, serious thought should be given to the purposes of such retransmissions. If they are undertaken to supply non-automated centers with "human-readable" information, then there may be more sense in dropping the use of the sometimes complex WMO character code forms and instead send the information out in a simple tabular form; alternatively, graphical products may be generated and transmitted. Eventually, the aim should be to eliminate the need for training in human decoding of the WMO code forms. Programming to generate tables, for transmission and display, is much simpler than generating the current WMO character codes. If the transmissions are to automated centers, then they should switch over to the binary representation forms as soon as possible. Of course, there will be an interim period when both binary and character data are flowing on the GTS, but every effort should be made to avoid converting binary data, particularly BUFR encoded messages, back into the character codes.

Code table number	Reserved for use in
120 to 199	WMO Region I
220 to 299	WMO Region II
320 to 399	WMO Region III
420 to 499	WMO Region IV
520 to 599	WMO Region V
620 to 699	WMO Region VI
720 to 799	Antarctic

SECTION	CONTENT
0	Indicator Section
1	Identification Section
2	Optional Section (local use)
3	Data Descriptors Section
4	Data Section
5	End Section

SECTION	CONTENTS
0	Indicator Section
1	Product Definition Section
2	Grid Description Section (optional but recommended)
3	Bit Map Section (optional)
4	Data Section
	End Section

ISO	LAYER
7	Application
6	Presentation
5	Session
4	Transport
3	Network
2	Data Link
1	Physical