IWXXM FSBE "Aviamettelecom of Roshydromet"

Краткое руководство по кодированию сводки погоды METAR в формате AvXML версии 1.1.

Оригинальный текст руководства на английском языке можно посмотреть здесь ссылка.

METAR по аэродрому Карловы Вары, 12:00 25-Июля-2007

Этот METAR предназначен для примера и не отражает фактические наблюдаемые условия. Для простоты, в этот METAR не включен trend forecast.

Полный XML-код этого примера можно найти здесь ссылка.

XML Namespaces

В этом примере, прямо или косвенно, испльзуются следующие пространства имен XML:

ОписаниеXML NamespaceDefault namespace prefix
XML Schemahttp://www.w3.org/2001/XMLSchemaxsd
Schematronhttp://purl.oclc.org/dsdl/schematronsch
XSLT v2http://www.w3.org/1999/XSL/Transformxsl
XML Linking Languagehttp://www.w3.org/1999/xlinkxlink
OGC GML 3.2.1http://www.opengis.net/gml/3.2gml
ISO/TS 19139:2007 metadata XML schema implementationhttp://www.isotc211.org/2005/gmdgmd
OGC OMXML Observations and Measurementshttp://www.opengis.net/om/2.0om
OGC OMXML Sampling Featureshttp://www.opengis.net/sampling/2.0sf
OGC OMXML Spatial Sampling Featureshttp://www.opengis.net/samplingSpatial/2.0sams
WMO Observable Property Model(1.0)http://def.wmo.int/opm/2013opm
WMO METCE (1.0)http://def.wmo.int/metce/2013metce
ICAO Simple Aviation Features (1.0)http://icao.int/saf/1.0saf
ICAO Meteorological Information Exchange Model (1.0)http://icao.int/iwxxm/1.0iwxxm

*Обратите внимание, что последовательность расположения XML Namespace в таблице отличается от расположения в реальном XML-файле.

