Weather Observation Definition Format (OMF)

  1. Motivation
  2. Structure of an OMF document
    1. Basic attributes
    2. Basic elements
      1. VALID Element
    3. Access Restrictions
    4. Reports Element
      1. SYN: land or sea surface weather report in a METAR, SPECI, SYNOP, SHIP or BUOY code
      2. UAR Report
      3. Aircraft Reports (PIREP, AIREP, AMDAR)
      4. BTSC Report: bathythermal and salinity observations
  3. SIGMET advisories
  4. Terminal Aerodrome Forecasts (TAF)
  5. Plain-text WMO Messages
  6. Post-processing of OMF documents for JMV
    1. Computing of Flight Categories
  7. References (bibliography)
    • Total weather query: reconstruction and presentation of METAR, SPECI, SYNOP, and TAF reports using XSL stylesheets



Weather Observation Markup Format is an application of XML to describe a particular kind of documents: weather observation reports.

Weather observations are reported in a variety of formats: FM 15-X Ext. METAR, FM 16-X Ext. SPECI, FM 51-X Ext. TAF, synoptic code, etc. These reports constitute AWDS, NWS etc. feeds. Unfortunately, these formats are rather unsuitable for serving of observation information requested for a particular area of interest:

The intent of OMF therefore is annotation of weather reports. The reports should be distributed as they are without any mangling. On the other hand, we would like to mark them up with station information (location, name), decoded data, and with a few derived parameters. This document is to define the format of this markup.

OMF is an application of XML, and by its virtue, an application of SGML. SGML is used extensively within DoD for documenting of various types of information (military standards, procurement materials, service manuals). OMF brings weather observations into the same fold.

Thus, the design goals of OMF are:


Structure of an OMF document

The Observation Markup Format is an application of the Extensible Markup Language (XML). Thus its definition consists of the various XML elements defined in this section. See the references section for more information on XML.

The OMF contains the following elements:

The following sections define the major elements along with the minor elements that are relevant to them. In each section, XML DTD declarations are provided for precise definition of elements and attributes. The collection of XML DTD declarations found in this specification can be arbitrarily extended to add new elements and attributes for new enhancements.

Some of elements attributes are common. For compactness, they are defined in the following special section.

Basic Attributes

The following attributes provide basic annotation information. These attributes may (and often must) be present in appropriate elements describing reports.

 Time Stampinteger number
 UTC time in seconds since the Epoch, 00:00:00 Jan 1, 1970 UTC. This is the value returned by a POSIX function time(2). The value may be negative for time moments before the Epoch.
 Time Interval a string of a form "aaa, bbb"
 where aaa and bbb are integer numbers specifying the beginning and the end timestamps of the interval. The timestamps are in seconds since the Epoch, 00:00:00 Jan 1, 1970 UTC. These are the values returned by a POSIX function time(2).
 Specification of a point on the globe a string of a form "aaa.bbb, ccc.ddd"
 where aaa.bbb and ccc.ddd are signed floating point numbers telling the latitude resp. longitude of a point on the globe, in whole and fractional degrees.
The numbers are positive for Northern latitudes resp. Eastern longitudes, and negative otherwise.
The range of the numbers is [-90.0, 90.0] for latitudes, (-180.0, 180.0] for longitudes.
 Specification of a sequence of points on the globe a string of a form "lat1 lon1 lat2 lon2 latn lonn"
 where lat1, lon1, etc. are signed floating point numbers telling the latitude resp. longitude of a point on the globe, in whole and fractional degrees.
See a LatLon attribute above for more details.
 Bounding box, which tells the latitudal and the longitudal spans of an area of the globe a string of a form "lat-N, lon-W, lat-S, lon-E"
  Here lat-N is the latitude of the Northern-most point of the area, lat-S is the latitude of the Southern-most point, lon-W is the longitude of the Western-most point of the area, and lon-E is the Eastern-most longitude.

lats and lons are signed floating-point numbers, in degrees. See a LatLon attribute above for more details.

