IWXXM-3.0-Tutorial-metar-EDDF-2013-03-12T0550Z
Note that this tutorial has not been updated for IWXXM 3.0
This METAR is intended as an example and does not represent actual observed conditions.
The full XML for this example can be found here.
Note that the XML Namespace is distinct from the schema locations. For reference, these are provided here.
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.
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.
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" For example:
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.
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:
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.
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.
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.
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 href="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]
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:
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:
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:
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:
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
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
Looking in detail at the result we see:
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.
The dew-point temperature and QNH values are provided along with their units of Celsius (Cel) and hecto-pascals (hPa).
Amount and height of clouds is not observable (eg. the attribute amountAndHeightUnobservableByAutoSystem is set "true").
Deposit type schema definition
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).
The points to note are:
!!!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
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
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 metre (see line 6).
Trend forecast result
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.
Observation structure
WMO METCE and ICAO IWXXM are built on the foundation provided by ISO19156: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" For example:
- 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
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 value
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" [http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006%28E%29.zip|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 . ...
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 href="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:
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:
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 . ...
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!<p></p>
The observation result is the main part of this METAR; it provides the data values for the observed properties. As required by the MeteorologicalAerodromeObservationclass, 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<p></p>
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 metres
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 metres for the first two runways, and 1900 metres 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.
- In due course more terms will be added along with additional descriptive information.
Lines 40-42 (Clouds)
... <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 through 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,
- "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.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 contains a 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. Theattribute 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 metre (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 . ...