AvXML-1.0RC1-tutorial-example
METAR for Karlovy Vary Airport, midday 25-July-2007
This METAR is intended as an example and does not represent actual observed conditions.
For simplicity, this METAR does not include a trend forecast.
The full XML for this example can be found here. UPDATE: hyperlink now fixed (2012-12-11)
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 Meteorological Basic Types (1.0RC1) | http://data.wmo.int/def/met-basic/1.0RC1 | met-basic |
| WMO Observable Property Model(1.0RC1) | http://data.wmo.int/def/opm/1.0RC1 | opm |
| WMO METCE (1.0RC1) | http://data.wmo.int/def/metce/1.0RC1 | metce |
| ICAO Simple Aviation Features (1.0RC1) | http://icao.int/saf/1.0RC1 | saf |
| ICAO Weather Information Exchange Model | http://icao.int/iwxxm/1.0RC1 | 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 a single <iwxxm:observation> element. 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 zero trend forecasts.
<?xml version="1.0" encoding="UTF-8"?>
<iwxxm:METAR xmlns:iwxxm="http://icao.int/iwxxm/1.0RC1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gco="http://www.isotc211.org/2005/gco"
xmlns:gmd="http://www.isotc211.org/2005/gmd"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:om="http://www.opengis.net/om/2.0"
xmlns:metce="http://data.wmo.int/def/metce/1.0RC1"
xmlns:gss="http://www.isotc211.org/2005/gss"
xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"
xmlns:gts="http://www.isotc211.org/2005/gts"
xmlns:gsr="http://www.isotc211.org/2005/gsr"
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.0RC1 http://schemas.wmo.int/iwxxm/1.0RC1/iwxxm.xsd
http://data.wmo.int/def/metce/1.0RC1 http://schemas.wmo.int/metce/1.0RC1/metce.xsd"
gml:id="metar-LKKV-20070725T12Z"
status="NORMAL" automatedStation="false">
<iwxxm:observation>...</iwxxm:observation>
</iwxxm:METAR>Note that in line 17 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.
Although omitted in this example, 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 shall be managed in a controlled register that will be published by WMO; e.g.
- http://data.wmo.int/def/observationType/iwxxm/1.0RC1/MeteorologicalAerodromeObservation
- http://data.wmo.int/def/observationType/iwxxm/1.0RC1/MeteorologicalAerodromeTrendForecast
For an existing example, please refer to the OpenGIS definition of 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.
...
<iwxxm:observation>
<om:OM_Observation gml:id="observation-LKKV-20070725T120000Z">
<om:type
xlink:href="http://data.wmo.int/def/observationType/iwxxm/1.0RC1/MeteorologicalAerodromeObservation"
xlink:title="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 12:00 UTC on 25th July 2007. In ISO 8601 format, this is defined as: 2007-07-25T12:00: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.
...
<om:phenomenonTime>
<gml:TimeInstant gml:id="time-instant-20070725T12Z">
<gml:timePosition>2007-07-25T12:00:00Z</gml:timePosition>
</gml:TimeInstant>
</om:phenomenonTime>
<om:resultTime xlink:href="#time-instant-20070725T12Z"/>
...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 only the provision of a reference to human-readable on-line documentation that describes the procedure: <metce:documentationRef>.
Here, we refer to the relevant section of WMO No. 49 Volume 2 that describes the procedure for METAR observations. Again, xlink:href and xlink:title are used.
...
<om:procedure>
<metce:Process gml:id="metar-observation-procedure">
<metce:documentationRef
xlink:href="http://wis.wmo.int/procedure=MetarOb"
xlink:title="WMO No. 49 Volume 2 Meteorological Service for International Air Navigation
APPENDIX 3 TECHNICAL SPECIFICATIONS RELATED TO METEOROLOGICAL OBSERVATIONS AND REPORTS"/>
</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 27 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, a mechanism is required to aggregate a set of physical properties into a single composite.
Furthermore, the 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 will publish authoritative definitions that comprise the set of observable properties that may be reported in these products.
Note that these definitions are not yet available to support the 1.0RC1 release.
...
<om:observedProperty
xlink:href="http://data.wmo.int/def/observableProperty/metarSpeci/observation"
xlink:title="Observed properties for METAR and SPECI (Meteorological Aerodrome Reports)"/>
...The resource referenced here is an instance of CompositeObservableProperty (from the "Observable Property Model" which has been developed in the OGC Sensor Web Enablement Standards Working Group). More information regarding this resource may be found here.
The anticipate URIs for the CompositeObservableProperties to be published by WMO for regulated products in the aeronautical domain are:
- <http://data.wmo.int/def/observableProperty/metarSpeci/observation>
- <http://data.wmo.int/def/observableProperty/metarSpeci/trendForecast>
- <http://data.wmo.int/def/observableProperty/taf/forecast>
- <http://data.wmo.int/def/observableProperty/sigmet/evolvingConditionAnalysis>
- <http://data.wmo.int/def/observableProperty/sigmet/positionAnalysis>
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:
...
<om:featureOfInterest>
<sams:SF_SpatialSamplingFeature gml:id="sampling-point-LKKV">
<sam:type
xlink:href="http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0/SF_SamplingPoint"
xlink:title="SF_SamplingPoint"/>
<sam:sampledFeature
xlink:href="http://icao.int/def/aerodrome/LKKV"
xlink:title="Karlovy Vary Airport"/>
<sams:shape>...</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 (lines 4-6).
IWXXM relies on rule-based validation to ensure that the correct type of spatial sampling feature is used in this instance.
Lines 7-9 define the real-world entity that the observation is intended to describe; in this case Karlovy Vary Airport. Again, xlink is used to reference an externally published resource. We anticipate that ICAO will publish an authoritative register containing the definition of aerodromes used for international civil aviation.
Each definition will resolve to provide useful information about the aerodrome (e.g. human-readable web-pages or machine-readable content; the format provided will be determined using HTTP content negotiation).
Note that at present, this register of aerodromes does not exist.
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 10).
The code fragment below shows the GML definition of the location (e.g. <gml:Point>):
...
<sams:shape>
<gml:Point gml:id="aerodrome-reference-point-LKKV"
axisLabels="Lat Lon"
srsDimension="2"
srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:pos>50.20 12.92</gml:pos>
</gml:Point>
</sams:shape>
...Best practice for aerodrome reports (METAR/SPECI and TAF) is to use the aerodrome reference point.
GML requires the coordinate reference system in which the geometry is specified to be provided. Attribute srsName (line 6) references an authoritative publication of the EPSG 4326 coordinate reference system which is based on WGS84. Attributes axisLabels (line 4) and srsDimension (line 5) provide additional information. This means that the values provided within the <gml:pos> element (line 7) can be unambiguously used to geolocate the sampling point.
A side benefit of using spatial sampling features is that even though we are unable to resolve the definition of the aerodrome (e.g. the sampled feature), the METAR report includes the position information required to locate the observation.
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 used here is fairly simple and only includes a small 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:
...
<om:result>
<iwxxm:MeteorologicalAerodromeObservationRecord
ceilingAndVisibilityOK="false"
gml:id="observation-record-LKKV-20070725T12Z">
<iwxxm:airTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">
27
</iwxxm:airTemperature>
<iwxxm:dewpointTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">
10
</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="http://opengis.net/def/uom/UCUM/0/hPa">
1010
</iwxxm:qnh>
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:depositType
xlink:href="http://data.wmo.int/def/bufr4/codeflag/0-20-086/1"
xlink:title="Damp"/>
</iwxxm:AerodromeRunwayState>
</iwxxm:runwayState>
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="http://data.wmo.int/def/uom/degrees-true">
210
</iwxxm:meanWindDirection>
<iwxxm:windSpeed uom="http://opengis.net/def/uom/UCUM/0/m/s">
2.6
</iwxxm:windSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
<iwxxm:recentWeather
xlink:href="http://data.wmo.int/def/306/4678/TS"
xlink:title="Thunderstorm"/>
<iwxxm:presentWeather
xlink:href="http://data.wmo.int/def/306/4678/VCSH"
xlink:title="Showers (in vicinity)"/>
</iwxxm:MeteorologicalAerodromeObservationRecord>
</om:result>
...Looking in detail at the result we see:
Line 4 (CAVOK)
...
ceilingAndVisibilityOK="false"
...- CAVOK (e.g. attribute ceilingAndVisibilityOK) is false
Lines 6-8 (Air temperature)
...
<iwxxm:airTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">
27
</iwxxm:airTemperature>
...- The value is 27 Celsius
- Following best practice, the unit of measure (e.g. attribute uom) is specified as a reference to the Unified Code for the Units of Measure (UCUM)
<iwxxm:airTemperature> schema definition
As an aside, it is worth understanding a little more about the definition of the <iwxxm:airTemperature> element. The code fragment below shows the definition of this element (extracted from metarSpeci.xsd):...
<element name="airTemperature" type="met-basic:AirTemperatureType">
<annotation>
<documentation>The observed air temperature</documentation>
</annotation>
</element>
...Here we see that airTemperature is specified with type AirTemperatureType (from met-basic; the meteorological basic types published by WMO). Also, the schema provides documentation about the element which has been extracted from the UML model).
The WMO meteorological basic types model provides a palette of physical property and code-list classes that can be used as types for properties in Application Schema such as IWXXM. This is intended to ensure that the semantics defined by WMO are consistently incorporated into the models the build on the WMO foundation. Please refer to the "Meteorological basic types" package in the UML model for more information.
The AirTemperature class (from met-basic) is a sub-class of Measure (from ISO 19103 Basic types) and requires the unit of measure to be provided alongside the data value.
Lines 9-14 (Dew-point temperature and QNH)
...
<iwxxm:dewpointTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">
10
</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="http://opengis.net/def/uom/UCUM/0/hPa">
1010
</iwxxm:qnh>
...- The mandatory dew-point temperature and QNH values are provided along with their units of Celsius (Cel) and hecto-pascals (hPa).
Lines 15-21 (Runway state)
...
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:depositType
xlink:href="http://data.wmo.int/def/bufr4/codeflag/0-20-086/1"
xlink:title="Damp"/>
</iwxxm:AerodromeRunwayState>
</iwxxm:runwayState>
...- <iwxxm:depositType> is specified via a reference to an on-line definition (e.g. <http://data.wmo.int/def/bufr4/codeflag/0-20-086/1>).
- xlink is used to provide the reference, once again including a human readable title (e.g. "Damp"). 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.
- As WMO develops new data-exchange products using contemporary formats such as XML that complement the existing BUFR and GRIB code-forms, it is essential that terms from BUFR and GRIB code-tables are published as web-accessible definitions so that they can be referred to from data products.
- In this case, one can infer from the URI .../bufr4/codeflag/0-20-086/... that the source code-table is BUFR edition 4, Code- and Flag-table #0-20-086 "Runway deposit".
- Each term from the BUFR code-table is assigned an HTTP URI by appending the code-figure from the table to the URI of the register; thus code-figure #1 "Damp" shall have the URI <http://data.wmo.int/def/bufr4/codeflag/0-20-086/1>.
Note that the web-accessible registers and definitions are unavailable for 1.0RC1.
<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:...
<element maxOccurs="1" minOccurs="0" name="depositType"
type="met-basic: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. <met-basic:RunwayDepositsType>) and the inclusion of documentation.
On this occasion, it is also worth taking a look at the definition of <met-basic:RunwayDepositsType> (from runwaySurfaceProperties.xsd):
...
<complexType name="RunwayDepositsType">
<annotation>
<appinfo>
<vocabulary>http://data.wmo.int/def/bufr/codeflag/0-20-086</vocabulary>
<extensibility>none</extensibility>
</appinfo>
<documentation>Type of deposit on runway. See WMO No. 306:
- WMO Code table 0919; and
- BUFR Code table 0 20 086
</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
Crucially, the code-lists are managed and maintained externally to the model. Thus an update to the code-lists does not require the model and XML Schema to be republished!
Given that the extension base is gml:ReferenceType, the XML Schema will only validate that one enters a URI conforming to IETF RFC 3986. We anticipate providing rule-based validation in subsequent releases to ensure that only members of the designated code-list are permitted.
Lines 22-31 (Surface wind)
...
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="http://data.wmo.int/def/uom/degrees-true">
210
</iwxxm:meanWindDirection>
<iwxxm:windSpeed uom="http://opengis.net/def/uom/UCUM/0/m/s">
2.6
</iwxxm:windSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
...- The wind direction is not variable (attribute variableDirection is false)
- The unit of measure is one of the few that the Unified Code for Units of Measure (UCUM) does not provide: degrees-true. In due course, WMO will publish an authoritative definition for this unit of measure in lieu of other agents. The other unit of measure that WMO anticipates publishing is okta (e.g. <http://data.wmo.int/def/uom/okta>
Lines 32-37 (Recent and present weather)
...
<iwxxm:recentWeather
xlink:href="http://data.wmo.int/def/306/4678/TS"
xlink:title="Thunderstorm"/>
<iwxxm:presentWeather
xlink:href="http://data.wmo.int/def/306/4678/VCSH"
xlink:title="Showers (in vicinity)"/>
...- Recent weather is "Thunderstorm" (TS).
- Present weather is "Showers (in vicinity)" (VCSH).
- <iwxxm:recentWeather> has type AerodromeRecentWeather (from met-basic); <vocabulary> for this code-list class is specified as <http://data.wmo.int/def/49-2/AerodromeRecentWeather>.
- <iwxxm:presentWeather> has type AerodromePresentWeather (from met-basic); <vocabulary> for this code-list class is specified as <http://data.wmo.int/def/49-2/AerodromePresentWeather>.
- These code-lists each contain the sub-set of terms from WMO No. 306 Code-table 4678 "Significant Weather" <http://data.wmo.int/def/306/4678> that are permitted for describing present and recent weather at an aerodrome within a METAR as defined in ICAO Annex 3. More information about these significant weather terms please refer to this page.
- Both XML schema and UML model provide documentation describing this relationship.
