Reports Element
SYN: land or sea surface weather report in a METAR, SPECI, SYNOP, SHIP or BUOY code
UAR Report
PIREP, AIREP, AMDAR)
BTSC Report: bathythermal and salinity observations
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:
HHMM or DDHHMM format, 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:
METAR, SPECI, SYNOP, SHIP or BUOY codeThe 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.
TStamp |
||
|---|---|---|
| Time Stamp | integer 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.
| ||
TRange |
||
| 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).
| ||
LatLon |
||
| 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. | ||
LatLons |
||
| 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.
| ||
BBox |
||
| 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.
It is required that | ||
BId |
||
| Identifier of the reporting station | an alphanumeric string | |
SName |
||
| 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
| ||
Elev |
||
| 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).
| ||
| XML DTD | |
|---|---|
<!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 ElementThe VALID element tells a time interval within which an advisory, forecast, etc. is valid. This markup annotates the corresponding words of a raw report.
| XML DTD | |
|---|---|
<!ELEMENT VALID (#PCDATA)> |
TRange |
||
|---|---|---|
| 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
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.
LimitTo |
||
|---|---|---|
| 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" LimitTo="C"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.
| ||
LimitRecd |
||
| 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". | ||
| XML DTD | |
|---|---|
<!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.
| XML DTD | |
|---|---|
<!ELEMENT Reports ( SYN | UAR | BTSC | PIREP | AIREP | AMDAR )* > |
TStamp |
||
|---|---|---|
| Time Stamp of the moment this group of reports was created. Normally it's the time the request is fulfilled. | ||
<!ATTLIST Reports %TStamp;> |
CREATE TABLE Observations (
| ||
block_id | INTEGER not null,
| Station's block id |
station_name | VARCHAR(40), | |
latlon | VARCHAR(16) not null, | |
issue_time | DATETIME YEAR TO SECOND not null, | Timestamp of the report |
visibility | VARCHAR(5), | |
ceiling | VARCHAR(5), | |
tokens, | VARCHAR(255,61) not null | Tokens 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|
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.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: | |||
if
| |||
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
| |
else
| |||
| (that is, both symbols are unknown) | ---> | unknown | |
OMF DTD
The OMF Data Definition Document in XML format
Retrieving of the latest land surface observation reports
http://www.metnet.navy.mil/cgi-bin/oleg/get-obs
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 Microsoft.XMLHTTP and Microsoft.XMLDOM objects.
A similar script with a server-side XML-to-HTML translation:
http://www.metnet.navy.mil/cgi-bin/oleg/get-wx-light
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
http://covis.atmos.uiuc.edu/covis/visualizer/covisualizer.text.html
Purdue's WXP - The Weather Processor
http://wxp.eas.purdue.edu/wxp/
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
http://www-sdd.fsl.noaa.gov/~fxa/overview/WFO-A-Overview.book.html
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
http://www.nws.noaa.gov/tg/siteloc.shtml
Meteorological Station Information
Lookup, from the Metcast Database
http://www.metnet.navy.mil/cgi-bin/oleg/search-mslib
Glossary of Weather Terms
http://www.weather.com/glossary/