It is required that lat-N >= lat-S. The left-lon (lon-W) may however be greater than the right-lon (lon-E). For example, a range of longitudes [-170,170] specifies the entire world but Indonesia. On the other end, the range [170,-170] includes Indonesia only. By the same token, [-10,10] pertains to a 21-degree longitude strip along the Greenwich meridian, while [10,-10] specifies the whole globe but that strip.

 Identifier of the reporting station an alphanumeric string
 The secondary identifier and the full name of a weather observation station a string of the form "ccccc, name"
 where ccccc is an optional secondary identifier (e.g., a WMO identifier for a station reporting by the call letters, or vice versa), name is an arbitrary optional string describing the station
 Elevation relative to the sea level, in meters an integer, or omitted if unknown
 This attribute may specify a surface elevation of an observation station, or an upper-air elevation for an upper-air report. Elevation may be negative, e.g., station EHAM (Amsterdam/Schiphol) or KTRM (Thermal Airport, US).

<!ENTITY % TStamp-type "NMTOKEN">
<!ENTITY % TRange-type "CDATA">
<!ENTITY % TStamp "TStamp %TStamp-type; #REQUIRED">
<!ENTITY % TRange "TRange %TRange-type; #REQUIRED">


Basic Elements

Certain annotation information -- for example, valid time interval -- is rather common. The corresponding (minor) elements therefore occur frequently inside other elements to mark up and annotate these common pieces of information. For convenience, definitions of these minor elements are collected in the present section.

VALID Element

The VALID element tells a time interval within which an advisory, forecast, etc. is valid. This markup annotates the corresponding words of a raw report.


 Valid time interval



Access Restrictions

Access restrictions in OMF are intentionally minimalist and intended as a rough guidance only. The fitness for use in MLS environments is specifically disclaimed. Access restrictions are specified by the following two attributes, to be attached to each major OMF element (e.g., SYN, TAF, etc). If both attributes are absent, the corresponding report/forecast is considered free of any restrictions.

 Content classification and caveats A sequence of tokens, the first being U, C, etc.
  The first token describes the overall classification (e.g., C -- confidential). The other tokens are optional modifiers. Examples:
LimitTo="U NOFORN"
The omitted LimitTo attribute is equivalent to LimitTo="U". The list of modifiers is not specified in OMF; it is assumed to be agreed upon.
 Record of access restrictions and other handling instructions plain text
  This attribute describes access restriction authority and reasons, derived information, and downgrading instructions if any. The string is in free form and intended to be displayed to the user rather than processed mechanically. The string may contain either the full instructions or just the reference such as "see document 17".

<!ENTITY % AccessLimit "LimitTo    NMTOKENS #IMPLIED
                        LimitRecd  CDATA    #IMPLIED">

Reports Element

Defines a collection of weather observation reports. The collection is made of SYN, UAR, BTSC elements, each defining one particular report.



 Time Stamp of the moment this group of reports was created. Normally it's the time the request is fulfilled.

<!ATTLIST Reports %TStamp;>


Post-processing of OMF documents for JMV

JMV stores weather reports received for a specific area in a "database", which can be described as follows