Кроме понимания основ XML необходимо обладать некоторыми знаниями о спецификации пространства имен XML. Мы не будем исследовать спецификацию подробно, однако необходимо знать, что пространство имен, по существу, связано с использованием привязки префикса (к примеру iwxxm) к определенному URI (к примеру http://icao.int/iwxxm/1.0). Для помещения элемента в пространство имен, определенное ассоциированным URI можно добавить префикс в начало имен этого элемента (к примеру iwxxm:METAR). Использование объявления пространств имен и их префиксов дает возможность использовать определения элементов из нескольких пространств имен (например saf:Element, metce:Element, gml:Element и т.д.) в одной схеме.

Синтаксис объявления пространства имен иногда может сбить с толку. Объявление начинается с http://, однако оно не ссылается на файл с описанием схемы. На самом деле, например, ссылка http://icao.int/iwxxm/1.0 вообще не ведет ни на один файл, а только на назначенное имя.

Обзор сводок METAR

METAR в XML-кодировке имеет корневой элемент <iwxxm:METAR> в котором объявляется информация о пространстве имен XML. Элемент <iwxxm:METAR> кодирует сводку METAR.

После объявления пространства имен экземпляра XML-схемы можно использовать в нем атрибут schemaLocation. Данный атрибут фактически состоит из двух значений. Первым значением, или аргументом, является заданное пространство имен. В нашем примере им является пространство имен – http://icao.int/iwxxm/1.0. Вторым значением, или аргументом, является местоположение XML-схемы, используемой для ограничения данного пространства имен. Обратите внимание на пробел между URI-адресом пространства имен и путем размещения файла схемы. Обязательно вставляйте этот пробел! Его отсутствие приводит к различного рода проблемам. Как видно, можно использовать несколько пространств имен, необходимо лишь добавить вторую (или третью, четвертую и т.д.) пару значений к атрибуту schemaLocation. В приведенном примере, первая пара - строки 16 и 17, вторая пара - строки 18 и 19.

status and automatedStation включены как XML-атрибуты. В этом примере сводка METAR содержит один элемент <iwxxm:observation>. Сводка METAR может содержать до трех прогнозов изменений (trend forecast).
Фрагмент кода ниже показывает объявление пространства имен XML плюс основные структуры сводки METAR, содержащей одно наблюдение и ноль прогнозов изменений.

Namespace declarations, basic structure
 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <iwxxm:METAR xmlns:iwxxm="http://icao.int/iwxxm/1.0"
 3.     xmlns:saf="http://icao.int/saf/1.0"
 4.     xmlns:metce="http://def.wmo.int/metce/2013"
 5.     xmlns:om="http://www.opengis.net/om/2.0"
 6.     xmlns:gml="http://www.opengis.net/gml/3.2"
 7.     xmlns:sam="http://www.opengis.net/sampling/2.0"
 8.     xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"
 9.     xmlns:gco="http://www.isotc211.org/2005/gco"
10.     xmlns:gmd="http://www.isotc211.org/2005/gmd"
11.     xmlns:gsr="http://www.isotc211.org/2005/gsr"
12.     xmlns:gss="http://www.isotc211.org/2005/gss"
13.     xmlns:gts="http://www.isotc211.org/2005/gts"
14.     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
15.     xmlns:xlink="http://www.w3.org/1999/xlink"
16.     xsi:schemaLocation="http://icao.int/iwxxm/1.0
17.         http://schemas.wmo.int/iwxxm/1.0/iwxxm.xsd
18.         http://def.wmo.int/metce/2013
19.         http://schemas.wmo.int/metce/1.0/metce.xsd"
20.     gml:id="metar-LKKV-20070725T12Z"
21.     status="NORMAL"
22.     automatedStation="false">
23. <iwxxm:observation>...</iwxxm:observation>
24. </iwxxm:METAR>

Обратите внимание, что в строке 20 фрагмента кода предоставлен XML-атрибут gml:id. Все экземпляры этого атрибута в рамках данного документа должны быть уникальными. Кроме того рекомендуется, чтобы gml:id для сводки был глобально уникальным и соответсвовал шаблону {report-type}-{aerodrome-identifier}-{issue-time}. Время должно предоставляться в формате ISO 8601 ссылка.

Observation structure

WMO METCE и ICAO IWXXM построены на базе ISO 19156:2011 "Geographic information — Observations and measurements" ссылка. Как составитель этого стандарта ISO, открытый консорциум геопространственных данных (Open Geospatial Consortium) также опубликовал информацию касающуюся Наблюдений и Измерений: Topic 20: Observations and Measurements ссылка.

Больше информации о вариантах решений можно найти в документации по модели.

Учитывая зависимость от ISO 19156:2011, основная часть METAR (например элемент <iwxxm:observation>) обеспечивается с помощью экземпляра <om:OM_Observation>.

Класс OM_Observation предоставляет платформу для описания события наблюдения и измерения; estimation of the value (the result) of a property (the observed property) of some entity (the feature of interest) using a specified procedure в заданное время. OM_Observation также предоставляет механизмы для сбора качественной информации about the result and arbitrary parameters concerning the observation event.

OM_Observation позволяет описать произвольно сложные процедуры, от измерения температуры воздуха, используя определенный тип термометра до сложного численного моделирования. С помощью этого класса можно даже оценивать значения свойств в некоторый момент будущего! Для ясности, OM_Observation может описывать время завершения процедуры время результата) и время, или период времени, к которому имеет отношение результат (временное явления). Для примера, прогноз может быть составлен в 12:00Z (время результата) и описывать явление которое произойдет в 18:00Z при T+6. Аналогичным образом, если мы имеем дело с физическими образцами, такими как ледяной керн, есть время когда образец собирают и время, исчисляемое днями, месяцами и даже годами, когда образец анализируют в лабораторных условиях.

Хотя в этом примере опущен элемент <iwxxm:trendForecast>, он также обеспечивается с помощью экземпляра <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.

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.

Обратите внимание, что xlink ссылка чтобы обратиться к определению класса. Атрибут xlink:href обеспечивает ссылки, в то время как xlink:title обеспечивает информативную удобочитаемую метку целевого ресурса. Это хорошая практика, включать xlink:title. Однако, как показано в этом случае, когда URI обеспечивает удобочитаемый идентификатор, допустимо опустить атрибут xlink:title.

Basic structure of om:OM_Observation
 1. ...
 2.     <iwxxm:observation>
 3.         <om:OM_Observation gml:id="obs-LKKV-20070725T120000Z">
 4.             <om:type xlink:href="http://codes.wmo.int/49-2/observation-type/IWXXM/1.0/MeteorologicalAerodromeObservation"/>
 5.             <om:phenomenonTime>...</om:phenomenonTime>
 6.             <om:resultTime xlink:href="#ti-20070725T12Z"/>
 7.             <om:procedure>...</om:procedure>
 8.             <om:observedProperty
 9.                 xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation"
