IWXXM-2-Tutorial-metar-EDDF-2013-03-12T0550Z
Tutorial
- METAR EDDF for 2013-03-12T0550Z
This METAR is intended as an example and does not represent
actual observed conditions.
The full XML for this example can be found here.
XML Namespaces
The following namespaces are used either directly or indirectly in this
example:
|
Description |
XML Namespace |
Default namespace prefix |
|
XML Schema |
http://www.w3.org/2001/XMLSchema |
xsd |
|
XML Linking Language |
http://www.w3.org/1999/xlink |
xlink |
|
OGC GML 3.2.1 |
http://www.opengis.net/gml/3.2 |
gml |
|
ISO/TS 19139:2007 metadata XML schema implementation |
http://www.isotc211.org/2005/gmd |
gmd |
|
OGC OMXML Observations and Measurements |
http://www.opengis.net/om/2.0 |
om |
|
OGC OMXML Sampling Features |
http://www.opengis.net/sampling/2.0 |
sf |
|
OGC OMXML Spatial Sampling Features |
http://www.opengis.net/samplingSpatial/2.0 |
sams |
|
WMO Observable Property Model(1.2) |
http://def.wmo.int/opm/2013 |
opm |
|
WMO METCE (1.2) |
http://def.wmo.int/metce/2013 |
metce |
|
ICAO Meteorological Information Exchange Model (2.1) |
http://icao.int/iwxxm/2.1 |
iwxxm |
Note that the XML Namespace is distinct from the schema locations. For
reference, these are provided here.
Overview: the METAR
report
The XML-encoded METAR has a root element <iwxxm:METAR> within which the XML Namespace information
is declared.
The <iwxxm:METAR>
element encodes a METAR report. status
and automatedStation are included as XML
attributes. In this example, the METAR report contains an <iwxxm:observation> element and
one <iwxxm:trendForecast>. A METAR report may
include up to three trend forecasts.
The code fragment below shows the XML Namespace declarations plus the basic
structure of this METAR report containing a single observation and one
trend forecasts.
Namespace
declarations, basic structure
1 . <?xml version="1.0" encoding="UTF-8"?>
2 . <iwxxm:METAR xmlns:iwxxm="http://icao.int/iwxxm/2.1"
3 . xmlns:xlink="http://www.w3.org/1999/xlink"
4 . xmlns:gml="http://www.opengis.net/gml/3.2"
5 . xmlns:om="http://www.opengis.net/om/2.0"
6 . xmlns:metce="http://def.wmo.int/metce/2013"
7 . xmlns:aixm="http://www.aixm.aero/schema/5.1.1"
8 . xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"
9 . xmlns:sam="http://www.opengis.net/sampling/2.0"
10 . xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
11 . xsi:schemaLocation="http://icao.int/iwxxm/2.1 http://schemas.wmo.int/iwxxm/2.1/iwxxm.xsd
12 . http://def.wmo.int/metce/2013 http://schemas.wmo.int/metce/1.2/metce.xsd"
13 . gml:id="metar-EDDF-20130312T055000Z" status="NORMAL" automatedStation="false">
14 . <iwxxm:observation>...</iwxxm:observation>
15 . <iwxxm:trendForecast>...</iwxxm:trendForecast>
16 . </iwxxm:METAR>
Note that in line 13 of the code fragment the XML attribute gml:id is provided. All instances of this attribute
within a given document must be unique. Furthermore, we
recommend that the gml:id
for the report itself is globally unique, comprising of
{report-type}-{aerodrome-identifier}-{issue-time}. The issue time should be
provided in ISO 8601 format.
Observation
structure
WMO
METCE and ICAO IWXXM are built on the foundation provided by ISO
19156:2011 "Geographic information — Observations and measurements".
As the originator of this ISO standard, the Open Geospatial Consortium also publish information regarding Observations and Measurement: Topic 20:
Observations and Measurements.
More information regarding the design decisions can be found in the model
documentation.
Given the reliance on ISO 19156:2011, the main part of the METAR (e.g. the <iwxxm:observation> element) is
provided using an instance of <om:OM_Observation>.
The OM_Observation class provides a framework to
describe the event of an observation or measurement; estimation of the
value (the result) of a property (the observed
property) of some entity (the feature of interest)
using a specified procedure at a given time. OM_Observation also provides the mechanism to capture
quality information about the result and arbitrary parameters
concerning the observation event.
OM_Observation allows one to describe arbitrarily
complex procedures, from the measurement of air temperature using a particular
type of thermometer though to intensive numerical simulations. The process may
even facilitate the estimation of values of the properties at some point in the
future! To ensure clarity, OM_Observation provides a
time at which the procedure completed (the result time) and the
time or time-period when the result is relevant (the phenomenon time).
For example, a forecast might have a result time of 12:00Z and a phenomenon
time of 18:00Z at T+6. Similarly, if one is dealing with physical specimens
such as ice-cores, the phenomenon time is the time at which the specimen is
collected, whilst the result time may be days, months or even years later when
the specimen is tested in the laboratory.
The <iwxxm:trendForecast>
element is also provided using an instance of <om:OM_Observation>.
In the conceptual model, the observation types are specified with
particular semantics. For example, the METAR observation and trend forecast are
characterised by the classes MeteorologicalAerodromeObservation
and MeteorologicalAerodromeTrendForecast
respectively, both of which are sub-classes of OM_Observation.
In the XML document, the category, or class, of observation is specified using
the element <om:type>.
This provides a reference to a definition of the particular sub-class of OM_Observation. These types are managed in a controlled
register published by WMO at http://codes.wmo.int;
e.g.
- http://codes.wmo.int/49-2/observation-type/IWXXM/2.1/MeteorologicalAerodromeObservation
- http://codes.wmo.int/49-2/observation-type/IWXXM/2.1/MeteorologicalAerodromeTrendForecast
These definitions are based on the OpenGIS
definitions; for example - OM_ComplexObservation
(from ISO 19156:2011):
The code fragment below show the basic structure of the <om:OM_Observation> element plus the <om:type> declaration.
Note that xlink
is used to refer to the class definition. The attribute xlink:href provides the reference, whilst xlink:title provides an informative human-readable
label for the target resource. It is best practice to always include an xlink title. However, as shown in this case, where the URI
provides a human readable identifier it is permissible to omit the xlink title attribute.
Basic
structure of om:OM_Observation
1 . ...
2 . <iwxxm:observation>
3 . <om:OM_Observation gml:id="obs-EDDF-20130312T055000Z">
4 . <om:type xlink:href="http://codes.wmo.int/49-2/observation-type/IWXXM/2.1/MeteorologicalAerodromeObservation"/>
5 . <om:phenomenonTime>...</om:phenomenonTime>
6 . <om:resultTime>...</om:resultTime>
7 . <om:procedure>...</om:procedure>
8 . <om:observedProperty>...</om:observedProperty>
9 . <om:featureOfInterest>...</om:featureOfInterest>
10 . <om:result>...</om:result>
11 . </om:OM_Observation>
12 . </iwxxm:observation>
13 . ...
Note that, like other sub-classes of OM_Observation, MeteorologicalAerodromeObservation asserts
additional constraints over the vanilla OM_Observation.
These are clearly specified in the conceptual model (e.g. the UML). In the case
of MeteorologicalAerodromeObservation is constrained
such that:
- procedure shall be an instance of Process (from METCE);
- featureOfInterest shall be an instance of
SF_SpatialSamplingPoint (from ISO 19156:2011
Spatial Sampling Features); and - result shall be an instance of
MeteorologicalAerodromeObservationRecord (from
IWXXM).
In particular, the constraint on the result ensures that the
information that is included in this instance of <om:OM_Observation> matches the regulatory
requirements from ICAO Annex 3 / WMO No. 49 Volume 2.
These sections of the observation are described in more detail below.
Observation time
values
This METAR is for 05:50 UTC on 12th March 2013. In ISO 8601
format, this is defined as: 2013-03-12T05:50:00Z.
As this is a METAR observation, the observation time (e.g. phenomenon
time) and the issue time (e.g. result time)
both time values are identical. Given this, rather than repeating the <gml:TimeInstant> element, the
<om:resultTime> uses xlink
to refer to the definition above; a URI beginning with "#" is a local
reference within the file.
Observation
time values
1 . ...
2 . <om:phenomenonTime>
3 . <gml:TimeInstant gml:id="ti-20130312T055000Z">
4 . <gml:timePosition>2013-03-12T05:50:00Z</gml:timePosition>
5 . </gml:TimeInstant>
6 . </om:phenomenonTime>
7 . <om:resultTime xlink:href="#ti-20130312T055000Z"/>
8 . ...
Observation
procedure
The MeteorologicalAerodromeObservation
class is constrained such that <om:procedure>
must refer to an instance of Process class (from METCE). This constraint is not
enforced using the XML Schema, but using rule-based validation in the form of schematron (ISO/IEC 19757-3:2006 "Information
technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based
validation - Schematron" (zip
file)).
In its simplest form, METCE Process requires no content. However, an
"empty" process definition is not very helpful!
It is recommended that one provides reference to human-readable on-line
documentation that describes the procedure (e.g. using the element <metce:documentationRef>
enabling the use of xlink:href to provide a hyperlink
reference to the documentation). An acceptable alternative is to cite a well known document (e.g. using the element <gml:description>).
In the case of METAR, as a regulated product, one can simply reference the
appropriate clause(es) from
ICAO Annex 3 (WMO No. 49) technical regulations.
Also note in line 3 of the code fragment the inclusion of a mandatory gml:id attribute which provides a
unique identifier within the scope of the XML document.
Observation
procedure
1 . ...
2 . <om:procedure>
3 . <metce:Process gml:id="p-49-2-metar">
4 . <gml:description>WMO No. 49 Volume 2 Meteorological Service for International Air Navigation
5 . APPENDIX 3 TECHNICAL SPECIFICATIONS RELATED TO METEOROLOGICAL OBSERVATIONS
6 . AND REPORTS
7 . </gml:description>
8 . </metce:Process>
9 . </om:procedure>
10 . ...{img src=/pages/prog/www/WIS/wiswiki/pics/icons/wiki_plugin_edit.png height=16 width=16
alt=Edit}
Observed property
Typically, the observed property is used to support
search and discovery use-cases (e.g. "find me all the observations using
property air temperature"). The Open Geospatial Consortium Sensor
Observation Service (OGC 12-006
Sensor Observation Service Interface Standard 2.0) uses the observed
property as a primary mechanism to retrieve observation instances.
However, the OM_Observation model allows only a
single instance of <om:observedProperty>.
In the case of the METAR observation, a total of 26 individual physical
properties may be measured; everything from air temperature to sea-surface
state.
As the observation instance is able to refer to only a single definition, the CompositeObservableProperty (from the ObservablePropertyModel)
is used to aggregate a set of physical properties into a single composite.
The observed property definition must be referenced remotely (e.g. via
xlink); it cannot be specified in-line within the
document.
For regulated products such as METAR, WMO publishes a set of CompositeObservableProperty instances within the WMO Codes
Registry (http://codes.wmo.int/49-2/observable-property)
that may be referenced from data products.
Thus the observed property reference relating to the aggregated set of physical
properties that may be observed in a METAR may be found here: http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation
Observed
property
1 . ...
2 . <om:observedProperty
3 . xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation"
4 . xlink:title="Observed properties for Meteorological
5 . Aerodrome Observation Reports (METAR and SPECI)"/>
6 . ...
Feature of interest
The feature
of interest is the entity about which the observation is made.
Meteorological observations or forecasts clearly relate to the real world. For
example, we may observe the weather for Exeter or provide a weather forecast
for the ‘North Atlantic European’ area. However, there is a level of
abstraction to resolve:
- An observation of the weather for the city of Exeter
happens at some representative location within the city or some
representative locale nearby - The forecast domain for ‘North Atlantic European’ is
specified so that it covers the areas for which a forecast is required
In each case, the ‘observation’ event relates to some sampling regime that is a
proxy for the real entity of interest (e.g. the site of the weather station, or
the extent of the forecast domain). The observation or forecast is not directly
related to real-world entities.
ISO 19156 ‘Observations and measurements’ provides a conceptual model for
describing this layer of indirection: Sampling Features.
A sampling feature is related to the real world via the
property <sam:sampledFeature>.
Further specialisations of Sampling Feature are
provided based on spatial topology (SF_SpatialSamplingFeature
and sub-types thereof).
In all cases identified thus far in meteorology, it appears useful to describe
an observation, measurement or forecast with respect to the sampling regime
(e.g. the Sampling Feature) and indirectly refer to the real-world entity for
which the Sampling Feature is a proxy.
The code fragment below shows the structure of the sampling feature:
Feature
of interest
1 . ...
2 . <om:featureOfInterest>
3 . <sams:SF_SpatialSamplingFeature gml:id="sp-EDDF">
4 . <sam:type xlink:href="http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0/SF_SamplingPoint"/>
5 . <sam:sampledFeature>...</sam:sampledFeature>
6 . <sams:shape>...</sam:shape>
7 . </sams:SF_SpatialSamplingFeature>
8 . </om:featureOfInterest>
9 . ...
As required by the MeteorologicalAerodromeObservation
class, the spatial sampling feature used here is an instance
of SF_SamplingPoint; the METAR observation is
considered to occur at some fixed point in space.
Similarly to the XML implementation of sub-classes of OM_Observation,
only the generic SF_SpatialSamplingFeature is
implemented as an XML element. The <sam:type>
element is used to define the sub-class of spatial sampling feature (line 4).
IWXXM relies on rule-based validation to ensure that the correct type of
spatial sampling feature is used in this instance.
The element <sam:sampledFeature>
in line 5 relates the abstract sampling feature to the the
real-world entity that the observation is intended to describe.
A spatial sampling point must always include some geometric
information about the sampling regime it characterises.
This is provided by the <sams:shape>
element (line 6).
The <sam:sampledFeature>
is further elaborated in the code-fragment below:
Spatial
sampling feature
1 . ...
2 . <sam:sampledFeature>
3 . <aixm:AirportHeliport gml:id="aerodrome-EDDF">
4 . <aixm:timeSlice>
5 . <aixm:AirportHeliportTimeSlice gml:id="aerodrome-EDDF-ts">
6 . <gml:validTime/>
7 . <aixm:interpretation>SNAPSHOT</aixm:interpretation>
8 . <aixm:designator>EDDF</aixm:designator>
9 . <aixm:name>FRANKFURT AM MAIN INTERNATIONAL</aixm:name>
10 . <aixm:locationIndicatorICAO>EDDF</aixm:locationIndicatorICAO>
11 . </aixm:AirportHeliportTimeSlice>
12 . </aixm:timeSlice>
13 . </aixm:AirportHeliport>
14 . </sam:sampledFeature>
15 . ...{img src=/pages/prog/www/WIS/wiswiki/pics/icons/wiki_plugin_edit.png
height=16 width=16 alt=Edit}
In this case, we can easily determine that the intended subject of the
observation is FRANKFURT AM MAIN INTERNATIONAL Airport
in Germany. The information provided here conforms to the Aerodrome
data model defined in the Aeronautical Information eXchange
Model (AIXM). This is intended to align
with the definition of Aerodrome within the broader ICAO Aeronautical
Information Reference Model (AIRM); albeit only a subset of the information
required for meteorological products is required.
The gml:ids shown here are
fictitious. A core feature enabling
consistency and alignment within the AIRM, is the use
of UUIDs (RFC 4122) for
identifying and referencing information about aeronautical features such as
Aerodromes. The use of UUIDs is adopted from Aeronautical Information eXchange Model (AIXM) 5, conjointly developed by EuroControl and US FAA. A managed set of information
describing an aeronautical feature is allocated a UUID by the data publisher.
The UUID is an opaque identifier and may be automatically generated (e.g. using
an online UUID-generator
or other mechanism). Once assigned by a data publisher, the UUID may be used as
a unique reference to the given set of information, thus enabling distributed
systems to assert that they are, indeed, using consistent information.
The information provided about an Aerodrome includes:
- (line 8) The coded designator for the Aerodrome or
Heliport (e.g. <saf:designator>) - this
may or may not be a 4-letter ICAO location indicator - (line 9) The name of the Aerodrome (e.g. <saf:name>) - this must be provided in BLOCK
CAPITALS - (line 10) The 4-letter ICAO location indicator for the
Aerodrome or Heliport, as listed in ICAO Doc 7910
Each spatial sampling feature must refer to a geometry (e.g.
<sams:shape>. In the
case of a sampling point the geometry is constrained to be of
type <gml:Point>. The
sampling point geometry represents the location of the observation (e.g. the
location that the observation is pertinent to). Whilst it is commonplace for
METAR/SPECI and TAF to use the Aerodrome Reference Point for this purpose, in
some cases, the sampling point may differ from the Aerodrome Reference Point.
The code fragment below shows the GML definition of the observation location:
Observation
location
1 . ...
2 . <sams:shape>
3 . <gml:Point gml:id="obs-point-EDDF"
4 . uomLabels="deg deg m"
5 . axisLabels="Lat Lon Altitude"
6 . srsDimension="3"
7 . srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
8 . <gml:pos>50.0464 8.5986 112</gml:pos>
9 . </gml:Point>
10 . </sams:shape>
11 . ...
Observation result
The observation
result is the main part of this METAR; it provides the data
values for the observed properties.
As required by the MeteorologicalAerodromeObservation
class, the result is constrained to be an instance of MeteorologicalAerodromeObservationRecord.
MeteorologicalAerodromeObservationRecord has been
designed with the explicit intention to allow provision of the information
required to meet ICAO Annex 3 / WMO No. 49 Volume 2 regulation.
As with the sampling point, IWXXM relies on rule-based validation (e.g. schematron) to validate this constraint; XML Schema will not
enforce this constraint.
However, <iwxxm:MeteorologicalAerodromeObservationRecord>
element is specified in XML Schema. As a result, typical XML authoring
tools such as oXygenXML
will be able to provide auto-completion and validation to help developers edit
METAR instances.
For reference, we recommend reviewing the IWXXM UML model to determine the
information that must or may be included in a MeteorologicalAerodromeObservationRecord
instance.
The example METAR provided here includes only a sub-set of the properties that
might be reported in a METAR.
The code fragment below provides the XML-encoding of the result
for this example:
Observation
result
1 . ...
2 . <om:result>
3 . <iwxxm:MeteorologicalAerodromeObservationRecord cloudAndVisibilityOK="false"
4 . gml:id="observation-record-EDDF-20130312T055000Z">
5 . <iwxxm:airTemperature uom="Cel">-4</iwxxm:airTemperature>
6 . <iwxxm:dewpointTemperature uom="Cel">-4</iwxxm:dewpointTemperature>
7 . <iwxxm:qnh uom="hPa">1000</iwxxm:qnh>
8 . <iwxxm:surfaceWind>
9 . <iwxxm:AerodromeSurfaceWind variableDirection="false">
10 . <iwxxm:meanWindDirection uom="deg">30</iwxxm:meanWindDirection>
11 . <iwxxm:meanWindSpeed uom="kn">15</iwxxm:meanWindSpeed>
12 . </iwxxm:AerodromeSurfaceWind>
13 . </iwxxm:surfaceWind>
14 . <iwxxm:visibility>
15 . <iwxxm:AerodromeHorizontalVisibility>
16 . <iwxxm:prevailingVisibility uom="m">1400</iwxxm:prevailingVisibility>
17 . </iwxxm:AerodromeHorizontalVisibility>
18 . </iwxxm:visibility>
19 . <iwxxm:rvr>
20 . <iwxxm:AerodromeRunwayVisualRange pastTendency="NO_CHANGE">
21 . <iwxxm:runway xlink:href="uuid.eddf-07-1-sf" />
22 . <iwxxm:meanRVR uom="m">2000</iwxxm:meanRVR>
23 . </iwxxm:AerodromeRunwayVisualRange>
24 . </iwxxm:rvr>
25 . <iwxxm:rvr>
26 . ...
27 . </iwxxm:rvr>
28 . <iwxxm:rvr>
29 . ...
30 . </iwxxm:rvr>
31 . <iwxxm:presentWeather
32 . xlink:href="http://codes.wmo.int/306/4678/SN"
33 . xlink:title="Snow"/>
34 . <iwxxm:presentWeather
35 . xlink:href="http://codes.wmo.int/306/4678/DRSN"
36 . xlink:title="low drifting Snow"/>
37 . <iwxxm:presentWeather
38 . xlink:href="http://codes.wmo.int/306/4678/BR"
39 . xlink:title="Mist"/>
40 . <iwxxm:cloud>
41 . <iwxxm:AerodromeObservedClouds amountAndHeightUnobservableByAutoSystem="true" />
42 . </iwxxm:cloud>
43 . <iwxxm:runwayState>
44 . <iwxxm:AerodromeRunwayState>
45 . <iwxxm:runway>
46 . <saf:RunwayDirection gml:id="uuid.eddf-07-r-sf">
47 . <gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-1-r-sf</gml:identifier>
48 . <saf:designator>07R</saf:designator>
49 . <saf:trueBearing uom="deg">70</saf:trueBearing>
50 . <saf:elevationTDZ uom="m">113</saf:elevationTDZ>
51 . <saf:usedRunway>
52 . <saf:Runway gml:id="uuid.eddf-07-1-sf">
53 . <gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-1-sf</gml:identifier>
54 . <saf:designator>07R/25L</saf:designator>
55 . <saf:associatedAirportHeliport xlink:href="#uuid.eddf-sf"/>
56 . </saf:Runway>
57 . </saf:usedRunway>
58 . </saf:RunwayDirection>
59 . </iwxxm:runway>
60 . <iwxxm:depositType
61 . xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1"
62 . xlink:title="Damp" />
63 . <iwxxm:contamination xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-087/1"
64 . xlink:title="Less than 10% of runway covered" />
65 . <iwxxm:depthOfDeposit uom="mm">0</iwxxm:depthOfDeposit>
66 . <iwxxm:estimatedSurfaceFriction uom="unity">0.9</iwxxm:estimatedSurfaceFriction>
67 . </iwxxm:AerodromeRunwayState>
68 . </iwxxm:runwayState>
69 . <iwxxm:runwayState>
70 . ...
71 . </iwxxm:runwayState>
72 . <iwxxm:runwayState>
73 . ...
74 . </iwxxm:runwayState>
75 . </iwxxm:MeteorologicalAerodromeObservationRecord>
76 . </om:result>
77 . ...
Looking in detail at the result we see:
Line 3 (CAVOK)
CAVOK
...
cloudAndVisibilityOK="false"
...
- CAVOK (e.g. attribute cloudAndVisibilityOK)
is false
Line 5 (Air
temperature)
Air
temperature
...
<iwxxm:airTemperature uom="Cel">-4</iwxxm:airTemperature>
...
- The value is -4 Celsius
- In accordance with the GML specification, the unit of
measure (e.g. attribute uom)
shall be defined either using the symbol from the Unified Code for the Units of Measure
(UCUM) or anyURI. For brevity, use of UCUM
symbols is preferred.
<iwxxm:airTemperature>
definition
It is worth understanding a little more about the definition of the <iwxxm:airTemperature> element.
Within the UML model, the property airTemperature
is annotated with tagged value "quantity" which refers to the
authoritative semantic definition of "air temperature" as specified
by WMO: http://codes.wmo.int/common/c-15/me/airTemperature
Degree Celsius
definition
A definition of "Degree Celsius" is provided by the Unified Code for the Units of Measure (UCUM).
However, WMO also publishes a list of the permitted units of measure: WMO No.
306 Vol 2 Common code-table C-6. This is published online at http://codes.wmo.int/common/c-6.
In the interest of reusing existing definitions, the WMO Codes register cites
the definition from QUDT (Quantities, Units, Dimensions and Data Types;
maintained within the NASA AMES Research Center): http://qudt.org/vocab/unit#DegreeCelsius.
QUDT provides a machine-readable definition of "Degree Celsius" in
RDF.
Furthermore, the WMO Codes Registry provides supplemental information about the
"Degree Celsius", including a description, the appropriate UCUM
symbol, the WMO abbreviations from Common code-table C-6 (e.g. IA5, IA2) and
the offset and multiplier required to convert values to other temperature
units.
Lines 6-7
(Dew-point temperature and QNH)
Dew-point
temperature, QNH
...
<iwxxm:dewpointTemperature uom="Cel">-4</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="hPa">1000</iwxxm:qnh>
...
- The dew-point temperature and QNH values are provided along
with their units of Celsius (Cel) and hecto-pascals (hPa).
Lines 8-13 (Surface
wind)
Wind
...
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="deg">30</iwxxm:meanWindDirection>
<iwxxm:meanWindSpeed uom="kn">15</iwxxm:meanWindSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
...
- The wind direction is not variable
(attribute variableDirection is
false) - The mean wind direction is specified as 30 degrees
(measured from true-north) - The mean wind speed is specified as 15 knots
Lines 14-18
(horizontal visibility)
Horizontal
visibility
...
<iwxxm:visibility>
<iwxxm:AerodromeHorizontalVisibility>
<iwxxm:prevailingVisibility uom="m">1400</iwxxm:prevailingVisibility>
</iwxxm:AerodromeHorizontalVisibility>
</iwxxm:visibility>
...
- The visibility is specified as prevailing visibility of
1400 meters
Lines 19-30 (RVR)
RVR
...
<iwxxm:rvr>
<iwxxm:AerodromeRunwayVisualRange pastTendency="NO_CHANGE">
<iwxxm:runway xlink:href="#uuid.eddf-07-1-sf" />
<iwxxm:meanRVR uom="m">2000</iwxxm:meanRVR>
</iwxxm:AerodromeRunwayVisualRange>
</iwxxm:rvr>
<iwxxm:rvr>
<iwxxm:AerodromeRunwayVisualRange pastTendency="NO_CHANGE">
<iwxxm:runway xlink:href="#uuid.eddf-07-2-sf" />
<iwxxm:meanRVR uom="m">2000</iwxxm:meanRVR>
</iwxxm:AerodromeRunwayVisualRange>
</iwxxm:rvr>
<iwxxm:rvr>
<iwxxm:AerodromeRunwayVisualRange pastTendency="UPWARD">
<iwxxm:runway xlink:href="#uuid.eddf-07-3-sf" />
<iwxxm:meanRVR uom="m">1900</iwxxm:meanRVR>
</iwxxm:AerodromeRunwayVisualRange>
</iwxxm:rvr>
...
- RVR is reported for 3 runways on the airport. The runways
are referred by a local reference via xlink. - in this example, past
tendency of the RVR is NO_CHANGE or UPWARD. Another possible value is
DOWNWARD. - the mean RVR is specified
as 2000 meter for the first two runways, and 1900 meters for the third.
Lines 31-39
(Present weather)
Present
weather
...
<iwxxm:presentWeather
xlink:href="http://codes.wmo.int/306/4678/SN"
xlink:title="Snow"/>
<iwxxm:presentWeather
xlink:href="http://codes.wmo.int/306/4678/DRSN"
xlink:title="low drifting Snow"/>
<iwxxm:presentWeather
xlink:href="http://codes.wmo.int/306/4678/BR"
xlink:title="Mist"/>
...
- Present weather is reported in three items
- First item is is
"Moderate Snow" (SN). - Second item is "low drifting Snow" (DRSN).
- Third item is "Mist" (BR).
- <iwxxm:presentWeather>
has type AerodromePresentWeather (from IWXXM
Package METAR/SPECI); <vocabulary> for this code-list class is
specified as <http://codes.wmo.int/49-2/AerodromePresentWeather>. - <iwxxm:recentWeather>
has type AerodromeRecentWeather (from IWXXM
Package METAR/SPECI); <vocabulary> for this code-list class is
specified as <http://data.wmo.int/def/49-2/AerodromeRecentWeather>. - The <vocabulary> refers to a register within the
WMO Codes Register that provides the set of permissible terms that may be
used for this element. - The members of AerodromePresentWeather
and AerodromeRecentWeather registers are
compiled from a subset of terms from WMO No. 306 Vol I.1 Code-table 4678
"Significant Weather" - as specified by the appropriate
technical regulation in ICAO Annex 3 (WMO No. 49 Vol 2). Terms from
Code-table 4678 comprise one or more of the elements from the 5 columns of
Code-table 4678: 'intensity or proximity', 'descriptor', 'precipitation',
'obscuration' and 'other'. The enumerated set of
meteorologically valid options are published within the WMO Codes
Registry at http://codes.wmo.int/306/4678. - The WMO Codes Registry provides a ?validate
operation to determine weather a resource is a
member of a given register; e.g.- HTTP POST:
http://codes.wmo.int/49-2/AerodromePresentWeather?validate=http://codes.wmo.int/306/4678/SN
- HTTP POST:
- In due course more terms will be added along with
additional descriptive information.
Lines 40-42
(Clouds)
Cloud
...
<iwxxm:cloud>
<iwxxm:AerodromeObservedClouds amountAndHeightUnobservableByAutoSystem="true" />
</iwxxm:cloud>
...
Amount and height of clouds is not observable (eg.
the attribute amountAndHeightUnobservableByAutoSystem
is set "true").
Lines 43-74 (Runway
state)
Runway
state
...
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:runway>
<saf:RunwayDirection gml:id="uuid.eddf-07-c-sf">
<gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-c-sf</gml:identifier>
<saf:designator>07C</saf:designator>
<saf:trueBearing uom="deg">70</saf:trueBearing>
<saf:elevationTDZ uom="m">113</saf:elevationTDZ>
<saf:usedRunway>
<saf:Runway gml:id="uuid.eddf-07-2-sf">
<gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-2-sf</gml:identifier>
<saf:designator>07C/25C</saf:designator>
<saf:associatedAirportHeliport xlink:href="#uuid.eddf-sf"/>
</saf:Runway>
</saf:usedRunway>
</saf:RunwayDirection>
</iwxxm:runway>
<iwxxm:depositType
xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1"
xlink:title="Damp" />
<iwxxm:contamination xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-087/5"
xlink:title="25% to 50% of runway covered" />
<iwxxm:depthOfDeposit uom="mm">0</iwxxm:depthOfDeposit>
<iwxxm:estimatedSurfaceFriction uom="unity">0.9</iwxxm:estimatedSurfaceFriction>
</iwxxm:AerodromeRunwayState>
</iwxxm:runwayState>
...
- <iwxxm:depositType>
is specified via a reference to an online definition at the WMO Codes
Registry (e.g. http://codes.wmo.int/bufr4/codeflag/0-20-086/1). - xlink is used to provide the
reference, including a human readable title (e.g. "Damp") to
complement the opaque identifier. The inclusion of the title improves the
human readability of the XML; although it should be noted that the title
is informative only. Normative information about the
referenced resource must be acquired from resolving the HTTP URI. - <iwxxm:contamination>
describes the portion of the runway affected by the deposition. It is also
specified throu a xlink-reference to an online definition at the WMO
Codes Registry (e.g. http://codes.wmo.int/bufr4/codeflag/0-20-087/5).
<iwxxm:depositType> schema
definition
To assist developers in understanding how to construct valid
XML documents, it is worth understanding more about how code-list elements are
defined. The following code fragment shows the XML schema definition for the
<iwxxm:depositType>
element (from metarSpeci.xsd):
Deposit
type schema definition
1 . ...
2 . <element maxOccurs="1" minOccurs="0" name="depositType"
3 . type="iwxxm:RunwayDepositsType">
4 . <annotation>
5 . <documentation>The type of runway deposit, such as damp conditions,
6 . wet snow, or ice. WMO 306: Table 0919
7 . </documentation>
8 . </annotation>
9 . </element>
10 . ...
The key points to note are the type specification (e.g. <iwxxm:RunwayDepositsType>) and the inclusion of
documentation.
On this occasion, it is also worth taking a look at the definition of <iwxxm:RunwayDepositsType> (from
metarSpeci.xsd):
1 . ...
2 . <complexType name="RunwayDepositsType">
3 . <annotation>
4 . <appinfo>
5 . <vocabulary>http://codes.wmo.int/bufr4/codeflag/0-20-086</vocabulary>
6 . <extensibility>none</extensibility>
7 . </appinfo>
8 . <documentation>Type of deposit on runway. See WMO No. 306 Vol I.1 code table 0919 and
9 . WMO No. 306 Vol I.2 FM 94 BUFR Code table 0 20 086 "Runway Deposits".
10 . </documentation>
11 . </annotation>
12 . <complexContent>
13 . <extension base="gml:ReferenceType"/>
14 . </complexContent>
15 . </complexType>
16 . ...
The points to note are:
- Inclusion of documentation extracted from the UML model
- usually providing a reference to the source Code-tables. - Inclusion of <vocabulary> element that defines
the target register from which values of this code-list
shall/should be taken; this is specified as a tagged-value within
the UML model. - Inclusion of <extensibility> element that
indicates the governance regime applied to- "none"
implies _ONLY_ terms from the specified code list are permitted, - "narrower"
implies you can use terms with more refined definitions (e.g. narrower
semantics), and - "any" implies that anything goes and the specified
code list is simply a recommendation!
- "none"
- The extension base is gml:ReferenceType
- implying that the values must be provided using a valid
xlink
Trend forecast
In this example METAR, the observation is followed by one trend forecast. As
noted before, a METAR message may contain up to three <iwxxm:trendForecast> elements. The following listing
illustrates the basic structure of a trend forecast:
basic structure trend forecast
1 . ...
2 . <iwxxm:trendForecast>
3 . <om:OM_Observation gml:id="trend-fcst-1">
4 . <om:type xlink:href="http://codes.wmo.int/49-2/observation-type/IWXXM/2.1/MeteorologicalAerodromeTrendForecast"/>
5 . <om:phenomenonTime/>
6 . <om:resultTime/>
7 . <om:procedure/>
8 . <om:observedProperty/>
9 . <om:featureOfInterest/>
10 . <om:result/>
11 . </om:OM_Observation>
12 . </iwxxm:trendForecast>
13 . ...
Trend forecast time
values
The trend forecast covers a two hour period. Given this, the phenomen time is defined as a <gml:timePeriod>, stating the begin and end of the
trend forecast. Since the result time (e.g. the issue-time of the trend
forecast) is identical with the result time of the METAR, it is defined by a
local reference to the <om:resultTime>
element of the observation.
Trend
forecast time values
1 . ...
2 . <om:phenomenonTime>
3 . <gml:TimePeriod gml:id="tp-201303120550Z-201303120750Z">
4 . <gml:beginPosition>2013-03-12T05:50:00Z</gml:beginPosition>
5 . <gml:endPosition>2013-03-12T07:50:00Z</gml:endPosition>
6 . </gml:TimePeriod>
7 . </om:phenomenonTime>
8 . <om:resultTime xlink:href="#ti-20130312T055000Z"/>
9 . ...
Observation
procedure and observed property
Since the observation procedure is defined within the <iwxxm:observation> element within this document, and an
unique gml:id attribute is provided, <om:procedure> just containes
an local reference to the former definition.
The observed property element defines the aggregation of possible pysical quantities, which may be contained in the METAR
trend forecast. The observed property definition is a reference to the WMO code
registry: http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeTrendForecast.
Since the feature of interest for the trend forecast is the same as for the
METAR observation before, <om:featureOfInterest>
contains a local reference via xlink to the
definition inside the document.
The listing below shows these elements:
1 . ...
2 . <om:procedure xlink:href="#p-49-2-metar" xlink:title="WMO 49-2 METAR procedure"/>
3 . <om:observedProperty
4 . xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeTrendForecast"
5 . xlink:title="METAR trend forecast properties"/>
6 . <om:featureOfInterest xlink:href="#sp-EDDF"/>
7 . ...
Trend forecast
result
The result is the main part of the trend forecast. It contains the expected
variation of the physical parameters during the trend period. In the case of
this example, the result-element contains one METAR trend forecast record. The
attribute changeIndicator defines the quality of the
change. E.g. BECOMING in this case means, the physical quantities mentioned in
the trend-forecast, will continously move from the
observed value to the value defined in the trend-forecast. Other possible
values are NO_SIGNIFICANT_CHANGES or TEMPORARY_FLUCTUATIONS. In this example
the horizontal visibility is expected to increase to 4000 meter (see line 6).
Trend
forecast result
1 . ...
2 . <om:result>
3 . <iwxxm:MeteorologicalAerodromeTrendForecastRecord
4 . gml:id="trend-fcst-record-1-201303120550Z-201303120750Z"
5 . changeIndicator="BECOMING" cloudAndVisibilityOK="false">
6 . <iwxxm:prevailingVisibility uom="m">4000</iwxxm:prevailingVisibility>
7 . <iwxxm:forecastWeather nilReason="http://codes.wmo.int/common/nil/nothingOfOperationalSignificance"/>
8 . </iwxxm:MeteorologicalAerodromeTrendForecastRecord>
9 . </om:result>
10 . ...