CREATE TABLE Observations (
block_idINTEGER not null, Station's block id
latlonVARCHAR(16) not null, 
issue_timeDATETIME YEAR TO SECOND not null,Timestamp of the report
tokens,VARCHAR(255,61) not nullTokens of the actual report, with METAR or SPECI prepended
primary key (block_id)

This table is actually stored in a flat file (for example, MZZUPDT_.XXF file), one row per line, with fields delimited with a character "|". There is one extra character "|" at the end of the line, right after the last field and before the end-of-line character(s).

For example, an OMF document would be stored in the MZZUPDT_.XXF file as follows:

724915|KMRY, MONTEREY PENINSULA|36.58, -121.85|888965153|80500|INF|METAR KMRY 032245Z 29007KT 50SM SKC 15/03 A3003|
746716|KBWG, BOWLING GREEN|36.97, -86.42|888966299|12880|2400|SPECI KBWG 032304Z VRB05KT 8SM BKN024 OVC035 04/01 A2990 RMK AO2|
724604|KEHA, ELKHART (AWOS)|37.00, -101.9|888968939|||METAR KEHA 032348Z AUTO 08004KT 15/M10 RMK AO1 PK WND 06 000 T01501099|
84820|LEMG, MALAGA (CIV/MIL)|36.67, -4.48|888967859|4000|INF|METAR LEMG 2330Z 31006KT 4000 BR FEW008 08/07 Q1027 NOSIG|

When a new OMF document with updated reports for the same area of interest arrives, a text/x-omf helper, syn-proc, merges the new information with the one already contained in the local database, MZZUPDT_.XXF. Specifically, the expired observations (the ones that are past their valid time) are purged, and a new report of an observation station replaces the old one if existed. The helper thus reinforces a primary key constrain: each record in the database has a unique block_id.

Computing of Flight Categories

Horizontal visibility and the cloud ceiling can be used to compute flight categories. The algorithm outlined below was explained to me by LCDR Mike Neith.

A flight category is determined by visibility and cloud ceiling. First, we need to quantify these parameters: convert their numerical values into symbols, by simple thresholding:

Quantifying the reported prevailing visibility
visibility <= 4830 meters (3 miles)--->visibility_symbol = IFR
visibility <= 8050 meters (5 miles)--->visibility_symbol = MVFR
visibility > 8050 meters (5 miles) or "INF"--->visibility_symbol = VFR
visibility was not reported--->visibility_symbol = unknown
Quantifying the ceiling, based on reported cloud conditions:
ceiling <= 1000 (feet)---> ceiling_symbol = IFR
ceiling <= 3000 (feet)---> ceiling_symbol = MVFR
ceiling > 3000 (feet) or "INF"---> ceiling_symbol = VFR
ceiling is omitted---> ceiling_symbol = unknown

Flight category is then, informally, the "smallest" of the two symbols, the visibility_symbol and the ceiling_symbol. To be more precise:

FlightCategory is:
 visibility_symbol is IFR or ceiling_symbol IFR---> IFR
else if
 visibility_symbol is MVFR or ceiling_symbol MVFR---> MVFR
else if
 visibility_symbol is VFR or ceiling_symbol VFR---> VFR
 (that is, both symbols are unknown)---> unknown



The OMF Data Definition Document in XML format

Sample OMF Report

Retrieving of the latest land surface observation reports
The reports are presented in the OMF format described in this document.


Total weather query (combined TAF and land surface reports)


This page demonstrates XSL stylesheets and their ability to sort and group OMF elements, and reconstruct METAR, SPECI, SYNOP, and TAF reports into their original form -- as they came in WMO messages. Furthermore, the stylesheet makes use of decoded information to compute flight categories and color-code observation reports accordingly. With the help of OMF annotations, the stylesheet presents reconstructed TAF reports in the most informative way, indenting major and minor forecast periods. In addition the stylesheet emphasizes the current period (the one that has started but hasn't yet ended) with a red vertical bar.

The page and the corresponding JScript code are a lightweight Metcast client. It submits MBL requests to a Metcast server and handles single- and multi-part responses. The latter are "merged" by the script into a compound OMF document, which is then rewritten into HTML as instructed by a stylesheet.

MSIE5.0 is required to properly run the above page, as it relies on Microsoft.XMLHTTP and Microsoft.XMLDOM objects.

A similar script with a server-side XML-to-HTML translation:
This script only requires a Web browser. The output is designed to be viewed on a handheld device with a small screen.

Other Databases of Meteorological Information

Many of these databases have limited coverage of the world outside of the U.S.A. These search engines require the user to explicitly name a city of interest, a county or a state; they do not appear to allow retrieval of data for an arbitrary rectangular area on the globe.

XML Weather Station Demo
An alternative (and rather primitive) way of describing weather conditions of particular cities. Still, some ideas are relevant and illustrate the points of the current proposal.

The Weather Visualizer

Purdue's WXP - The Weather Processor
A suite of routines for analyzing and displaying meteorological data and satellite images. The software handles standard National Weather Service data captured in near- real time.

WFO-Advanced Overview. NOAA Forecast Systems Laboratory, Modernization and Systems Development Divisions
A system that is similar to Metcast's LLT decoders and database. It was written by NOAA and many a contractor over several years. I developed the Metcast system alone within one year.

Weather Codes and Reference Manuals

Meteorological Station Information Lookup, a NWS site

Meteorological Station Information Lookup, from the Metcast Database

Glossary of Weather Terms



$Id: OMF.html,v 2.6 2007/02/21 00:59:07 oleg Exp oleg $