10.                 xlink:title="Observed properties for Meteorological Aerodrome Observation Reports (METAR and SPECI)"/>
11.             <om:featureOfInterest>...</om:featureOfInterest>
12.             <om:result>...</om:result>
13.         </om:OM_Observation>
14.     </iwxxm:observation>
15. ...

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.

Значение времени наблюдения

Рассматриваемая сводка METAR была выпущена для 12:00 UTC 25 июля 2007 года. В формате ISO 8601, это время будет записано следующим образом: 2007-07-25T12:00:00Z.

Так как METAR, это фактическая погода, то время наблюдения (например время явления) и время выпуска (например время сводки) будут идентичными. Учитывая это, а не повтор элемента <gml:TimeInstant>, элемент <om:resultTime> использует xlink-ссылку к приведенному выше определению; начало URI с "#" является указателем локальной ссылки в файле.

Observation time values
 1. ...
 2.             <om:phenomenonTime>
 3.                 <gml:TimeInstant gml:id="ti-20070725T12Z">
 4.                     <gml:timePosition>2007-07-25T12:00:00Z</gml:timePosition>
 5.                 </gml:TimeInstant>
 6.             </om:phenomenonTime>
 7.             <om:resultTime xlink:href="#ti-20070725T12Z"/>
 8. ...


Observation procedure

Класс MeteorologicalAerodromeObservation сдерживается (ограничивается) тем, что <om:procedure> должен ссылаться на экземпляр класса Process (из METCE). Это ограничение не применяется при использовании XML Schema, but using rule-based validation in the form of schematron (ISO/IEC 19757-3:2006 "Information technology - Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation - Schematron" (zip file ссылка)).

In its simplest form, METCE Process requires no content. However, an "empty" process definition is not very helpful!

It is recommended that one provides reference to human-readable on-line documentation that describes the procedure (e.g. using the element <metce:documentationRef> enabling the use of xlink:href to provide a hyperlink reference to the documentation). An acceptable alternative is to cite a well known document (e.g. using the element <gml:description>).

In the case of METAR, as a regulated product, one can simply reference the appropriate clause(es) from ICAO Annex 3 (WMO No. 49) technical regulations.

Also note in line 3 of the code fragment the inclusion of a mandatory gml:id attribute which provides a unique identifier within the scope of the XML document.

Observation procedure
 1. ...
 2.             <om:procedure>
 3.                 <metce:Process gml:id="p-49-2-metar">
 4.                     <gml:description>WMO No. 49 Volume 2 Meteorological Service for International Air Navigation
 5.                                      APPENDIX 3 TECHNICAL SPECIFICATIONS RELATED TO METEOROLOGICAL OBSERVATIONS
 6.                                      AND REPORTS</gml:description>
 7.                 </metce:Process>
 8.             </om:procedure>
 9. ...


Observed property

Typically, the observed property is used to support search and discovery use-cases (e.g. "find me all the observations using property air temperature"). The Open Geospatial Consortium Sensor Observation Service (OGC 12-006 Sensor Observation Service Interface Standard 2.0 ссылка) uses the observed property as a primary mechanism to retrieve observation instances.

However, the OM_Observation model allows only a single instance of <om:observedProperty>. In the case of the METAR observation, a total of 26 individual physical properties may be measured; everything from air temperature to sea-surface state.

As the observation instance is able to refer to only a single definition, the CompositeObservableProperty (from the ObservablePropertyModel) is used to aggregate a set of physical properties into a single composite.

The observed property definition must be referenced remotely (e.g. via xlink); it cannot be specified in-line within the document.

