AvXML-1.0RC2-tutorial-metar-LKKV-2007-07-25T12Z
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.
Note (2013-05-21): updated example to fix error in line 44, element <saf:locationIndicatorICAO> now correctly refers to LKKV - same as value of element <saf:designator>.
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.0RC2) | http://def.wmo.int/opm/2013 | opm |
| WMO METCE (1.0RC2) | http://def.wmo.int/metce/2013 | metce |
| ICAO Simple Aviation Features (1.0RC2) | http://icao.int/saf/1.0RC2 | saf |
| ICAO Meteorological Information Exchange Model (1.0RC2) | http://icao.int/iwxxm/1.0RC2 | 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.0RC2"
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://def.wmo.int/metce/2013"
xmlns:gss="http://www.isotc211.org/2005/gss"
xmlns:saf="http://icao.int/saf/1.0RC2"
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.0RC2 http://schemas.wmo.int/iwxxm/1.0RC2/iwxxm.xsd
http://def.wmo.int/metce/2013 http://schemas.wmo.int/metce/1.0RC2/metce.xsd"
gml:id="metar-LKKV-20070725T12Z"
status="NORMAL" automatedStation="false">
<iwxxm:observation>...</iwxxm:observation>
</iwxxm:METAR>Note that in line 18 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 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
At time of publishing AvXML1.0 RC2, the WMO Codes registry is yet to be deployed at the http://codes.wmo.int. As an interim measure, a BETA deployment is provided at http://test.wmocodes.info.
For reference, please refer to:
- http://test.wmocodes.info/49-2/observation-type/IWXXM/1.0/MeteorologicalAerodromeObservation
- http://test.wmocodes.info/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.
...
<iwxxm:observation>
<om:OM_Observation gml:id="obs-LKKV-20070725T120000Z">
<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 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="ti-20070725T12Z">
<gml:timePosition>2007-07-25T12:00:00Z</gml:timePosition>
</gml:TimeInstant>
</om:phenomenonTime>
<om:resultTime xlink:href="#ti-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 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.
...
<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.
At time of publication of RC2, the WMO Code Registry is available in BETA at http://test.wmocodes.info. In the interim, please refer to: http://test.wmocodes.info/49-2/observable-property.
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://test.wmocodes.info/49-2/observable-property/MeteorologicalAerodromeObservation
...
<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:
...
<om:featureOfInterest>
<sams:SF_SpatialSamplingFeature gml:id="sp-LKKV">
<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:
...
<sam:sampledFeature>
<saf:Aerodrome gml:id="uuid.f4ebfc50-b727-11e2-9e96-0800200c9a66">
<gml:identifier codeSpace="urn:uuid:">f4ebfc50-b727-11e2-9e96-0800200c9a66</gml:identifier>
<saf:designator>LKKV</saf:designator>
<saf:name>KARLOVY VARY INTERNATIONAL</saf:name>
<saf:locationIndicatorICAO>LKKV</saf:locationIndicatorICAO>
<saf:ARP>
<gml:Point gml:id="ref-point-LKKV"
uomLabels="deg deg m"
axisLabels="Lat Lon Altitude"
srsDimension="3"
srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
<gml:pos>50.20 12.92 606</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 Karlovy Vary Airport in the Czech Republic. 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 amy 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:
...
<sams:shape>
<gml:Point gml:id="obs-point-LKKV"
uomLabels="deg deg m"
axisLabels="Lat Lon Altitude"
srsDimension="3"
srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
<gml:pos>50.20 12.92 606</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 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 cloudAndVisibilityOK="false"
gml:id="observation-record-LKKV-20070725T12Z">
<iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature>
<iwxxm:dewpointTemperature uom="Cel">10</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="hPa">1010</iwxxm:qnh>
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="deg">210</iwxxm:meanWindDirection>
<iwxxm:meanWindSpeed uom="m/s">2.6</iwxxm:meanWindSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
<iwxxm:presentWeather
xlink:href="http://codes.wmo.int/306/4678/VCSH"
xlink:title="Showers (in vicinity)"/>
<iwxxm:recentWeather
xlink:href="http://codes.wmo.int/306/4678/TS"
xlink:title="Thunderstorm"/>
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:depositType
xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1"
xlink:title="Damp"/>
</iwxxm:AerodromeRunwayState>
</iwxxm:runwayState>
</iwxxm:MeteorologicalAerodromeObservationRecord>
</om:result>
...Looking in detail at the result we see:
Line 3 (CAVOK)
...
cloudAndVisibilityOK="false"
...- CAVOK (e.g. attribute cloudAndVisibilityOK) is false
Lines 5 (Air temperature)
...
<iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature>
...- The value is 27 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://test.wmocodes.info/common/c-15/me/airTemperatureIn the final release of AvXML1.0, it is anticipated that this information will also be visible within the XML Schema as <annotation>.
Note that at time of publication of RC2, the WMO Codes Registry is not yet deployed to http://codes.wmo.int. In the interim, please refer to the BETA deployment at http://test.wmocodes.info. For example: http://test.wmocodes.info/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.Noting that we are currently in BETA with the WMO Codes Registry, Common code-table C-6 is sparsely deployed at http://test.wmocodes.info. A definition of "Degree Celsius" may be found here: http://test.wmocodes.info/common/c-6/_060.
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)
...
<iwxxm:dewpointTemperature uom="Cel">10</iwxxm:dewpointTemperature>
<iwxxm:qnh uom="hPa">1010</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)
...
<iwxxm:surfaceWind>
<iwxxm:AerodromeSurfaceWind variableDirection="false">
<iwxxm:meanWindDirection uom="deg">210</iwxxm:meanWindDirection>
<iwxxm:meanWindSpeed uom="m/s">2.6</iwxxm:meanWindSpeed>
</iwxxm:AerodromeSurfaceWind>
</iwxxm:surfaceWind>
...- The wind direction is not variable (attribute variableDirection is false)
- The mean wind direction is specified as 210 degrees (measured from true-north)
- The mean wind speed is specified as 2.6 meters per second
Lines 14-19 (Present and recent weather)
...
<iwxxm:presentWeather
xlink:href="http://codes.wmo.int/306/4678/VCSH"
xlink:title="Showers (in vicinity)"/>
<iwxxm:recentWeather
xlink:href="http://codes.wmo.int/306/4678/TS"
xlink:title="Thunderstorm"/>
...- Present weather is "Showers (in vicinity)" (VCSH).
- Recent weather is "Thunderstorm" (TS).
- <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.
- At time of publishing RC2, the WMO Codes Register is not yet deployed at http://codes.wmo.int. As an interim measure, a BETA version of the Registry is available at http://test.wmocodes.info. Please refer to the registers themselves for more details:
- AerodromePresentWeather - very sparsely populated at time of RC2 release
- AerodromeRecentWeather
- 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 to be published within the WMO Codes Registry at http://codes.wmo.int/306/4678. At time of publication of RC2, a sparsely populated BETA version of this register is provided: http://codes.wmo.int/306/4678.
- For reference, please refer to:
- 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/VCSH
- In due course more terms will be added along with additional descriptive information.
Lines 20-26 (Runway state)
...
<iwxxm:runwayState>
<iwxxm:AerodromeRunwayState>
<iwxxm:depositType
xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1"
xlink:title="Damp"/>
</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.
- At time of publishing RC2, the WMO Codes Registry is yet to be deployed operationally. In the interim, a BETA deployment is provided at http://test.wmocodes.info. For reference, please refer to http://test.wmocodes.info/bufr4/codeflag/0-20-086/1.
<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):...
<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
