AvXMl-1.0-Tutorial-metar-EDDF-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 |
| Schematron | http://purl.oclc.org/dsdl/schematron | sch |
| XSLT v2 | http://www.w3.org/1999/XSL/Transform | xsl |
| 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.0) | http://def.wmo.int/opm/2013 | opm |
| WMO METCE (1.0) | http://def.wmo.int/metce/2013 | metce |
| ICAO Simple Aviation Features (1.0) | http://icao.int/saf/1.0 | saf |
| ICAO Meteorological Information Exchange Model (1.0) | http://icao.int/iwxxm/1.0 | 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
<?xml version="1.0" encoding="UTF-8"?>
<iwxxm:METAR xmlns:iwxxm="http://icao.int/iwxxm/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:om="http://www.opengis.net/om/2.0"
xmlns:metce="http://def.wmo.int/metce/2013"
xmlns:saf="http://icao.int/saf/1.0"
xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"
xmlns:sam="http://www.opengis.net/sampling/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://icao.int/iwxxm/1.0 http://schemas.wmo.int/iwxxm/1.0/iwxxm.xsd
http://def.wmo.int/metce/2013 http://schemas.wmo.int/metce/1.0/metce.xsd"
gml:id="metar-EDDF-20130312T055000Z" status="NORMAL" automatedStation="false">
<iwxxm:observation>...</iwxxm:observation>
<iwxxm:trendForecast>...</iwxxm:trendForecast>
</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/1.0/MeteorologicalAerodromeObservation
- http://codes.wmo.int/49-2/observation-type/IWXXM/1.0/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
...
<iwxxm:observation>
<om:OM_Observation gml:id="obs-EDDF-20130312T055000Z">
<om:type xlink:href="http://codes.wmo.int/49-2/observation-type/IWXXM/1.0/MeteorologicalAerodromeObservation"/>
<om:phenomenonTime/>
<om:resultTime/>
<om:procedure/>
<om:observedProperty/>
<om:featureOfInterest/>
<om:result/>
</om:OM_Observation>
</iwxxm:observation>
...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
...
<om:phenomenonTime>
<gml:TimeInstant gml:id="ti-20130312T055000Z">
<gml:timePosition>2013-03-12T05:50:00Z</gml:timePosition>
</gml:TimeInstant>
</om:phenomenonTime>
<om:resultTime xlink:href="#ti-20130312T055000Z"/>
...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
...
<om:procedure>
<metce:Process gml:id="p-49-2-metar">
<gml:description>WMO No. 49 Volume 2 Meteorological Service for International Air Navigation
APPENDIX 3 TECHNICAL SPECIFICATIONS RELATED TO METEOROLOGICAL OBSERVATIONS
AND REPORTS
</gml:description>
</metce:Process>
</om:procedure>
...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
...
<om:observedProperty
xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation"
xlink:title="Observed properties for Meteorological
Aerodrome Observation Reports (METAR and SPECI)"/>
...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
...
<om:featureOfInterest>
<sams:SF_SpatialSamplingFeature gml:id="sp-EDDF">
<sam:type xlink:href="http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0/SF_SamplingPoint"/>
<sam:sampledFeature/>
<sams:shape/>
</sams:SF_SpatialSamplingFeature>
</om:featureOfInterest>
...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
...
<sam:sampledFeature>
<saf:Aerodrome gml:id="uuid.d97143d0-00bb-11e3-b778-0800200c9a66">
<gml:identifier codeSpace="urn:uuid:">d97143d0-00bb-11e3-b778-0800200c9a66</gml:identifier>
<saf:designator>EDDF</saf:designator>
<saf:name>FRANKFURT AM MAIN INTERNATIONAL</saf:name>
<saf:locationIndicatorICAO>EDDF</saf:locationIndicatorICAO>
<saf:ARP>
<gml:Point gml:id="ref-point-EDDF"
uomLabels="deg deg m"
axisLabels="Lat Lon Altitude"
srsDimension="3"
srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
<gml:pos>50.0464 8.5986 112</gml:pos>
</gml:Point>
</saf:ARP>
</saf:Aerodrome>
</sam:sampledFeature>
...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 Simple Aeronautical Features (SAF). This data model is intended to align with the definition of Aerodrome within the broader ICAO Aeronautical Information Reference Model (AIRM); albeit only providing a subset of the information required for meteorological products.
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 5) 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 6) The name of the Aerodrome (e.g. <saf:name>) - this must be provided in BLOCK CAPITALS
- (line 7) The 4-letter ICAO location indicator for the Aerodrome or Heliport, as listed in ICAO Doc 7910
- (lines 8-16) The Aerodrome Reference Point - shown here defined using the 3-dimensional coordinate reference system EPSG-4979
GML requires the coordinate reference system in which the geometry is specified to be provided. Attribute srsName (line 13) references an authoritative publication of the EPSG 4326 coordinate reference system which is based on WGS84. Attributes uomLabels (line 10), axisLabels (line 11) and srsDimension (line 12) provide additional information. This means that the values provided within the <gml:pos> element (line 14) can be unambiguously used to geolocate the point.
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
...
<sams:shape>
<gml:Point gml:id="obs-point-EDDF"
uomLabels="deg deg m"
axisLabels="Lat Lon Altitude"
srsDimension="3"
srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
<gml:pos>50.0464 8.5986 112</gml:pos>
</gml:Point>
</sams:shape>
...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
...
<om:result>
<iwxxm:MeteorologicalAerodromeObservationRecord cloudAndVisibilityOK="false"
gml:id="observation-record-EDDF-20130312T055000Z">
<iwxxm:airTemperature uom="Cel">-4</iwxxm:airTemperature>
<iwxxm:dewpointTemperature uom="Cel">-4</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="hPa">1000</iwxxm:qnh>
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="deg">30</iwxxm:meanWindDirection>
<iwxxm:meanWindSpeed uom="kn">15</iwxxm:meanWindSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
<iwxxm:visibility>
<iwxxm:AerodromeHorizontalVisibility>
<iwxxm:prevailingVisibility uom="m">1400</iwxxm:prevailingVisibility>
</iwxxm:AerodromeHorizontalVisibility>
</iwxxm:visibility>
<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:rvr>
<iwxxm:rvr>
...
</iwxxm:rvr>
<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"/>
<iwxxm:cloud>
<iwxxm:AerodromeObservedClouds amountAndHeightUnobservableByAutoSystem="true" />
</iwxxm:cloud>
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:runway>
<saf:RunwayDirection gml:id="uuid.eddf-07-r-sf">
<gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-1-r-sf</gml:identifier>
<saf:designator>07R</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-1-sf">
<gml:identifier codeSpace="urn:uuid:">uuid.eddf-07-1-sf</gml:identifier>
<saf:designator>07R/25L</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/1"
xlink:title="Less than 10% of runway covered" />
<iwxxm:depthOfDeposit uom="mm">0</iwxxm:depthOfDeposit>
<iwxxm:estimatedSurfaceFriction uom="unity">0.9</iwxxm:estimatedSurfaceFriction>
</iwxxm:AerodromeRunwayState>
</iwxxm:runwayState>
<iwxxm:runwayState>
...
</iwxxm:runwayState>
<iwxxm:runwayState>
...
</iwxxm:runwayState>
</iwxxm:MeteorologicalAerodromeObservationRecord>
</om:result>
...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
- 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
...
<element maxOccurs="1" minOccurs="0" name="depositType"
type="iwxxm:RunwayDepositsType">
<annotation>
<documentation>The type of runway deposit, such as damp conditions,
wet snow, or ice. WMO 306: Table 0919
</documentation>
</annotation>
</element>
...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):
...
<complexType name="RunwayDepositsType">
<annotation>
<appinfo>
<vocabulary>http://codes.wmo.int/bufr4/codeflag/0-20-086</vocabulary>
<extensibility>none</extensibility>
</appinfo>
<documentation>Type of deposit on runway. See WMO No. 306 Vol I.1 code table 0919 and
WMO No. 306 Vol I.2 FM 94 BUFR Code table 0 20 086 "Runway Deposits".
</documentation>
</annotation>
<complexContent>
<extension base="gml:ReferenceType"/>
</complexContent>
</complexType>
...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!
- 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
...
<iwxxm:trendForecast>
<om:OM_Observation gml:id="trend-fcst-1">
<om:type xlink:href="http://codes.wmo.int/49-2/observation-type/IWXXM/1.0/MeteorologicalAerodromeTrendForecast"/>
<om:phenomenonTime/>
<om:resultTime/>
<om:procedure/>
<om:observedProperty/>
<om:featureOfInterest/>
<om:result/>
</om:OM_Observation>
</iwxxm:trendForecast>
...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
...
<om:phenomenonTime>
<gml:TimePeriod gml:id="tp-201303120550Z-201303120750Z">
<gml:beginPosition>2013-03-12T05:50:00Z</gml:beginPosition>
<gml:endPosition>2013-03-12T07:50:00Z</gml:endPosition>
</gml:TimePeriod>
</om:phenomenonTime>
<om:resultTime xlink:href="#ti-20130312T055000Z"/>
...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:
...
<om:procedure xlink:href="#p-49-2-metar" xlink:title="WMO 49-2 METAR procedure"/>
<om:observedProperty
xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeTrendForecast"
xlink:title="METAR trend forecast properties"/>
<om:featureOfInterest xlink:href="#sp-EDDF"/>
...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
...
<om:result>
<iwxxm:MeteorologicalAerodromeTrendForecastRecord
gml:id="trend-fcst-record-1-201303120550Z-201303120750Z"
changeIndicator="BECOMING" cloudAndVisibilityOK="false">
<iwxxm:prevailingVisibility uom="m">4000</iwxxm:prevailingVisibility>
<iwxxm:forecastWeather nilReason="http://codes.wmo.int/common/nil/nothingOfOperationalSignificance"/>
</iwxxm:MeteorologicalAerodromeTrendForecastRecord>
</om:result>
...