For regulated products such as METAR, WMO publishes a set of CompositeObservableProperty instances within the WMO Codes Registry (http://codes.wmo.int/49-2/observable-property ссылка) that may be referenced from data products.

Thus the observed property reference relating to the aggregated set of physical properties that may be observed in a METAR may be found here: http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation ссылка

Observed property
 1. ...
 2.             <om:observedProperty
 3.                 xlink:href="http://codes.wmo.int/49-2/observable-property/MeteorologicalAerodromeObservation"
 4.                 xlink:title="Observed properties for Meteorological Aerodrome Observation Reports (METAR and SPECI)"/>
 5. ...


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:

In each case, the ‘observation’ event relates to some sampling regime that is a proxy for the real entity of interest (e.g. the site of the weather station, or the extent of the forecast domain). The observation or forecast is not directly related to real-world entities.

ISO 19156 ‘Observations and measurements’ provides a conceptual model for describing this layer of indirection: Sampling Features.

A sampling feature is related to the real world via the property <sam:sampledFeature>.

Further specialisations of Sampling Feature are provided based on spatial topology (SF_SpatialSamplingFeature and sub-types thereof).

In all cases identified thus far in meteorology, it appears useful to describe an observation, measurement or forecast with respect to the sampling regime (e.g. the Sampling Feature) and indirectly refer to the real-world entity for which the Sampling Feature is a proxy.

The code fragment below shows the structure of the sampling feature:

Feature of interest
 1. ...
 2.             <om:featureOfInterest>
 3.                 <sams:SF_SpatialSamplingFeature gml:id="sp-LKKV">
 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>...</sams:shape>
 7.                 </sams:SF_SpatialSamplingFeature>
 8.             </om:featureOfInterest>
 9. ...


As required by the MeteorologicalAerodromeObservation class, the spatial sampling feature used here is an instance of SF_SamplingPoint; the METAR observation is considered to occur at some fixed point in space.

Similarly to the XML implementation of sub-classes of OM_Observation, only the generic SF_SpatialSamplingFeature is implemented as an XML element. The <sam:type> element is used to define the sub-class of spatial sampling feature (line 4).

IWXXM relies on rule-based validation to ensure that the correct type of spatial sampling feature is used in this instance.

The element <sam:sampledFeature> in line 5 relates the abstract sampling feature to the the real-world entity that the observation is intended to describe.

A spatial sampling point must always include some geometric information about the sampling regime it characterises. This is provided by the <sams:shape> element (line 6).

The <sam:sampledFeature> is further elaborated in the code-fragment below:

Spatial sampling feature
 1. ...
 2.                     <sam:sampledFeature>
 3.                         <saf:Aerodrome gml:id="uuid.f4ebfc50-b727-11e2-9e96-0800200c9a66">
 4.                             <gml:identifier codeSpace="urn:uuid:">f4ebfc50-b727-11e2-9e96-0800200c9a66</gml:identifier>
 5.                             <saf:designator>LKKV</saf:designator>
 6.                             <saf:name>KARLOVY VARY INTERNATIONAL</saf:name>
 7.                             <saf:locationIndicatorICAO>LKKV</saf:locationIndicatorICAO>
 8.                             <saf:ARP>
 9.                                 <gml:Point gml:id="ref-point-LKKV"
10.                                     uomLabels="deg deg m"
11.                                     axisLabels="Lat Lon Altitude"
12.                                     srsDimension="3"
13.                                     srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
14.                                     <gml:pos>50.20 12.92 606</gml:pos>
15.                                 </gml:Point>
16.                             </saf:ARP>
17.                         </saf:Aerodrome>
18.                     </sam:sampledFeature>
19. ...


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:

GML requires the coordinate reference system in which the geometry is specified to be provided. Attribute srsName (line 13) references an authoritative publication of the EPSG 4326 coordinate reference system which is based on WGS84. Attributes uomLabels (line 10), axisLabels (line 11) and srsDimension (line 12) provide additional information. This means that the values provided within the <gml:pos> element (line 14) can be unambiguously used to geolocate the point.

Each spatial sampling feature must refer to a geometry (e.g. <sams:shape>. In the case of a sampling point the geometry is constrained to be of type <gml:Point>. The sampling point geometry represents the location of the observation (e.g. the location that the observation is pertinent to). Whilst it is commonplace for METAR/SPECI and TAF to use the Aerodrome Reference Point for this purpose, in some cases, the sampling point may differ from the Aerodrome Reference Point.

The code fragment below shows the GML definition of the observation location:

Observation location
 1. ...
 2.                     <sams:shape>
 3.                         <gml:Point gml:id="obs-point-LKKV"
 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.20 12.92 606</gml:pos>
 9.                         </gml:Point>
10.                     </sams:shape>
11. ...



Observation result

The observation result is the main part of this METAR; it provides the data values for the observed properties.

As required by the MeteorologicalAerodromeObservation class, the result is constrained to be an instance of MeteorologicalAerodromeObservationRecord.

MeteorologicalAerodromeObservationRecord has been designed with the explicit intention to allow provision of the information required to meet ICAO Annex 3 / WMO No. 49 Volume 2 regulation.

As with the sampling point, IWXXM relies on rule-based validation (e.g. schematron) to validate this constraint; XML Schema will not enforce this constraint.

However, <iwxxm:MeteorologicalAerodromeObservationRecord> element is specified in XML Schema. As a result, typical XML authoring tools such as oXygenXML ссылка will be able to provide auto-completion and validation to help developers edit METAR instances.

For reference, we recommend reviewing the IWXXM UML model to determine the information that must or may be included in a MeteorologicalAerodromeObservationRecord instance.

The example 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:
Observation result
 1. ...
 2.             <om:result>
 3.                 <iwxxm:MeteorologicalAerodromeObservationRecord cloudAndVisibilityOK="false"
 4.                     gml:id="observation-record-LKKV-20070725T12Z">
 5.                     <iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature>
 6.                     <iwxxm:dewpointTemperature uom="Cel">10</iwxxm:dewpointTemperature>
 7.                     <iwxxm:qnh uom="hPa">1010</iwxxm:qnh>
 8.                     <iwxxm:surfaceWind>
 9.                         <iwxxm:AerodromeSurfaceWind variableDirection="false">
10.                             <iwxxm:meanWindDirection uom="deg">210</iwxxm:meanWindDirection>
11.                             <iwxxm:meanWindSpeed uom="m/s">2.6</iwxxm:meanWindSpeed>
12.                         </iwxxm:AerodromeSurfaceWind>
13.                     </iwxxm:surfaceWind>
14.                     <iwxxm:presentWeather
15.                         xlink:href="http://codes.wmo.int/306/4678/VCSH"
16.                         xlink:title="Showers (in vicinity)"/>
17.                     <iwxxm:recentWeather
18.                         xlink:href="http://codes.wmo.int/306/4678/TS"
19.                         xlink:title="Thunderstorm"/>
20.                     <iwxxm:runwayState>
21.                         <iwxxm:AerodromeRunwayState>
22.                             <iwxxm:depositType
23.                                 xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1"
24.                                 xlink:title="Damp"/>
25.                         </iwxxm:AerodromeRunwayState>
26.                     </iwxxm:runwayState>
27.                 </iwxxm:MeteorologicalAerodromeObservationRecord>
28.             </om:result>
29. ...


Looking in detail at the result we see:

Line 3 (CAVOK)

CAVOK
...
                cloudAndVisibilityOK="false"
...



Line 5 (Air temperature)


Air temperature
...
                <iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature>
...



<iwxxm:airTemperature> definition

It is worth understanding a little more about the definition of the <iwxxm:airTemperature> element. Within the UML model, the property airTemperature is annotated with tagged value "quantity" which refers to the authoritative semantic definition of "air temperature" as specified by WMO: http://codes.wmo.int/common/c-15/me/airTemperature ссылка
Degree Celsius definition

A definition of "Degree Celsius" is provided by the Unified Code for the Units of Measure (UCUM) ссылка. However, WMO also publishes a list of the permitted units of measure: WMO No. 306 Vol 2 Common code-table C-6. This is published online at http://codes.wmo.int/common/c-6 ссылка.

In the interest of reusing existing definitions, the WMO Codes register cites the definition from QUDT (Quantities, Units, Dimensions and Data Types; maintained within the NASA AMES Research Center): http://qudt.org/vocab/unit#DegreeCelsius ссылка. QUDT provides a machine-readable definition of "Degree Celsius" in RDF.

Furthermore, the WMO Codes Registry provides supplemental information about the "Degree Celsius", including a description, the appropriate UCUM symbol, the WMO abbreviations from Common code-table C-6 (e.g. IA5, IA2) and the offset and multiplier required to convert values to other temperature units.

Lines 6-7 (Dew-point temperature and QNH)

Dew-point temperature, QNH
...
                <iwxxm:dewpointTemperature uom="Cel">10</iwxxm:dewpointTemperature>
                <iwxxm:qnh uom="hPa">1010</iwxxm:qnh>
...



Lines 8-13 (Surface wind)


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>
...



Lines 14-19 (Present and recent weather)


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"/>
...


Lines 20-26 (Runway state)


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> 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: