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:
DDHHMMformat, omitting the month and the year. This makes the raw reports unsuitable for archival storage, record keeping, trend processing, etc.
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:
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.
The following attributes provide basic annotation information. These attributes may (and often must) be present in appropriate elements describing reports.
|Time Stamp||integer number|
|UTC time in seconds since the Epoch, |
|Time Interval||a string of a form |
|Specification of a point on the globe||a string of a form |
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 |
|Bounding box, which tells the latitudal and the longitudal spans of an area of the globe||a string of a form |
It is required that
|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 |
|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 |
<!ENTITY % TStamp-type "NMTOKEN"> <!ENTITY % TRange-type "CDATA"> <!ENTITY % TStamp "TStamp %TStamp-type; #REQUIRED"> <!ENTITY % TRange "TRange %TRange-type; #REQUIRED"> <!ENTITY % LatLon "LatLon CDATA #IMPLIED"> <!ENTITY % LatLons "LatLons NMTOKENS #REQUIRED"> <!ENTITY % BBox-REQD "BBox CDATA #REQUIRED"> <!ENTITY % BBox-OPT "BBox CDATA #IMPLIED"> <!ENTITY % BId "BId NMTOKEN #REQUIRED"> <!ENTITY % SName "SName CDATA #REQUIRED"> <!ENTITY % Elev "Elev NMTOKEN #IMPLIED">
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 tells a time interval within which an advisory, forecast, etc. is valid. This markup annotates the corresponding words of a raw report.
<!ELEMENT VALID (#PCDATA)>
|Valid time interval|
<!ATTLIST VALID %TRange; >
Access restrictions in OMF are intentionally minimalist and intended
as a rough guidance only. The fitness for use in MLS environments is
Access restrictions are specified by the following two attributes, to
be attached to each major OMF element (e.g.,
TAF, etc). If both attributes are absent, the
corresponding report/forecast is considered free of any
|Content classification and caveats||A sequence of tokens, the
first being |
The first token describes the overall classification (e.g.,
LimitTo="U NOFORN" LimitTo="C"The omitted
|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">
Defines a collection of weather observation reports. The collection is made of
BTSC elements, each defining one particular report.
<!ELEMENT Reports ( SYN | UAR | BTSC | PIREP | AIREP | AMDAR )* >
|Time Stamp of the moment this group of reports was created. Normally it's the time the request is fulfilled.|
<!ATTLIST Reports %TStamp;>
|Station's block id|
|Timestamp of the report|
|Tokens of the actual report, with |
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|
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
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 = |
|visibility <= 8050 meters (5 miles)||--->||visibility_symbol = |
|visibility > 8050 meters (5 miles) or "||--->||visibility_symbol = |
|visibility was not reported||--->||visibility_symbol = unknown|
|Quantifying the ceiling, based on reported cloud conditions:|
|ceiling <= 1000 (feet)||--->|| ceiling_symbol = |
|ceiling <= 3000 (feet)||--->|| ceiling_symbol = |
|ceiling > 3000 (feet) or "||--->|| ceiling_symbol = |
|ceiling is omitted||--->||ceiling_symbol = unknown|
Flight category is then, informally, the "smallest" of the two
visibility_symbol and the
ceiling_symbol. To be more precise:
|visibility_symbol is ||--->|| |
|visibility_symbol is ||--->|| |
|visibility_symbol is ||--->|| |
|(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.
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
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.
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.
Meteorological Station Information Lookup, a NWS site
Meteorological Station Information
Lookup, from the Metcast Database
Glossary of Weather Terms