guidelines for data modeling for wmo codeswgds/...manual-codes-mo… · web viewdata modeling for...

CBS-Ext.(2014)-Doc 2.3(2) Annex B – Approved

DRAFT: Guidelines on Data Modelling for WMO Codes. of 168

GUIDELINES ON DATA MODELLING FOR WMO CODES

ContentsGuidelines on Data Modelling for WMO Codes.................................................................................1

1 Introduction...................................................................................................................................98

1.1 Context..............................................................................................................................98

1.2 History................................................................................................................................98

1.3 Data Modeling and WMO Governance..............................................................................98

1.4 Overview..........................................................................................................................109

1.5 Reference standards.......................................................................................................109

1.6 Special role of the Observations and Measurements Model in WMO Data Modeling...1110

2 Modèle pour l’Échange des Informations sur le Temps, le Climate et l’Éau (METCE).............1211

2.1 Purpose and use of METCE..........................................................................................1211

2.2 Observation/Forecast Types Defined in METCE...........................................................1211

2.2.1 ComplexSamplingMeasurement................................................................................1211

2.2.2 SamplingCoverageMeasurement..............................................................................1312

2.2.3 SamplingObservation.................................................................................................1312

2.2.4 Notes on observation/forecast types..........................................................................1312

2.3 Data Model for Meteorological Phenomena..................................................................1413

2.4 Data Model for Procedures............................................................................................1413

2.5 Location of class definitions and context diagrams for METCE....................................1413

3 Observable Property Model......................................................................................................1614

3.1 Purpose and use of OPM..............................................................................................1614

3.1.1 Parameter aggregation and CompositeObservableProperty.....................................1614

3.1.2 Parameter qualification and QualifiedObservableProperty........................................1614



3.2 Location of class definitions and context diagrams for OPM.........................................1715

4 Development of new data representations with METCE and OPM.........................................1816

4.1 UML notation.................................................................................................................1816

4.2 Overall considerations...................................................................................................2018

4.3 The application of O&M properties to WMO data modeling..........................................2119

4.3.1 om:phenomenonTime................................................................................................2119

4.3.2 om:resultTime............................................................................................................2119

4.3.3 om:validTime..............................................................................................................2220

4.3.4 Examples and times...................................................................................................2220

4.3.5 om:resultQuality.........................................................................................................2220

4.3.6 om:procedure.............................................................................................................2220

4.3.7 om:observedProperty.................................................................................................2321

4.3.8 om:featureOfInterest..................................................................................................2321

4.3.9 om:result....................................................................................................................2321

4.3.10 om:metadata..............................................................................................................2321

4.3.11 om:relatedObservation...............................................................................................2421

4.3.12 om:parameter.............................................................................................................2422

4.3.13 om:type......................................................................................................................2422

4.4 Strong typing versus weak typing..................................................................................2522

4.4.1 Advantages and disadvantages.................................................................................2523

4.4.2 An example of strong typing......................................................................................2623

4.4.3 An example of weak typing........................................................................................2725

4.5 Methods for generating data representations from UML...............................................2825

5 The WMO Registry and its use.................................................................................................2926

5.1 Overview of the WMO Registry.....................................................................................2926



5.2 Parameter references and the WMO Registry..............................................................2926

5.3 Code lists and the WMO Registry.................................................................................3027

5.4 Regional Extensions to the WMO Registry...................................................................3128

6 References................................................................................................................................3229

Annex A: Abridged class definitions and context diagrams for METCE.....................................3330

A.1 Introduction....................................................................................................................3330

A.2 Meteorological Phenomena...........................................................................................3330

A.2.1 EruptingVolcano.........................................................................................................3431

A.2.2 Volcano......................................................................................................................3431

A.2.3 TropicalCyclone.........................................................................................................3633

A.3 Observation and Measurement Types..........................................................................3734

A.3.1 ComplexSamplingMeasurement................................................................................3935

A.3.2 SamplingCoverageMeasurement..............................................................................4036

A.3.3 SamplingObservation.................................................................................................4238

A.4 Procedure......................................................................................................................4339

A.4.1 MeasurementContext.................................................................................................4339

A.4.2 Process......................................................................................................................4641

A.4.3 RangeBounds............................................................................................................4843

Annex B: Abridged class definitions and context diagrams for observable properties model (OPM).....................................................................................................................................................4945

B.1 Introduction....................................................................................................................4945

B.2 Classes..........................................................................................................................4945

B.2.1 CompositeObservableProperty..................................................................................5147

B.2.2 AbstractObservableProperty......................................................................................5147

B.2.3 ObservableProperty...................................................................................................5248

B.2.4 QualifiedObservableProperty.....................................................................................5248



B.2.5 StatisticalQualifier......................................................................................................5349

B.2.6 Constraint...................................................................................................................5450

B.2.7 CategoryConstraint....................................................................................................5551

B.2.8 ScalarConstraint........................................................................................................5551

B.2.9 RangeConstraint........................................................................................................5652

B.2.10 ComparisonOperator.................................................................................................5753

B.2.11 RangeBounds............................................................................................................5853

B.2.12 StatisticalFunctionCode.............................................................................................5854

Annex C: Abridged class definitions and context diagrams for Simple Aeronautical Features (SAF).....................................................................................................................................................6056

C.1 Introduction..............................................................................................................6056

C.2 Features...................................................................................................................6056

C.2.1 Aerodrome..............................................................................................................6056

C.2.2 Airspace..................................................................................................................6460

C.2.3 AirspaceVolume......................................................................................................6762

C.2.4 Runway...................................................................................................................6762

C.2.5 RunwayDirection.....................................................................................................6863

C.2.6 Service....................................................................................................................6964

C.2.7 Unit.........................................................................................................................7166

C.3 Data Types..............................................................................................................7266

C.3.1 CodeAirportHeliportDesignatorType.......................................................................7267

C.3.2 CodeAirspaceDesignatorType................................................................................7368

C.3.3 CodeAirspaceType.................................................................................................7368

C.3.4 CodeFlightDestinationType....................................................................................7570

C.3.5 CodeIATAType.......................................................................................................7671

C.3.6 CodeICAOType......................................................................................................7671



C.3.7 CodeOrganisationDesignatorType.........................................................................7671

C.3.8 CodeUnitType.........................................................................................................7772

C.3.9 CodeVerticalReferenceType...................................................................................7772

C.3.10 TextDesignatorType.............................................................................................7873

C.3.11 TextNameType.....................................................................................................7873

C.4 Measures.................................................................................................................7974

C.4.1 DistanceWithNilReason..........................................................................................8074

C.4.2 LengthWithNilReason.............................................................................................8075

Annex D: abridged class definitions and context diagrams for the icao meteorological information exchange model (IWXxm), metar and speci................................................................................8176

D.1 Introduction....................................................................................................................8176

D.2 The METAR and SPECI leaf of IWXXM........................................................................8176

D.2.1 MeteorologicalAerodromeObservationReport............................................................8176

D.2.2 METAR......................................................................................................................8378

D.2.3 SPECI........................................................................................................................8479

D.2.4 MeteorologicalAerodromeObservation......................................................................8579

D.2.5 MeteorologicalAerodromeObservationRecord...........................................................8782

D.2.6 MeteorologicalAerodromeTrendForecast..................................................................8883

D.2.7 MeteorologicalAerodromeTrendForecastRecord.......................................................9084

D.2.8 AerodromeSurfaceWind.............................................................................................9186

D.2.9 AerodromeHorizontalVisibility....................................................................................9287

D.2.10 AerodromeSeaState..................................................................................................9489

D.2.11 SeaSurfaceState........................................................................................................9590

D.2.12 AerodromeRunwayVisualRange................................................................................9590

D.2.13 VisualRangeTendency...............................................................................................9792

D.2.14 AerodromePresentWeather.......................................................................................9893



D.2.15 AerodromeObservedClouds....................................................................................10095

D.2.16 AerodromeRecentWeather......................................................................................10196

D.2.17 AerodromeWindShear.............................................................................................10297

D.2.18 AerodromeRunwayState..........................................................................................10297

D.2.19 RunwayContamination...........................................................................................106101

D.2.20 RunwayDeposits....................................................................................................106101

D.2.21 MeteorologicalAerodromeReportStatus.................................................................106101

D.2.22 ForecastChangeIndicator.......................................................................................107102

Annex E: Abridged class definitions and context diagrams for the icao meteorological information exchange model (IWXXM), TAF..............................................................................................109103

E.1 Introduction................................................................................................................109103

E.2 2 The TAF leaf of IWXXM..............................................................................109103

E.2.1 TAF.....................................................................................................................109103

E.2.2 MeteorologicalAerodromeForecast.....................................................................113107

E.2.3 MeteorologicalAerodromeForecastRecord.........................................................114108

E.2.4 TAFReportStatus................................................................................................117110

E.2.5 AerodromeForecastChangeIndicator..................................................................117111

E.2.6 AerodromeAirTemperatureForecast...................................................................121114

Annex F: Abridged class definitions and context diagrams for the ICAO Meteorological Information Exchange Model (IWXXM), SIGMET.......................................................................................123117

F.1 Introduction................................................................................................................123117

F.2 The SIGMET Lleaf of IWXXM..............................................................................123117

F.2.1 SIGMET..............................................................................................................123117

F.2.2 TropicalCycloneSIGMET.....................................................................................129123

F.2.3 VolcanicAshSIGMET...........................................................................................129123

F.2.4 SIGMETEvolvingConditionAnalysis....................................................................130123



F.2.5 EvolvingMeteorologicalCondition........................................................................132126

F.2.6 SIGMETPositionAnalysis....................................................................................133127

F.2.7 MeteorologicalPositionCollection........................................................................135128

F.2.8 MeteorologicalPosition........................................................................................135129

F.2.9 ExpectedIntensityChange...................................................................................136129

F.2.10 SIGMETReportStatus.......................................................................................136130

F.2.11 AeronauticalSignificantWeatherPhenomenon...................................................137131

Annex G: Abridged class definitions and context diagrams for the ICAO Meteorological Information Exchange Model (IWXXM), Common...................................................................138132

G.1 Introduction................................................................................................................138132

G.2 The Common leaf of IWXXM...............................................................................138132

G.2.1 AerodromeCloudForecast..................................................................................138132

G.2.2 CloudLayer.........................................................................................................140134

G.2.3 CloudAmountReportedAtAerodrome..................................................................140134

G.2.4 SigConvectiveCloudType...................................................................................141134

G.2.5 AerodromeSurfaceWindTrendForecast..............................................................141135

G.2.6 AerodromeSurfaceWindForecast.......................................................................143137

G.2.7 AerodromeForecastWeather..............................................................................143137

G.2.8 RelationalOperator.............................................................................................145139

Annex H: Methods for generating data representations from Universal Modelling Language (UML).................................................................................................................................................147141

H.1 Introduction................................................................................................................147141

Overview of serialization procedure from Application Schema (UML) to GML Schema (XML Schema)...............................................................................................................................148142

Introduction...........................................................................................................................148142

Pre-requisites.......................................................................................................................148142

Procedures...........................................................................................................................148142



Recommended Text.............................................................................................................152146

Annex H Appendix A: UML Stereotypes and Tagged Values for GML Application Schemas..............................................................................................................................................153147

Summary of GML stereotypes..............................................................................................153147

ISO GML stereotypes and associated tagged values..........................................................155149

METCE GML stereotypes and associated tagged values....................................................159153



1 INTRODUCTION1.1 Context

The word codes is used in many different contexts within the work of the WMO. There are lists of values named “code lists,” and multi-page documents that describe “code forms” (binary and alphanumeric) for data interchange. The matter is further complicated by the term “source code” for computer software. The title of this document refers to “WMO codes,” and it is intended to have two meanings. First, this document explains the strategies applied to create data models for a handful of important Traditional Alphanumeric Codes (TAC). Second, this document explains strategies that can be used as data modellers create entirely new data representations.

1.2 History

In July 2011, the WMO’s Commission for Basic Systems’ Management Group (CBS-MG) created the Task Team on Aviation XML (TT-AvXML) at its twelfth meeting. TT-AvXML was “to harmonize with ICAO an XML representation of weather data that could be used within the aviation community.” In accordance with its terms of reference, the team chose a data modelling approach that would “allow consistency with the emerging WMO data model...and allow consistent evolution alongside other WMO data representations…”

It was urgent for TT-AvXML to produce specifications of Geography Markup Language (GML)/eXtensible Markup Language (XML) schemas for the encoding of four key TAC forms. These code forms were METAR, SPECI, TAF, and SIGMET. ICAO needed these schemas to support Amendment 76 to ICAO Annex 3 – Meteorological Service for International Air Navigation. Specifically, Amendment 76 enabled "States in a position to do so" to disseminate these products "formatted in accordance with a globally interoperable information exchange model" that would "use extensible markup language (XML)/geography markup language (GML)."

Rather than create XML schemas directly, TT-AvXML chose to follow industry best practices and first create its data model within Unified Modeling Language (UML) and then generate XML schemas automatically using a defined set of rules. The Task Team also chose to establish a codes registry to host authoritative terms from WMO technical regulations as web-accessible resources that could be referenced from within these new data products.

1.3 Data Modeling and WMO Governance

The WMO has played a strong role in codifying weather, water, and climate concepts and procedures as well as developing data representations. This work has enabled the WMO to successfully facilitate the free and unrestricted exchange of products and services in real-time and near-real time with strong governance for decades. The code tables that form the underpinning of the WMO’s Table-Driven Code Forms (TDCF; e.g., GRIB and BUFR) have been called the WMO’s “crown jewels.” Decades of expert effort have established authoritative terminologies that describe phenomena in these domains.



The data models described herein have been built upon many of these same concepts. The generic classes presented here are intended to be useful across the regimes governed by the WMO and other regimes. While the WMO governs the classes contained in these data models, many useful definitions are imported from various reference models governed by the International Organization for Standardization (ISO) Technical Committee 211 (TC211). Developers have drawn inspiration from WMO TDCFs for much of this work.

1.4 Overview

This document is intended to guide people who want to create data representations. Most of the examples used here come from the four TAC that were modelled in AvXML. We offer these models as examples of best practice. Moreover, we hope that many readers will learn and understand more readily because they are familiar with TAC. Sections 2 and 3 introduce the METCE and OPM models, respectively. These are foundational tools for WMO data modelling. Section 4 provides substantial detail about the data modelling process. This includes an important discussion about the various properties of the Observation and Measurements model and how it can be applied to WMO domains. Section 5 introduces the WMO Codes Registry, another useful tool for WMO data modellers. Annexes A through G document METCE, OPM, and IWXXM in considerable detail. The reader should note that the information available in Annexes A through G is also available online. Moreover, the online versions are superior to the print versions. These annexes contain context diagrams and descriptive tables. Annex H documents the techniques used to create XML schemas from the AvXML model.

1.5 Reference standards

The following data models have all been useful in modelling WMO codes:

ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and times

ISO 19109:2005, Geographic information – Rules for application schema

ISO 19136:2007, Geographic information – Geography Markup Language (GML)

ISO/TS 19139:2007, Geographic information – Metadata – XML schema implementation

ISO 19156:2011, Geographic information – Observations and measurements

ISO/IEC 19757-3:2006 Information technology – Document Schema Definition Language (DSDL) – Part 3: Rule-based validation – Schematron

OGC/IS 10-025r1 Observations and measurements v2.0 – XML implementation

OGC/IS 08-094r1 SWE Common Data Model



W3C XMLName, Namespaces in XML. W3C Recommendation (14 January 1999)

W3C XMLSchema-1, XML Schema Part 1: Structures. W3C Recommendation (2 May 2001)

W3C XMLSchema-2, XML Schema Part 2: Datatypes. W3C Recommendation (2 May 2001)

W3C XML, Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation (6 October 2000)

W3C XLink, XML Linking Language (XLink) Version 1.1. W3C Recommendation (6 May 2010)

1.6 Special role of the Observations and Measurements Model in WMO Data Modeling

WMO data models are built on the foundation provided by ISO 19156:2011 "Geographic information — Observations and measurements" (O&M). O&M models many useful concepts and organises them into classes that complement and support the development of WMO codes. As the originator of this ISO standard, the Open Geospatial Consortium (OGC) has published a "sister document" named Topic 20: Observations and Measurements. OGC Topic 20 contains much of the information of ISO 19156:2011, supplemental material, and an XML implementation.

By far, the portion of O&M that is most relevant to modelling WMO codes is the class named OM_Observation.

OM_Observation is remarkably well suited to the representation of WMO codes. Despite its name, O&M supports both observations and forecasts of weather, water, and climate. The OM_Observation class provides a framework to describe the event of an observation or measurement. In O&M, an observation is defined as an event that results in an 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 also provides a mechanism to capture quality information about the result and arbitrary parameters concerning the observation event. OM_Observation includes three different time attributes. The phenomenon time is the time that the result applies to the property of the feature of interest. The result time is the time when the result became available. The valid time is the period during which the result is intended to be used.

OM_Observation allows one to describe arbitrarily complex procedures. It can describe the measurement of air temperature using a particular type of thermometer, and it can describe intensive numerical simulations. Many forms of observations are represented using WMO code forms. O&M provides a framework that can support them all.

Note: Some of the terminology (in particular, result time, phenomenon time, valid time) established in O&M differs from and conflicts with terminology previously established in WMO publications.



2 MODÈLE POUR L’ÉCHANGE DES INFORMATIONS SUR LE TEMPS, LE CLIMATE ET L’ÉAU (METCE)

The Modèle pour l’Échange des Informations sur le Temps, le Climate et l’Éau (METCE) is a Logical Data Model (LDM) that was developed to work within the O&M framework and support WMO domains. In English, METCE may also be known as the "METeorological Community Exchange" model. The classes and concepts found in METCE will be especially useful to those who are developing data models for pre-existing Traditional Alphanumeric Codes (TAC) and Table-Driven Code Forms (TDCF). METCE will serve equally well developing new data representations.

2.1 Purpose and use of METCE

METCE provides an information framework that will be useful when applying O&M to the task of modelling WMO codes. It contains three parts.

The first part of METCE is a series of definitions of observation/forecast types. In this context, the word type refers explicitly to the optional type sub-element defined in the OGC project document named “Observations and Measurements – XML Implementation” (OMXML; OGC 10-025r1). These types are defined authoritatively by the WMO Registry (http://codes.wmo.int). An initial set of types has been defined, at this writing, and they are described below.

The second part of METCE is a data model for certain meteorological phenomena. Version 1.10 (namespace http://def.wmo.int/metce/2013) of METCE currently contains a limited number of features (e.g. volcano and tropical cyclone) that were required to model METAR, SPECI, TAF, and SIGMET. There are many other features, however, that can be modelled in this way. They will likely be added as a part of subsequent releases.

The third part of METCE includes a data model for procedures. This is a concrete implementation of the OM_Process class found in O&M.

The METCE application schema will typically be imported to provide a baseline conceptual model framework upon which community-specific application schema can be built.

2.2 Observation/Forecast Types Defined in METCE

The UML data model for METCE (See Annex A, below.) clearly illustrates the structure and intended uses for the observation/forecast types. The types are named metce:Sampling-Observation, metce: ComplexSamplingMeasurement, and metce:SamplingCoverageMeasurement. All three types are specialisations of O&M. All three are formed by limiting options for om:result, om: featureOfInterest, and/or om:process.



2.2.1 ComplexSamplingMeasurement

ComplexSamplingMeasurement (a subclass of OM_ComplexObservation) should be used when a single observation event evaluates multiple parameters. Examples include a set of measurements taken by instruments mounted on a tower and a forecast of rainfall and wind speed at an aerodrome. It imposes the following three constraints: 1) the result (om:result) is a Record, as defined in ISO 19103; 2) the feature of interest (om: featureOfInterest) belongs to the class SF_SpatialSamplingFeature, as defined in O&M, or to a subclass of SF_SpatialSamplingFeature; and 3) the procedure (om:procedure) belongs to the class Process, as defined in METCE, or to a subclass of Process. The OM_ComplexObservation is used because the result of this class is a group of measures, provided as a Record. Again, this matches many WMO application domains where multiple phenomena are measured or forecast simultaneously as a single observation event.

2.2.2 SamplingCoverageMeasurement

SamplingCoverageMeasurement (a subclass of OM_DiscreteCoverageObservation) should be used when the observation/forecast event evaluates parameters that vary over space and/or time. Examples include sea surface temperatures from a drifting buoy and a forecast grid from a Numerical Weather Prediction (NWP) system. It imposes the following three constraints: 1) the result (om:result) is a discrete coverage (CV_ DiscreteCoverage), as defined in ISO 19123; 2) the feature of interest (om:featureOfInterest) belongs to the class SF_SpatialSamplingFeature, as defined in O&M, or to a subclass of SF_SpatialSamplingFeature; and 3) the procedure (om:procedure) belongs to the class Process, as defined in METCE, or to a subclass of Process.

2.2.3 SamplingObservation

SamplingObservation (a subclass of OM_Observation) provides a general purpose observation/forecast type. It imposes only two constraints: 1) the feature of interest (om: feature-OfInterest) belongs to the class SF_SpatialSamplingFeature, as defined in O&M, or to a subclass of SF_SpatialSamplingFeature; and 2) the procedure (om:procedure) belongs to the class Process, as defined in METCE, or to a subclass of Process. SamplingObservation is especially well suited to applications where the result of the observation/forecast (om:result) is not a number. E.g., IWXXM uses this observation/forecast type to model the aviation product named SIGMET. A SIGMET warns pilots of dangerous weather conditions over specific regions of airspace and spans of time. Of course, SamplingObservation can also support numerical observations/forecasts, i.e., a river gage reading.

2.2.4 Notes on observation/forecast types

Developers who want to use these various METCE types will need to choose among them. For those observations and forecasts where the result is expected to vary over space and time, SamplingCoverageMeasurement is the only suitable option. If the result is confined to a single point in space and a single moment in time, then SamplingObservation and ComplexSampling-Measurement are possibilities. One should choose between these two types by considering the number of parameters that will be evaluated. ComplexSamplingMeasurement records multiple parameters in a Record. SamplingObservation imposes no constraints on the results, making it the most flexible (least constrained).



It is notable that all three METCE observation/forecast types require the feature of interest to be a member of the class SF_SpatialSamplingFeature or a subclass of SF_SpatialSamplingFeature. SF_SpatialSamplingFeature is especially well-suited to the domains of interest to the WMO. Measurements from a set of instruments mounted at a fixed point on the earth’s surface can be modelled with a combination of SF_SpatialSamplingFeature and GM_Point. Observations from a moving platform, i.e. an aircraft or ship or weather balloon, can be modelled with a combination of SF_SpatialSamplingFeature and GM_Curve. In these cases, we generally seek information about large expanses of atmosphere or ocean, but our observations sample a small fraction of the domain.

There are use cases, however, in the WMO domains of interest where the notion of sampling is not appropriate. A weather service may issue a warning for some form of severe weather that applies to an entire geopolitical region. The basin-average precipitation accumulation could be observed, analysed, or forecast over a river basin. In these cases, it may not be appropriate to model the feature of interest (om:featureOfInterest) with the class SF_SpatialSamplingFeature. In these instances, the METCE types will not be useful. Rather, the data modeller should use the appropriate GFI_Feature from O&M. These are modelled in XML with the class gml: AbstractFeature.

2.3 Data Model for Meteorological Phenomena

The Data Model for Meteorological Phenomena includes features that play a significant role on meteorology (e.g., volcanoes and tropical cyclones). The phenomena listed in version 1.10 of METCE (namespace http://def.wmo.int/metce/2013) are taken from WMO No. 306 Vol I.2 FM 94 BUFR code-table 0 08 011 “Meteorological Feature.” Code table 0 08 011 includes items such as cold front at the surface, jet stream, mountain wave, and sandstorm. Some or all of these features may be added to the Data Model for Meteorological Phenomena in future releases.

2.4 Data Model for Procedures

The Data Model for Procedures provides a concrete implementation of the abstract OM_Process class (from O&M). The model provides a reference to supporting documentation about the observation/forecast. Typically, this will be a URL that points to a web page that contains documentation. The Data Model for Procedures also contains a number of parameters that describe the measuring process. These include the resolution and the measuring interval of the measurement. Other parameters can be defined and recorded through a soft typing method.

The concept of measuring interval is useful in cases where the smallest and/or largest reported values are determined by some prior agreement or regulation. E.g., aviation regulations (Annex 3 to the Convention on International Aviation) impose a measurement interval of 0 - 10 km on visibilities in the METAR, SPECI, and TAF codes. It is likely that the instruments used to make the measurements can accurately measure visibilities greater than 10 km. Regulation, however, restricts the reported values.



2.5 Location of class definitions and context diagrams for METCE

The authoritative version of the METCE is maintained within IWXXM as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. An abridged version of the METCE class diagrams and context diagrams are provided in Annex A.

http://wis.wmo.int/AvXML/AvXML-1.1/index.htm



3 OBSERVABLE PROPERTY MODELThe Observable Property Model (OPM) was developed within the OGC Sensor Web Enablement Standards Working Group & INSPIRE Thematic Working Groups. By agreement between OGC and WMO, OPM is governed by WMO.

Data modellers can use OPM to aggregate observed physical properties into composite properties (CompositeObservableProperty). OPM also provides the tools needed to explicitly describe any qualifications or constraints imposed upon these physical properties. Finally, OPM allows each physical property to be qualified according to its specific observation context. E.g. within a METAR, the property wind speed is formally defined as the mean wind speed within the 10-minute period preceding the observation.

OPM is not used within the ICAO Meteorological Information Exchange Model (IWXXM). The schema validation needs and strict regulation practices led to a hard-typing approach for IWXXM. OPM is included in this distribution to support the development of other application schemas.

3.1 Purpose and use of OPM

OPM supports two functions--aggregation and constraint.

3.1.1 Parameter aggregation and CompositeObservableProperty

OPM defines a CompositeObservableProperty class that supports the aggregation of observed physical properties into composites. A data publisher may need to use the OPM, if the observation results in the evaluation of multiple parameters, to define each of those individual parameters.

Note that in the case of class Process, there is no constraint on the number of occurrences of a given parameter name. However, recommended practice indicates the use of an instance of Class CompositeObservableProperty where a set of observable properties are to be specified.

3.1.2 Parameter qualification and QualifiedObservableProperty

OPM also defines a QualifiedObservableProperty that supports spatial aggregations, temporal aggregations, statistical functions, and constraints. (Those who are familiar with GRIB2 encoding may note a similarity between OPM’s QualifiedObservableProperty and the concept of “average, accumulation, extreme values or other statistically processed values” found in some Product Definition Templates.)

A data publisher may need to use the OPM to explicitly define any qualification or constraint applied to the observed property. Examples include explicitly declaring the averaging period of a wind observation, representing precipitation accumulation over a period of time, and representing maximum/minimum temperatures.



3.2 Location of class definitions and context diagrams for OPM

The authoritative version of the OPM is maintained within AvXML as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. An abridged version of the OPM class diagrams and context diagrams are provided in Annex B.




4 DEVELOPMENT OF NEW DATA REPRESENTATIONS WITH METCE AND OPM

As stated above, O&M provides a data modelling framework that can support most, if not all, WMO code forms. Moreover, the tools provided by METCE and OPM further support these efforts. WMO data generally fall into three broad categories, i.e., observations, analyses, and forecasts. In this section, we will provide concrete suggestions on applying O&M, METCE, and OPM to these three categories.

Data modellers who are developing new representations of WMO codes are encouraged to build their model first in UML, and then use automated techniques to create one or more data repre-sentations. The use of an abstract data model combined with a software implementation of the data representation provides a great deal of flexibility to organisations. These tools enable a quicker response when technologies evolve. E.g., TT_AvXML chose to use the commercial data modelling tool named Enterprise Architect to build its UML models. (Reference to names of firms and commercial products and process does not imply their endorsement by WMO, and any failure to mention a firm, commercial product or process is not a sign of disapproval.) Then, TT_AvXML used a software package named Fullmoon to convert the UML into XML schemas. If there were a need for other representations (say, JSON), additional software techniques would be able to generate those new representations from that same UML model.

Data modellers who are developing new representations of WMO codes are also encouraged to maximise use of the WMO Registry, described below, when formulating their data representations. The WMO Registry provides a web-enabled link to the large number of well-defined physical quantities. The combination of OPM and the registry should serve the needs of most WMO data modellers.

4.1 UML notation

UML notation is used freely throughout the annexes of this document, and it may be somewhat unfamiliar to the reader. Figures 1, 2, and 3 are offered here as a much abbreviated introduction to UML class diagrams with a focus on the constructs used elsewhere in this document. See Chapter 3 of UML Distilled (Fowler 2004) for a more thorough introduction to the topic.



Figure 1: UML classes and properties

Figure 2: UML associations



Figure 3: UML composites and generalisations

4.2 Overall considerations

As stated previously, O&M is well-suited to most data modelling tasks for WMO codes. One of the three O&M types defined in METCE will also be useful in most of these applications. The data modeler should consider the following points when planning his/her strategy:

The three METCE types named metce:SamplingObservation, metce: ComplexSampling-Measurement, and metce:SamplingCoverageMeasurement all require the O&M property named om:procedure to be of type metce:Process. If metce:Process is not suitable for the project at hand, then these types should not be used.



The same three METCE types require the O&M property named om:featureOfInterest to be of type SF_SpatialSamplingFeature. If SF_SpatialSamplingFeature is not suitable, then these types should not be used.

The METCE type named metce:ComplexSamplingMeasurement requires the om:result to be of type Record. This enables a single observation/analysis/forecast to contain multiple physical quantities.

The METCE type named metce:SamplingObservation imposes no constraints on the om:result.

The METCE type named metce:SamplingCoverageMeasurement requires the O&M property named om:result to of type CV_DiscreteCoverage.

If one of these three METCE observation types is selected, the O&M element named type should be set, as follows:

<om:type xlink:href=”http://codes.wmo.int/common/observation-type/ METCE/ 2013/ ComplexSamplingMeasurement”><om:type xlink:href=http://codes.wmo.int/common/observation-type/ METCE/ 2013/ SamplingCoverageMeasurement><om:type xlink:href=http://codes.wmo.int/common/observation-type/ METCE/ 2013/ SamplingObservation>

4.3 The application of O&M properties to WMO data modeling

Much of this section will refer to the various O&M properties depicted in Figure 2 of the O&M documentation (The basic Observation type). The reader will benefit if a copy of the figure is available for reference.

4.3.1 om:phenomenonTime

O&M defines phenomenonTime as “the time that the result…applies to the property of the feature-of-interest…” If we are modeling an observation, then this is the time when the physical parameter was observed. If we are modeling an analysis, then this is the time when the analysis applies to the “real world.” If we are modeling a forecast, then this is the time when we expect events will happen. For most earth science applications, we can expect phenomenonTime to be in the past for observations and analyses, and in the future for forecasts.

Because O&M defines phenomenonTime to be of type TM_Object, it can be either an instant in time or a span of time. One and only one phenomenonTime must appear in an OM_Observation.

4.3.2 om:resultTime

O&M defines resultTime as “the time when the result became available.” If we are modeling an observation, then this time may well match the phenomenonTime. If we are modeling an analysis, then is the time when the analysis process completed. If we are modeling a forecast, then this is the time when the forecast became available. We can generally expect resultTime to be in the past.

http://codes.wmo.int/common/observation-type/%E2%80%8CMETCE/%E2%80%8C2013/%E2%80%8C%E2%80%8CSamplingObservation

http://codes.wmo.int/common/observation-type/%E2%80%8CMETCE/%E2%80%8C2013/%E2%80%8C%E2%80%8CSamplingObservation

http://codes.wmo.int/common/observation-type/%E2%80%8CMETCE/%E2%80%8C2013/%E2%80%8C%E2%80%8CSamplingCoverageMeasurement

http://codes.wmo.int/common/observation-type/%E2%80%8CMETCE/%E2%80%8C2013/%E2%80%8C%E2%80%8CSamplingCoverageMeasurement

http://codes.wmo.int/common/observation-type/METCE/2013/ComplexSamplingMeasurement

http://codes.wmo.int/common/observation-type/METCE/2013/ComplexSamplingMeasurement



ResultTime is defined to be of type TM_Instant. Thus, it must be a point in time. One and only one resultTime must appear in an OM_Observation.

4.3.3 om:validTime

Note: The definition of validTime found in O&M differs considerably from the definitions of concepts with similar names found in other WMO documents. Those who produce data within this framework should take special care to help their customers interpret all time concepts correctly.

O&M defines validTime as “the time period during which the result is intended to be used.” It goes on to say that validTime “is commonly required in forecasting applications.”

ValidTime is defined to be of type TM_Period. Thus, it must be a span of time. ValidTime is an optional attribute. It may be omitted. If present, only one instance may appear.

For most earth science applications, validTime will be omitted from observations and analyses. This assumes that observations and analyses are useful for indefinite periods of time.

There are two strategies for validTime that seem appropriate when modeling forecasts. First, we can set validTime to begin with the resultTime and end with the phenomenonTime. I.e., our customers should use our forecast while it is still a forecast. In operational environments, a second strategy may be more useful to customers. We can limit the validTime to a shorter time period that ends when we expect a newer (and, presumably, better) forecast will be available.

4.3.4 Examples and times

WMO code forms are used to represent a number of different observations. When these observations are modelled with OM_Observation, their phenomenon time and result time will be generally be close to each other or identical. When output from a Numerical Weather Prediction (NWP) is modelled with OM_Observation, the result time will represent the time when the NWP simulation ended and the output became available, and the phenomenon time will be a time in the future when the NWP forecast will be valid. When a human generated forecast is modelled with OM_Observation, the result time will represent the time when the forecast was available for use, and the phenomenon time will be a time in the future when conditions are forecast to occur.

4.3.5 om:resultQuality

O&M defines resultQuality simply as describing “the quality of the result.” O&M goes on to note that resultQuality is “instance-specific” and “complements the description.” Information about “the quality of all observations using this procedure” should be modeled in om:procedure. ResultQuality should focus on the quality of the specific observation at hand.

ISO 19157:2011 Geographic Information—Data quality provides a substantial toolset for modelling data quality. ResultQuality is of type DQ_Element. It may be omitted, and more than one DQ_Element may appear.



4.3.6 om:procedure

O&M requires that each observation has one and only one property named procedure. Data modellers have a great deal of flexibility when encoding procedure in an observation. The class specified for procedure is OM_Process. OM_Process, in turn is abstract, lacking attributes, operations, associations.

Simple strategies for encoding procedure include the following: 1) encode a text description of the observing process, 2) encode a text description of a document that describes the observing process, and 3) encode a URL that points to the description.

As noted above, the three WMO observation types (metce:SamplingObservation, metce: Complex-SamplingMeasurement, and metce:SamplingCoverageMeasurement) all require that om:procedure be encoded as metce:Process.

There are other, more complex, strategies available for encoding procedure. ISO 19115-2:2009 “Geographic information—Metadata—Part 2: Extensions for imagery and gridded data” provides the following classes that can be useful for modeling the procedure: MI_Instrument, LE_Processing, and LE_Algorithm. The OGC standard named SensorML includes additional tools.

4.3.7 om:observedProperty

Like procedure, O&M requires that each observation include one and only one instance of observedProperty. Also like procedure, data modellers have substantial flexibility when implementing observedProperty. The class specified for observedProperty is GFI_PropertyType.

Data modellers who are implementing new or existing WMO codes are encouraged to maximize their use of the WMO Registry (See below.) when encoding observedProperty. Many, many observable properties have been catalogued in WMO tables and manuals. Authoritative, web-accessible versions of these tables and manuals are hosted within the registry.

4.3.8 om:featureOfInterest

O&M requires one and only one featureOfInterest, and its type is the general GFI_Feature. For many earth science applications where the feature being observed is a spatial proxy for a real-world feature, the class SF_SpatialSamplingFeature will serve nicely to encode featureOfInterest. As noted above, SF_SpatialSamplingFeature is required for any of the three WMO observation types defined in METCE (metce:SamplingObservation, metce: ComplexSamplingMeasurement, and metce:SamplingCoverageMeasurement).

4.3.9 om:result

O&M requires one and only one result, and it may be of any type. In cases where many physical quantities are observed simultaneously as part of a single observation, the type Record seems appropriate. The METCE type named metce:ComplexSamplingMeasurement requires that result be of type Record or a subclass of Record.



4.3.10 om:metadata

The O&M property named metadata is optional. If it is encoded, only one instance may appear, encoded with the MD_Metadata class found in ISO 19115 “Geographic information—Metadata.”

4.3.11 om:relatedObservation

The O&M property named relatedObservation is optional. It is used to relate one observation to another observation with an attribute that describes the role one plays in understanding the other.

O&M says that “Some observations depend on other observations to provide context…These dependencies are stronger than mere spatiotemporal coincidences…”

4.3.12 om:parameter

O&M provides a mechanism for modeling additional properties with a data type called NamedValue. A NamedValue has two attributes, a generic name called “name” and a “value” of type Any. This gives a great deal of flexibility to the data modeler. Om:parameter should capture event-specific and/or contextual parameters.

It is easy to see how named parameters might be useful in representing WMO codes. The following table was created by considering Product Definition Template (PDT) 4.1 in GRIB2, Individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer at a point in time. For this illustration, assume we are encoding data for a single point that was generated by an Ensemble Forecast System (EFS).

parameter.name Data Type GRIB2 Contents Comments

analysis time TM_Instant reference time Not modeled by existing O&M times.

data cutoff time TM_Instant Hours/minutes after reference time of data cutoff

Not modelled by existing O&M times.

ensemble forecast type

Code table Type of ensemble forecast

Could also be modelled as part of om: procedure.

perturbation number

int Perturbation num-ber



parameter.name Data Type GRIB2 Contents Comments

ensemble size int Number of fore-casts in ensemble

4.3.13 om:type

The element om:type does not appear in the ISO 19156 document. It does appear, however, in OGC’s Topic 20. Thus, it is implemented in the XML schemas. The 2013 version of METCE defined three observation types. They are described above, and they are documented authoritatively at http://codes.wmo.int/common/observation-type/METCE/2013. Additional types, defined by OGC, can be found at http://www.opengis.net/def/observationType/OGC-OM/2.0/.

4.4 Strong typing versus weak typing

Most data modellers can intuitively appreciate the concepts of “strong” and “weak” typing as they apply to data representation. For purposes of this discussion, we propose the following two delineations:

A strongly typed data representation strictly defines the elements that may appear and their data types.

A weakly typed data representation permits considerable flexibility in both elements and data types.

These statements are intended to be informative, not definitive. Practitioners can differ in their evaluation of any given data model. The purpose of this discussion is to inform data modellers of their options, and to provide examples of appropriate applications of each.

Below, we present a small portion of the ICAO Meteorological Information Exchange Model (IWXXM) as an example of a strongly typed data representation. IWXXM was intended to represent a set of four TAC, METAR, SPECI, TAF, and SIGMET. Historically, TACs have been defined strictly. Typical definitions include element order, units of measure, and numerical precision. As IWXXM was developed, ICAO representatives made it clear to the data modellers that the resulting XML schemas should enforce strong data typing. By way of contrast, we will also present an example that encodes the same information using methods of weak typing.

4.4.1 Advantages and disadvantages

Strongly typed data models generally sacrifice flexibility to gain efficiency. If the elements, their order, and their encoding are well known and understood at the time the data representations are modelled, strong typing can produce small, predictable messages. Strongly typed data models are also easier to process since the software only needs to accommodate a limited number of options. Strong typing was a clear choice for IWXXM since it was based on TACs that had seen little change in decades.

http://www.opengis.net/def/observationType/OGC-OM/2.0/

http://codes.wmo.int/common/observation-type/METCE/2013



Data modellers should also consider how data consumers will use the information. E.g., there are few applications that need a latitude value without an accompanying longitude and coordinate reference system. Likewise, most consumers who request a wind direction will also need the associated wind speed. Strong typing strategies help the data modeller “keep things together.”

Conversely, weakly typed data models emphasize flexibility over efficiency. Weak typing strategies are generally favoured in applications where data consumers choose a set of elements from a list at the time the data are requested. Data producers and data consumers must expend additional compute resources to support weakly typed data representations.

The decision on whether to use strong or weak typing in a model is not a single decision. A decision to use strong typing may apply to a complete model, but often the decision to use strong or weak typing is made for each element of the model on its merits.

A complete discussion of trade-offs for strong and weak typing is beyond the scope of this document. There are many other aspects to consider when deciding on whether to use strong or weak typing. Additional discussion points include (among others): where requirements for the model are fixed or highly mutable, whether the model will be extended and managed by others, management of concepts inside vs outside the model (i.e., registries), the importance of verifying correctness of messages, and others.

4.4.2 An example of strong typing

The following fragment of XML schema code has been redactedis taken from from IWXXM:

<complexType name="CloudLayerType"> <sequence> <element name="amount" type="iwxxm:CloudAmountReportedAtAerodromeType"> </element> <element name="base" nillable="true" type="saf:DistanceWithNilReasonType"> <annotation> <appinfo> <quantity> http://codes.wmo.int/common/c-15quantity-kind/heightOfBaseOfCloud </quantity> </appinfo> </annotation> </element> <element maxOccurs="1" minOccurs="0" name="cloudType" type="iwxxm:SigConvectiveCloudTypeType"> </element> </sequence></complexType><complexType name="SigConvectiveCloudTypeType"> <annotation> <appinfo> <vocabulary>http://codes.wmo.int/49-2/SigConvectiveCloudType</vocabulary> <extensibility>none</extensibility> </appinfo> </annotation> <complexContent>



<extension base="gml:ReferenceType"/> </complexContent></complexType><complexType name="CloudAmountReportedAtAerodromeType"> <annotation> <appinfo> <vocabulary> http://codes.wmo.int/49-2/CloudAmountReportedAtAerodrome </vocabulary> <extensibility>none</extensibility> </appinfo> </annotation> <complexContent> <extension base="gml:ReferenceType"/> </complexContent></complexType>

Note that the complex type named CloudLayerType is defined as containing the following three elements: amount, base, and cloudType. Amount and cloud type are further defined as code lists with vocabularies. Base is a quantity, and that is defined too. (Note that the WMO Codes Registry, http://codes.wmo.int, is the source used to define both the quantity named base and the code lists for cloudType and amount. Later sections of the document will elaborate on the registry and its use.)

Here is a code fragment that shows an encoded example of cloudLayerType:

<om:result> <iwxxm:MeteorologicalAerodromeForecastRecord gml:id="base-fcst-record" cloudAndVisibilityOK="false"> <iwxxm:cloud> <iwxxm:AerodromeCloudForecast gml:id="acf1"> <iwxxm:layer> <iwxxm:CloudLayer> <iwxxm:amount xlink:href=http://codes.wmo.int/bufr4/codeflag/0-20-008/3 xlink:title="Broken"/> <iwxxm:base uom="m">600</iwxxm:base> </iwxxm:CloudLayer> </iwxxm:layer> </iwxxm:AerodromeCloudForecast> </iwxxm:cloud> </iwxxm:MeteorologicalAerodromeForecastRecord></om:result>

Note that CloudLayer is encapsulated within layer, AerodromeCloudForecast, cloud, and MeteorologicalAerodromeForecastRecord.

4.4.3 An example of weak typing

The same cloud layer information could also be modelled using weak typing. We will illustrate this case by encoding the same broken cloud layer with a base of 600 meters using SWE Data Record.

<om:result xsi:type=”swe:DataRecordPropertyType”>

http://codes.wmo.int/bufr4/codeflag/0-20-008/3

http://codes.wmo.int/



<swe:DataRecord definition=”record_weather.xml”> <swe:field name=”amount” <swe:Category definition=http://codes.wmo.int/bufr4/codeflag/0-20-008/> <swe:value>Broken</swe:value> </swe:Category> </swe:field> <swe:field name=”base” <swe:Quantity definition=http://codes.wmo.int/common/c-15/heightOfBaseOfCloud http:// codes.wmo.int/common/quantity-kind/heightOfBaseOfCloud> <swe:uom xlink:href=”m”/> <swe:value>600</swe:value> </swe:Quantity> </swe:field> </swe:DataRecord></om:result>

This example only shows the encoding, not a schema. That is because no schemas are explicitly required beyond the schemas defined for O&M and SensorMLSWE Common. Om:result is of data type Any, so the XML shown will validate against the O&M schemas. Note that in this example the cloud amount and height of cloud base are both defined by making reference to the WMO Codes Registry.

4.5 Methods for generating data representations from UML

TT_AvXML spent a substantial level of effort developing a repeatable set of “mostly automated” procedures that successfully generated XML schemas from UML. These procedures were presented at the first meeting of the WMO’s Inter-Programme Expert Team on Metadata and Data Representation Development (IPET-MDRD) as Discussion Paper D24. A subsequent paper, D25, presented information on alternatives to these procedures which were still in development. Both papers can be downloaded from the IPET-MDRD web page at http://wis.wmo.int/page=IPET-MDRD-1. Discussion Paper D24 is included in its entirety here as Annex H. Both papers refer to the process as a “serialization procedure.”

http://wis.wmo.int/page=IPET-MDRD-1

http://wis.wmo.int/page=IPET-MDRD-1

http://codes.wmo.int/common/quantity-kind/heightOfBaseOfCloud%22HYPERLINK%20http://codes.wmo.int/common/c-15/heightOfBaseOfCloud

http://codes.wmo.int/common/quantity-kind/heightOfBaseOfCloud%22HYPERLINK%20http://codes.wmo.int/common/c-15/heightOfBaseOfCloud

http://codes.wmo.int/bufr4/codeflag/0-20-008/



5 THE WMO REGISTRY AND ITS USE5.1 Overview of the WMO Registry

The WMO Codes Registry is the mechanism that publishes the authoritative terms required for WMO AvXML as web-accessible resources. This includes definitions of physical quantities as well as enumerating the values in code and flag tables.

The registry can be accessed at http://codes.wmo.int. This guide will focus on accessing the registry with a web browser using HyperText Transfer Protocol (HTTP). HTTP is the default response. The registry also supports Resource Description Framework (RDF) and Terse RDF Triple Language (“turtle”; TTL).

The WMO Codes Registry was originally implemented to support the exchange of aviation data in eXtensible Markup Language (XML; AvXML). AvXML was designed to use authoritative terms from WMO technical regulation - most notably Manual on Codes (WMO306) - as web-accessible resources.

The registry was originally populated with a small fraction of the entries in WMO306. The WMO plans to increase the number of entries, but this will take considerable time. Fortunately, strong naming conventions allow users to anticipate the Universal Resource Identified (URI) for an item before the registry actually supports it.

The registry has a search feature that allows users to search for entries throughout.

5.2 Parameter references and the WMO Registry

The WMO has defined a wealth of physical quantity kinds in its Table-Driven Code Forms (TDCF). Experts in the weather, water, and climate disciplines have maintained these code lists under strict governance for decades, and they continue to maintain them.

Those who wish to refer to the registry when encoding data will generally make appropriate notations in an XML schema. In the example below, a reference to the registry is encoded with a <quantity> element within the XML Schema <xs:appinfo>. This fragment is extracted from http://schemas.wmo.int/iwxxm/1.0/metarSpeci.xsd http://schemas.wmo.int/iwxxm/1.1/ metarSpeci.xsd. Note the strong typing. The XML attribute airTemperature is explicitly defined.

<element name="airTemperature" type="gml:MeasureType"> <annotation> <appinfo> <quantity>http://codes.wmo.int/common/c-15quantity-kind/airTemperature</quantity> </appinfo> </annotation></element>

The WMO’s Code Table D-2 “Physical quantity kinds”Common Code Table C-15 “Physical Quantities” is supported within the registry at http://codes.wmo.int/common/c-



15 http://codes.wmo.int/common/quantity-kind . This table will support data encoding for a wide variety of weather elements. Other useful tables include BUFR4 Table B at http://codes.wmo.int/bufr4/b and GRIB2 Code and Flag tables at http://codes.wmo.int/grib2/codeflag.

5.3 Code lists and the WMO Registry

The WMO’s TDCFs use a number of code and flag tables. These are also supported within the registry.

As with physical quantities above, those who wish to refer to these portions of the registry when encoding data will generally make appropriate notations in their XML schema. In the example below, a reference to a code table within the registry is encoded with a <vocabulary> element within the XML Schema <xs:appinfo>. (This fragment is also extracted from http://schemas.wmo.int/iwxxm/1.0/metarSpeci.xsd http://schemas.wmo.int/iwxxm/1.1/ metarSpeci.xsd.)

<complexType name="RunwayDepositsType"> <annotation> <appinfo> <vocabulary>http://codes.wmo.int/bufr4/codeflag/0-20-086</vocabulary> <extensibility>none</extensibility> </appinfo> </annotation> <complexContent> <extension base="gml:ReferenceType"/> </complexContent></complexType>

BUFR4 Code Table 0-20-086 is typically used to describe “What’s on the runway?” at an aerodrome. Entries include “wet with water patches,” “dry snow,” “slush,” “ice,” and others.

Note that the URI encoded within the <vocabulary> element refers to BUFR4 Code Table 0-20-086 as a whole and not to a particular entry within that table. Note also the use of an <extensibility> element which can take on the values “narrower”, “any”, or “none”. Extensibility of “none” implies only terms from the specified code list are permitted. Extensibility of "narrower" implies one may use terms with narrower semantics (some, but not all, of the items on the code list), and extensibility of "any" implies that the specified code list is simply a recommendation.

The WMO registry is typically also used to support encoding data in documents. The following XML code fragment indicates slush on the runway. (This fragment is extracted from http://schemas.wmo.int/examples/1.0/iwxxm/Example%20METAR%20(GML)%20LKKV%2020070725T12Z.xml.)

<iwxxm:runwayState> <iwxxm:AerodromeRunwayState> <iwxxm:depositType xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-086/1" xlink:title="Damp"/>

http://codes.wmo.int/grib2/codeflag



</iwxxm:AerodromeRunwayState></iwxxm:runwayState>

A user who follows the URL to the registry will find the description “damp” in multiple languages.

5.4 Regional Extensions to the WMO Registry

The WMO Registry can form the foundation of extended tables hosted by other entities. If an organization needed to use a portion of a table in the registry and add additional values, they would:

Host the new table within their own resources.;

Add the subset of desired entries as references to the WMO Registry;.

Add additional entries hosted within their own resources.



6 REFERENCESFowler, M., 2004: UML Distilled. Third edition. Pearson Education, Incorporated, 175 pages.



ANNEX A: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR METCEA.1 Introduction

The authoritative version of the METCE is maintained within AvXML as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model . (N.B.: There are no whitespace characters in the URL.) What follows is abridged to suit the needs of the print medium.

The Modèle pour l’Échange des Informations sur le Temps, le Climate et l’Éau (METCE) is a Logical Data Model (LDM) that supports the entire scope of WMO concerns: weather, climate and water. In English, it may also be known as the ‘METeorological Community Exchange’ model. The scope of METCE matches the WMO UN mandate, weather, climate, and water, and it complements existing WMO Table-Driven Code Forms (TDCF).

METCE is intended to provide conceptual definitions of meteorological phenomena, entities and concepts in order to underpin semantic interoperability in the weather, climate and water domains. The model includes the following three parts:

A data model for meteorological phenomena that contains a number of meteorological features (i.e., volcano and tropical cyclone)

A data model for observation and measurement types that contains specializations of OM_Observation, OM_ComplexObservation and OM_DiscreteCoverageObservation classes from ISO 19156

A data model for procedures that contains a concrete implementation of OM_Process from ISO 19156

A.2 Meteorological Phenomena

Notes: The package 'Meteorological Phenomena' contains «FeatureType» entities that have a significant role in meteorology; e.g. volcanoes and tropical cyclones.





A list of meteorological phenomena are provided in WMO No. 306 Vol I.2 FM 94 BUFR code-table 0 08 011 'Meteorological Feature' (see below). It is anticipated that in future releases the additional meteorological features listed therein will be incorporated.

A.2.1 EruptingVolcano

Type: Class.

Notes: A volcano that is currently erupting, or has recently erupted, that is the source of volcanic ash or other significant meteorological phenomena described in operational weather reports.

Attribute Multi-plicity

Type Notes

eruptionDate [1] DateTime The date of eruption for the volcano.

A.2.2 Volcano

Type: Class.

Notes: A volcano irrespective of the volcano's current state (e.g. passive or erupting).

Note that the "Global Volcanism Program" provides an online, searchable catalogue of volcanoes which may assist in identifying the authoritative name for a given volcano feature [http://www.volcano.si.edu/world/]. (informative)




Type Notes

name [1] CharacterString The name of the volcano.

position [1] GM_Point The position of the volcano.



A.2.3 TropicalCyclone

Type: Class.



Notes: Cyclone of tropical origin of small diameter (some hundreds of kilometres) with minimum surface pressure in some cases less than 900 hPa, very violent winds and torrential rain; sometimes accompanied by thunderstorms. It usually contains a central region, known as the “eye” of the storm, with a diameter of the order of some tens of kilometres, and with light winds and more or less lightly clouded sky.

WMO No. 306 Vol I.1 code-table 3704 "Shape and definition of the eye of the tropical cyclone" and WMO No. 306 Vol I.1 code-table 3790 "Intensity of the tropical cyclone" provide additional candidate attributes that may be incorporated within this «FeatureType» in subsequent versions of METCE.


Type Notes

name [1] CharacterString Name of tropical cyclone.



A.3 Observation and Measurement Types

Notes: ISO 19156 ‘Observations and measurements’ provides a conceptual schema for observations and the features involved in sampling when making observations, and specifically designed to support the exchange of information describing both the observing event and the results of the observation between different scientific and technical communities.

Whilst the name of the model invokes a particular concept to meteorologists (e.g. ‘observation’, the measurement of physical phenomena with an instrument or sensor – disjoint from the concept of ‘forecast’) it is important to consider the semantics of the model. The class OM_Observation is defined as ‘an estimate of the value of some property of some Thing using some specified Process’. The process may be an instrument/sensor (directly) measuring some physical parameter or a numerical simulation predicting future values. Thus the ‘Observations and measurements’ conceptual model may be used to represent both observations and forecasts.

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; or

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

Spatial Sampling Features are considered an essential part of METCE: all observations, measurements and forecasts of meteorological phenomena shall define the ‘featureOfInterest’ as a concrete sub-type of SF_SpatialSamplingFeature.



Class 'OM_Process' (related to OM_Observation via the 'Procedure' Association) is used to define the process(es) involved in generating an observation. In order to ensure a consistent implementation of the abstract OM_Process class, *ALL* Application Schema based on METCE shall use the Process class defined therein (or sub-class thereof) to describe the observation procedure.

METCE provides three specialised types of OM_Observation; each of which enforce the constraints that 'featureOfInterest' shall refer to an entity of type SF_SpatialSamplingFeature (from ISO 19156), or subclass thereof, and 'procedure' shall refer to an entity of type Process (from METCE), or subclass thereof.

SamplingObservation: subclass of OM_Observation providing a general purpose observation type;

ComplexSamplingMeasurement: subclass of OM_ComplexObservation for use where the observation event is concerned with the evaluation of multiple measurands at a specified location and time instant or duration - the result of this observation type shall refer to an entity of type Record (from ISO 19103), or subclass thereof; and

SamplingCoverageMeasurement: subclass of OM_DiscreteCoverageObservation for use where the observation is concerned with the evaluation of measurands that vary with respect to space and/or time - the result of this observation type shall refer to an entity of type CV_DiscreteCoverage (from ISO 19123).

A.3.1 ComplexSamplingMeasurement

Type: Class.

Notes: Class ComplexSamplingMeasurement (a subclass of OM_ComplexObservation) is intended for use where the observation event is concerned with the evaluation of multiple measurands at a specified location and time instant or duration. The result of this observation type shall refer to an entity of metatype Record (from ISO 19103).

ComplexSamplingMeasurement enforces the following additional constraints:

'featureOfInterest' shall refer to an entity of type SF_SpatialSamplingFeature (from ISO 19156), or subclass thereof; and



'procedure' shall refer to an entity of type Process (from METCE), or subclass thereof

The OM_ComplexObservation is used because the 'result' of this class of observations is a group of measures, provided as a Record. Again, this matches the WMO application domain wherein multiple phenomena are measured within a single 'observation event'.

The term ‘measurement’ is used in the name in an attempt to reduce confusion arising from the overloading of the term ‘observation’.

A.3.2 SamplingCoverageMeasurement

Type: Class.



Notes: Class SamplingCoverageMeasurement (a subclass of OM_DiscreteCoverageObservation) is intended for use where the observation is concerned with the evaluation of measurands that vary with respect to space and/or time - the result of this observation type shall refer to an entity of type CV_DiscreteCoverage (from ISO 19123).

ComplexSamplingMeasurement enforces the following additional constraints:



A critical concern of meteorology is the understanding of the variation of physical phenomena with either space and/or time. This is exactly what the Coverage model is designed to convey.

Coverages are defined in 2 distinct categories: Discrete and Continuous. The main difference is that Continuous coverages provide an interpolation function to evaluate the phenomena at any point within the coverage domain, which Discrete coverages do not. A Discrete coverage is comprised of a number of domain elements (e.g. discrete locations where the phenomenon is sampled) and the associated range elements (e.g. the data). Where the phenomena are considered to be continuously varying within the Coverage domain, a user may apply their own interpolation algorithm as meets their specific requirement.

When describing properties that vary in space and/or time, METCE shall make exclusive use only of Discrete coverages.

The Class ‘SamplingCoverageMeasurement’ is based on the SamplingCoverageObservation which is defined in an informative annex of ISO 19156. However, the term ‘measurement’ is used in the name in an attempt to reduce confusion arising from the overloading of the term ‘observation’.



A.3.3 SamplingObservation

Type: Class.

Notes: Class SamplingObservation (a subclass of OM_Observation) provides a general purpose observation type.

It enforces the following additional constraints:



SamplingObservation is intended for use where measurement of physical phenomena is not the goal of the procedure. For example, the procedure executed to define SIGMET reports results in the identification of areas of turbulence, icing or other meteorological phenomena.



A.4 Procedure

Notes: The 'Procedure' package provides a concrete implementation of the abstract OM_Process class (from ISO 19156).

A.4.1 MeasurementContext

Type: Class.

Notes: Instances of the class 'MeasurementContext' specify the resolution [1] and measuring interval [2] for a given physical property in the context of this measurement procedure.




Type Notes

measurand [1] ObservableProperty The attribute 'measurand' [1] specifies the physical property that the associated 'resolution' and 'measuring interval' apply to.

The measurand may be sourced from an external controlled vocabulary, thesaurus or ontology or defined locally.

The measurand may reference a qualified observable property if required.

If the measurand references an observable physical property that serves as the base property for a qualified observable property, the measurement context is assumed to apply to ALL the qualified observable properties that reference this base property unless otherwise stated. For example, observable physical property 'radiance' may be qualified to measure wavelength bands 50-100nm, 100-200nm, 200-500nm etc. A measurement context associated with 'radiance' would be inferred to apply to all of these qualified radiance properties.

[1] Measurand: quantity intended to be measured (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf]

measuringInterval [0..1] RangeBounds The attribute 'measuringInterval' [1] specifies the extreme lower and upper limits of




Type Notes

property values of the 'measurand' that can measured within this procedure, using the unit of measure 'uom'.

[1] Measuring interval: set of values of quantities of the same kind that can be measured by a given measuring instrument or measuring system with specified instrumental uncertainty, under defined conditions (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf])

resolutionScale [0..1] Integer The attribute 'resolutionScale' specifies the smallest change (e.g. the 'resolution' [1]) in property value of the 'measurand' that is intended to be measured within this procedure, using the unit of measure 'uom'.

This shall be provided as a scaling factor.

For example:scale = -2 implies a precision of 100 unitsscale = -1 implies a precision of 10 unitsscale = 0 implies a precision of 1 unitscale = 1 implies a precision of 0.1 unitsscale = 2 implies a precision of 0.01 unitsetc.




Type Notes

[1] Resolution: smallest change in a quantity being measured that causes a perceptible change in the corresponding indication (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf])

unitOfMeasure [0..1] UnitOfMeasure The attribute 'uom' specifies the unit of measure that the values of 'resolution' and 'measuring interval' are specified in.

Typically, this will also be the unit of measure used to specify the measured quantity values. Unless otherwise specified, this unit of measure can be assumed to be the default unit of measure for this measurand.

A.4.2 Process

Type: Class.

Notes: Class 'OM_Process' (related to OM_Observation via the 'Procedure' Association) is used to define the process(es) involved in generating an observation. An instance of OM_Process is often an instrument or sensor (perhaps even a sensor in a given calibrated state), but it may be a human observer executing a set of instructions, a simulator or process algorithm. The 'Procedure' should provide sufficient information to interpret the result of an observation; thus if a sensor is recalibrated or its height above local ground is changed, a new instance of OM_Process should be created and associated with subsequent observations from that sensor (at least until the sensor is changed again).



Predominantly we expect the Process instance to be externally published / defined and 'static' (e.g. perhaps changing less often than once per month due to amendments to operational protocols etc.).

The class 'Process' provides a concrete implementation of OM_Process (from ISO 19156).


Type Notes

documentationRef [0..1] GenericName Reference to an external process definition providing information about relevant documentation that describes the associated Process.



A.4.3 RangeBounds

Type: Class.

Notes: The class 'RangeBounds' describes the extreme limits of a property value range (also known as a property value interval).




Type Notes

rangeEnd [1] Number The attribute 'rangeEnd' provides the extreme upper limit of the range or interval.

rangeStart [1] Number The attribute 'rangeStart' provides the extreme lower limit of the range or interval.



ANNEX B: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR OBSERVABLE PROPERTIES MODEL (OPM)

B.1 Introduction

The authoritative version of the OPM is maintained within AvXML as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model. What follows is abridged to suit the needs of the print medium.

The 'Observable Property' model enables observed physical properties to be aggregated into composite properties and for any qualification or constraint relating to those observed physical properties to be explicitly described.

A data publisher may need to use the Observed Property Model to explicitly define any qualification or constraint applied to the observed property, or, where the observation results in the evaluation of multiple properties, to explicitly define each of those individual physical properties.

B.2 Classes

The following context diagram shows the relationships among the various classes of OPM:




B.2.1 CompositeObservableProperty

Type: Class.

Notes: CompositeObservableProperty provides a single object within which a number of AbstractObservableProperty instances can be aggregated.


Type Notes

count [1] Integer The number of observed physical properties aggregated within this composite.

B.2.2 AbstractObservableProperty

Type: Class.

Notes: An 'observable property' is a physical property that can be observed. Typically, this will be a quantitative property (Quantity [1]) such as 'dew-point temperature'.

This abstract class enables either a single physical property to be specified or a composite observable property that aggregates a set of physical properties for a given observation context.

In many cases, the observed physical property will be sourced from a controlled vocabulary, thesaurus or ontology.

[1] Quantity: property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf])




Type Notes

altLabel [0..*] CharacterString The attribute 'altLabel' provides an alternative human-readable label used to describe the physical property.

label [0..1] CharacterString The attribute 'label' provides the primary human-readable label describing the observable physical property.

notation [0..*] LocalName The attribute 'notation' provides a notation or code-value that is used to identify the physical property within a given context.

B.2.3 ObservableProperty

Type: Class.

Notes: An 'observable property' is a physical property that can be observed. Typically, this will be a quantitative property (Quantity [1]) such as 'dew-point temperature'.

In many cases, the observed physical property will be sourced from a controlled vocabulary, thesaurus or ontology. The definition may be a simple a SKOS Concept or a node in a well-defined ontology. As such, the attributes of ObservableProperty have been elided; we simply need to assert that the entity has compatible semantics with the ObservableProperty class defined herein.

[1] Quantity: property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference (from the 'International vocabulary of metrology' [http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf])



B.2.4 QualifiedObservableProperty

Type: Class.

Notes: The class 'QualifiedObservableProperty' describes an observable physical property that is qualified or constrained within a given measurement context. Qualification of the observed physical property may take several forms:

- a specific unit of measure;

- a statistical operator (e.g. maximum) plus the aggregation context that the statistical operator applies to; or

- a constraint (e.g. radiance in wavelength band 50nm to 100nm).


Type Notes

unitOfMeasure [0..1] UnitOfMeasure The attribute 'uom' specifies the unit of measure used in the measurement of this physical property.

B.2.5 StatisticalQualifier

Type: Class.

Notes: An observed physical property may be represent a statistical summary with respect to a base property; e.g. maximum UV index over a 3-hour period.



The class 'StatisticalQualifier' defines the type of statistical function plus the mechanism that is used to aggregate the base property values to create the statistical summary: length, area, volume, duration or other.

Statistical summary properties may be defined by chaining a set of statistical operations together. For example: mean daily maximum temperature over a month period comprises two statistical operations with respect to the base property 'air temperature' - (i) maximum over a 24-hour duration, (ii) mean over a 1-month duration.


Type Notes

aggregationArea [0..1] Area The attribute 'aggregationArea' defines the spatial area over which the statistical function is applied in order to determine the statistical summary.

aggregationLength [0..1] Length The attribute 'aggregationLength' defines the spatial length over which the statistical function is applied in order to determine the statistical summary.

aggregationTimePeriod [0..1] TM_PeriodDuration The attribute 'aggregationTimePeriod' defines the temporal duration over which the statistical function is applied in order to determine the statistical summary.

aggregationVolume [0..1] Volume The attribute 'aggregationVolume' defines the spatial volume over which the statistical function is applied in order to determine the statistical summary.

description [0..1] CharacterString The attribute 'description' provides a textual description of the statistical qualification applied to the base observable physical property.

otherAggregation [0..1] Any The attribute 'otherAggregation' defines the any type of aggregation (other than duration, length, area or volume) over which the statistical function is applied in order to determine the statistical summary; e.g. prevailing visibility is [approximately] defined as a mean visibility in each horizontal direction.

statisticalFunction [1] StatisticalFunctionCode

The attribute 'statisticalFunction' defines the type of statistical function that is applied to the base observed property values in order to generate the statistical summary.



B.2.6 Constraint

Type: Class.

Notes: The class 'Constraint' enables the constraints relating to an observable physical property in a given measurement context to be specified.


Type Notes

description [0..1] CharacterString The attribute 'description' provides a textual description of the constraint applied to the base observable physical property.

B.2.7 CategoryConstraint

Type: Class.

Notes: The class 'CategoryConstraint' enables a category-based constraint to be specified. For example, in aviation the only clouds of significance for terminal aerodrome operations are convective clouds (cumulonimbus, towering cumulus etc.). The observed physical property 'cloud base [height]' may be constrained such that it is applicable only to clouds of a given type. In this example, a single instance of CategoryConstraint would be defined referencing both cloud types (cumulonimbus and towering cumulus); 'cloud type' is the constraint property.




Type Notes

value [1..*] GenericName The attribute 'value' defines the category member that applies to this constraint.

B.2.8 ScalarConstraint

Type: Class.

Notes: The class 'ScalarConstraint' allows an observed physical property to be constrained according to specific values of the constraining property. For example, the base property 'air temperature' may be constrained such that we are concerned only with the air temperature at 2.0 metres above local ground level (e.g. a screen temperature). In this example, 'height above local ground level' is the constraint property.


Type Notes

comparisonOperator [1] ComparisonOperator Attribute 'comparisonOperator' defines the mathematical operator relating the scalar constraint to the supplied numeric value; e.g. comparisonOperator = "eq" and value = "10.0" implies that the constraint is equal to the value 10.0.

unitOfMeasure [0..1] UnitOfMeasure The attribute 'uom' specifies the unit of measure used in the specification of the constraint property value.

value [1..*] Number The attribute 'value' provides the value of the constraint property.



B.2.9 RangeConstraint

Type: Class.

Notes: The class 'RangeConstraint' allows an observed physical property to be constrained according to a range of values of the constraining property. For example, the base property 'radiance' may be constrained such that we are concerned only with the radiance between wavelengths of 50nm to 100nm. In this example, 'wavelength' is the constraint property.


Type Notes

unitOfMeasure [0..1] UnitOfMeasure The attribute 'uom' specifies the unit of measure used in the specification of the constraint property value.

value [1..*] RangeBounds The association role 'value' references an instance of the RangeBounds class that specifies the extreme limits of the range that apply to the constraint property.

B.2.10 ComparisonOperator

Type: Enumeration.

Notes: «Enumeration» 'ComparisonOperator' defines the set mathematical operators that may be used to compare numerical values; not equal, less than, less than or equal, equal, greater than or equal and greater than.




Type Notes

ne [1] Comparison operator: "not equal to"

lt [1] Comparison operator: "less than"

le [1] Comparison operator: "less than or equal to"

eq [1] Comparison operator: "equal to"

ge [1] Comparison operator: "greater than or equal to"

gt [1] Comparison operator: "greater than"

B.2.11 RangeBounds

Type: Class.

Notes: The class 'RangeBounds' describes the extreme limits of a property value range (also known as a property value interval).


Type Notes

endComparison [1] ComparisonOperator Attribute 'startComparison' defines the mathematical operator relating the lower boundary of the range constraint to the supplied numeric value; e.g. when specifying a wavelength band, startComparison = "eq", uom = "nm" and value = "100.0" implies that the lower range of the wavelength band is 100 nanometres.




Type Notes

rangeEnd [1] Number The attribute 'rangeEnd' provides the extreme upper limit of the range or interval.

rangeStart [1] Number The attribute 'rangeStart' provides the extreme lower limit of the range or interval.

startComparison [1] ComparisonOperator Attribute 'startComparison' defines the mathematical operator relating the lower boundary of the range constraint to the supplied numeric value; e.g. when specifying a wavelength band, startComparison = "eq", uom = "nm" and value = "50.0" implies that the lower range of the wavelength band is 50 nanometres.

B.2.12 StatisticalFunctionCode

Type: Class.

Notes: The «CodeList» class 'StatisticalFunctionCode' specifies the type of statistical function that is applied to the base observable property to define the statistical summary; e.g. maximum air temperature.

Note that WMO provides two code-tables listing statistical operators:

- WMO No. 306 Vol I.2 Part B FM 92 GRIB code-table 4.10 'Type of statistical processing'; and

- WMO No. 306 Vol I.2 Part B FM 94 BUFR code-table 0 08 023 'First-order statistics'

The GRIB2 code-table is defined as the 'recommended' vocabulary for this «CodeList» class but lacks some of the necessary terms. For example, the GRIB code-table includes 'Average' but does not include 'Mean', 'Mode' or 'Median' (which can be found in the BUFR code-table). However, the BUFR code-table is _NOT_ chosen because 'Accumulation' is entirely missing. Given that 'extensibility' is set to 'any', authors are free to refer to their preferred 'statistical operator' vocabulary. The GRIB code-table is only a recommendation.



ANNEX C: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR SIMPLE AERONAUTICAL FEATURES (SAF)

C.1 Introduction

The authoritative version of the OPM is maintained within AvXML as an online resource at the following URL: http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. What follows is abridged to suit the needs of the print medium.

The Simple Aeronautical Features model includes simplified features from the aeronautical domain, such as aerodrome, runway, unit, and airspace. These features are simplified representations of the more complex aeronautical features found in the Aeronautical Information Conceptual Model (AICM) and the the Aeronautical Information eXchange Model (AIXM). They are simplified in SAF to facilitate both storage and transmission.

There are two independent issues involved in referencing aeronautical features: 1. Using AICM/AIXM classes directly for these concepts would introduce a dependency on AICM/AIXM, which is a package of significant size and complexity 2. Machine-readable, managed definitions for these concepts (such as the location, capabilities, and other information for the 'HTKJ' aerodrome) do not exist in a unified and authoritative form. This information is managed independently, and sometimes inconsistently, by many organizations worldwide.

The current version of this package is intended to address the needs for producers of meteorological information to be able to distribute the basic characteristics (identification, location, time, etc.) of their aeronautical information to consumers. In many cases data producers are the best authority for up-to-date aeronautical information. Downstream consumers may then use this information or ignore it. These concepts are represented in a way that is intended to be largely consistent with AICM/AIXM.

C.2 Features

Notes: Package containing the definition of the core SAF Features. Features in this package roughly correspond to AIXM equivalents.




C.2.1 Aerodrome

Type: Class.

Notes: A defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft/helicopters.

Attribute Multi-

plicity

Type Notes

designator [0..1] CodeAirportHeliportDesignatorType A coded designator for an Aerodrome/Heliport.

The rules according to which this identifier should be formed are as follows:

1. If the AD/HP has an ICAO four letter location indicator, then this one will become the CODE_ID for the Aerodrome/Heliport;

2. If the AD/HP does not have an ICAO four letter location indicator, but it has an IATA three letter code, then this one will become the CODE_ID for the Aerodrome/Heliport;

3. If the AD/HP has neither an ICAO four letter location indicator nor an IATA three letter code, then an artificial generated code will be used. This will contain a group of letters and a number. The group of letters could be the 2 letter code of the State being



Attribute Multi-

plicity

Type Notes

responsible for the Aerodrome/Heliport and the number could be an integer between 0001 and 9999.

designatorIATA [0..1] CodeIATAType The identifier that is assigned to a location in accordance with rules (resolution 767) governed by the International Air Transport Association (IATA).

fieldElevation [0..1] Distance The vertical distance above Mean Sea Level (MSL) of the highest point of the landing area.

locationIndicatorICAO [0..1] CodeICAOType The four letter ICAO location indicator of the aerodrome/heliport, as listed in ICAO DOC 7910.

name [0..1] TextNameType The primary official name of an aerodrome as designated by an appropriate authority.



C.2.2 Airspace

Type: Class.

Notes: A defined three dimensional region of space relevant to air traffic.

Attribute Multi-

plicity

Type Notes

designator [0..1] CodeAirspaceDesignatorType

A published sequence of characters allowing the identification of the airspace.

Description:

Typical examples are the ID of the Danger, Prohibited, Temporary segregated Areas, etc.

designatorICAO [0..1] Boolean A code indicating the Airspace designator is recorded in ICAO Doc. 7910.

name [0..1] TextNameType The name given to an airspace by a responsible authority.

Description:

It should be written as published, with no significance to upper or lower case letters.



Attribute Multi-

plicity

Type Notes

type [0..1] CodeAirspaceType A code indicating the general structure or characteristics of a particular airspace.



C.2.3 AirspaceVolume

Type: Class.

Notes: A defined volume in the air, described as horizontal projection with vertical limits.

Attribute Multi-

plicity

Type Notes

lowerLimit [0..1] Distance The vertical position of the airspace floor.

lowerLimitReference [0..1] CodeVerticalReferenceType The reference surface used for the value of the lower limit. For example, Mean Sea Level, Ground, standard pressure, etc..

upperLimit [0..1] Distance The vertical position of the airspace ceiling.

upperLimitReference [0..1] CodeVerticalReferenceType The reference surface used for the value of the upper limit. For example, Mean Sea Level, Ground, standard pressure, etc..

C.2.4 Runway

Type: Class.

Notes: A defined rectangular area on a land aerodrome/heliport prepared for the landing and take-off of aircraft.



Note: this includes the concept of Final Approach and Take-Off Area (FATO) for helicopters.

Attribute Multi-

plicity

Type Notes

designator [0..1] TextDesignatorType The full textual designator of the runway, used to uniquely identify it at an aerodrome/heliport which has more than one.

E.g. 09/27, 02R/20L, RWY 1.

C.2.5 RunwayDirection

Type: Class.

Notes: One of the two landing and take-off directions of a runway for which attributes like TORA, TODA, LDA, etc. may be defined.



Attribute Multi-

plicity

Type Notes

designator [0..1] TextDesignatorType The full textual designator of the landing and take-off direction.

Examples: 27, 35L, 01R.

elevationTDZ [0..1] Distance Elevation of touch down zone: The value of the highest elevation of the runway Touch Down Zone (TDZ).

trueBearing [0..1] Angle The measured angle between the runway direction and True North at a given position. Note : The True North is the north point at which the meridian lines meet.

C.2.6 Service

Type: Class.

Notes: The provision of tangible goods, information, instructions, guidance, etc. to pilots, flights, aircraft operators and other personnel and institutions concerned with flight operations.



Attribute Multi-

plicity

Type Notes

flightOperations [0..1] CodeFlightDestinationType

The destination (arriving, departing, etc.) of the flights for which the information is provided.

name [0..1] TextNameType A free text name by which the service is identified.



C.2.7 Unit

Type: Class.

Notes: A generic term meaning variously all types of 'units' providing all types of services. This includes particularly Air Traffic Management (ATM) Units but also units which are not express verbs included in ATM such as SAR, MET, COM etc.

Attribute Multi-

plicity

Type Notes

designator [0..1] CodeOrganisationDesignatorType A coded designator associated with the Unit. For example, the ICAO Location Indicator of an ACC, as listed in DOC 7910.

name [0..1] TextNameType The full textual name of a unit. This name must be established according to the rules specified by ICAO, viz.: in the official language of the country, transposed into the Latin Alphabet where necessary.

type [0..1] CodeUnitType A type by which the Unit is recognised, usually related to the standard type of services provided by it (e.g. area control centre, advisory centre, aeronautical information services office).



C.3 Data Types

Notes: Package containing the datatypes that are used throughout SAF. This is restricted set that are roughly analogous to equivalent AIXM data types.

C.3.1 CodeAirportHeliportDesignatorType

Type: Class.

Notes: A coded identifier for an Aerodrome/Heliport/Aerodrome.



The rules according to which this identifier should be formed are as follows:

1) If the AD/HP has an ICAO four letter location indicator, this will become the CODE_ID for the Aerodrome/Heliport;

2) If the AD/HP does not have an ICAO four letter location indicator but has an IATA three letter code, then this will become the CODE_ID for the Aerodrome/Heliport;

3) If the AD/HP does not have either an ICAO four letter location indicator or an IATA three letter code, an artificially generated code will be used. This will contain a group of letters and a number. The group of letters could be the 2 letter code of the State responsible for the Aerodrome/Heliport (or one of these, if there are more than one, like ED and ET for Germany) and the number could be an integer between 0001 and 9999.

C.3.2 CodeAirspaceDesignatorType

Type: Class.

Notes: A code indicating the general structure or characteristics of a particular airspace. This will generally include a published sequence of characters allowing the identification of the airspace. Typical examples are the ID of the Danger, Prohibited, Temporary segregated Areas, etc.

C.3.3 CodeAirspaceType

Type: Enumeration.

Notes: The valid codes that may be used for airspace type (e.g., flight information region, upper information region, controlled airspace).

Equivalent to AIXM CodeAirspaceType, except that only the codes of interest outside AIXM were used.



Attribute

Multi-

plicity

Type Notes

FIR [1] Flight information region. Airspace of defined dimensions within which flight information service and alerting service are provided.

Description:

ICAO Recognized.

Might, for example, be used if service provided by more than one unit.

UIR [1] Upper flight information region. An upper airspace of defined dimensions within which flight information service and alerting service are provided.

Description:

Non-ICAO Recognized.

Each state determines its definition for upper airspace.

FIR_UIR [1] Flight information region or upper flight information region.



Attribute

Multi-

plicity

Type Notes

CTA [1] Control area. A controlled airspace extending upwards from a specified limit above the earth.

Description:

ICAO Recognized.

C.3.4 CodeFlightDestinationType

Type: Enumeration.

Notes: A coded list of values that designate the intentions of a flight in relation with a location, such as arrival, departure or over-flight.

Attribute Multi-

plicity

Type Notes

ALL [1] All types (arrival, departure and overflying).

ARR [1] Arrival flights.



Attribute Multi-

plicity

Type Notes

DEP [1] Departing flights.

OVERFLY

[1] Overflying flights.

C.3.5 CodeIATAType

Type: Class.

Notes: The three letter coded location identifier of an airport/heliport according to the IATA Resolution 763.

C.3.6 CodeICAOType

Type: Class.

Notes: The four letter coded location identifier as published in the ICAO DOC 7910 - Location Indicators.

C.3.7 CodeOrganisationDesignatorType

Type: Class.



Notes: The coded identifier of an organisation, authority, agency or unit.

C.3.8 CodeUnitType

Type: Enumeration.

Notes: A unit providing particular ATS services.

Attribute

Multi-

plicity

Type Notes

ARO [1] Aerodrome reporting office/ATS reporting office.

ATCC [1] Air traffic control centre.

ATSU [1] Air traffic services unit.

FIC [1] Flight information centre.

MWO [1] Meteorological watch office.



C.3.9 CodeVerticalReferenceType

Type: Enumeration.

Notes: The type of vertical reference (e.g., surface, mean sea level)

This class is copied from the AIXM class with the same name.

Attribute

Multi-

plicity

Type Notes

SFC [1] The distance measured from the surface of the Earth (equivalent to AGL - Above Ground Level).

MSL [1] The distance measured from mean sea level (equivalent to altitude).

W84 [1] The distance measured from the WGS84 ellipsoid.

STD [1] The vertical distance is measured with an altimeter set to the standard atmosphere.

C.3.10 TextDesignatorType

Type: Class.

Notes: A textual designator.



C.3.11 TextNameType

Type: Class.

Notes: The official name of a State, an aerodrome, a unit, etc..

C.4 Measures

Notes: Package with Nillable Measure and NilReason



C.4.1 DistanceWithNilReason

Type: Class.



Notes: A nillable Distance quantity. Unlike the base Distance measure, references to this type may be nil and may include a nilReason

C.4.2 LengthWithNilReason

Type: Class.

Notes: A nillable Length quantity. Unlike the base Length measure, references to this type may be nil and include a nilReason



ANNEX D: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR THE ICAO METEOROLOGICAL INFORMATION EXCHANGE MODEL (IWXXM), METAR AND SPECI

D.1 Introduction

The authoritative version of the OPM is maintained within AvXML as an online resource at the following URL: http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. What follows is abridged to suit the needs of the print medium.

D.2 The METAR and SPECI leaf of IWXXM

The METAR/SPECI leaf of the ICAO Meteorological Information Exchange Model (IWXXM) models the reporting constructs defined in ICAO Annex 3 / WMO No. 49-2.

METAR and SPECI reports include identical information but are issued for different purposes. METAR reports are routine observations made at an aerodrome throughout the day. METAR observations are made (and distributed) at intervals of one hour or, if so determined by regional air navigation agreement, at intervals of one half-hour. SPECI reports are special (i.e., non-routine) observation made at an aerodrome as needed. SPECI observations are made (and distributed) in accordance with criteria established by the meteorological authority, in consultation with the appropriate ATS authority, operators and others concerned.

D.2.1 MeteorologicalAerodromeObservationReport

Type: Class.

Notes: A report of observed and trend forecast weather phenomenon from the surface near an aerodrome. This is a shared superclass for METAR and SPECI reports, which have identical reported information.





Type Notes

automatedStation [0..1] Boolean When true, this report was reported by an automated station.

observation [1] MeteorologicalAerodromeObservation The observation which resulted in the current meteorological conditions at an aerodrome

status [1] MeteorologicalAerodromeReportStatus The report status (e.g., normal, corrected)

trendForecast [0..3] MeteorologicalAerodromeTrendForecast The process that results in a trend forecast.

When no change is expected to occur during a forecast period ("NOSIG") this is indicated by a single missing trend forecast with a nil reason of noSignificantChange



D.2.2 METAR

Type: Class.

Notes: A routine observation made at an aerodrome throughout the day. METAR observations are made (and distributed) at intervals of one hour or, if so determined by regional air navigation agreement, at intervals of one half-hour.



The information contained in METAR and SPECI is identical. SPECI is issued when conditions merit a non-routine report on conditions at an aerodrome.

METARs are a routine report produced for dissemination beyond the aerodrome of origin, and are mainly intended for flight planning, VOLMET broadcasts and D-VOLMET.

See ICAO Annex 3 / WMO No. 49-2 Table A3-2

D.2.3 SPECI

Type: Class.

Notes: A special (i.e., non-routine) observation made at an aerodrome as needed. SPECI observations are made (and distributed) in accordance with criteria established by the meteorological authority, in consultation with the appropriate ATS authority, operators and others concerned.

The information contained in METAR and SPECI is identical. SPECI is issued when conditions merit a non-routine report on conditions at an aerodrome.

SPECI reports are used for dissemination beyond the aerodrome of origin (mainly intended for flight planning, VOLMET broadcasts and D-VOLMET) unless METAR are issued at half-hourly intervals.

SPECI is issued following the resumption of the issuance of METAR, as necessary, at aerodromes that are not operational throughout 24 hours in accordance with ICAO Annex 3 Section 4.3.1.

See ICAO Annex 3 / WMO No. 49-2 Table A3-2



D.2.4 MeteorologicalAerodromeObservation

Type: Class.

Notes: A specialized OM_Observation type used for reporting an aggregate set of observed meteorological conditions at an Aerodrome. The result of this observation type refers to an entity of type MeteorologicalAerodromeObservationRecord.

ComplexSamplingMeasurement enforces the sampled feature be an Aerodrome.

MeteorologicalAerodromeObservation has a sister Class for forecast information at an Aerodrome: MeteorologicalAerodromeTrendForecast.



D.2.5 MeteorologicalAerodromeObservationRecord

Type: Class.

Notes: A specialized Record type containing meteorological conditions observed at an aerodrome.

When no clouds of operational significance or no weather of operational significance is observed, the NothingOfOperationalSignificance nilReason is used for the cloud or presentWeather association. When no clouds were detected by the automatic observing system, the NotDetectedByAutoSystem nilReason is used for the cloud association.


Type Notes

airTemperature [1] Measure The observed air temperature. This is the temperature indicated by a thermometer exposed to the air in a place sheltered from direct solar radiation.

cloudAndVisibilityOK [1] Boolean When true, indicates that the observed cloud ceiling, horizontal visibility, and weather conditions are of no operational significance. See ICAO Annex 3 / WMO No. 49-2 Section 2.2. Also known as "CAVOK"

When CAVOK conditions are observed, no other information on visibility, runway visual range, present weather, cloud amount, or cloud type is reported

dewpointTemperature [1] Measure The observed dew point temperature. This is the temperature to which a given air parcel must be cooled at constant pressure and constant water vapor content in order for saturation to occur.




Type Notes

qnh [1] Measure The observed QNH altimeter setting.

Altitude setting (also known as QNH) is defined as barometric pressure adjusted to sea level. It is a pressure setting used by pilots, air traffic control (ATC), and low frequency weather beacons to refer to the barometric setting which, when set on an aircraft's altimeter, will cause the altimeter to read altitude above mean sea level within a certain defined region.

D.2.6 MeteorologicalAerodromeTrendForecast

Type: Class.

Notes: A specialized OM_Observation type used for reporting an aggregate set of forecast meteorological conditions at an Aerodrome. The result of this observation type refers to an entity of type MeteorologicalAerodromeTrendForecastRecord.

MeteorologicalAerodromeTrendForecast additionally enforces that the sampled feature must be an Aerodrome

MeteorologicalAerodromeTrendForecasts are reported in surface observation reports such as SPECI and METAR. MeteorologicalAerodromeTrendForecast has a sister class for trend forecast information at an Aerodrome (MeteorologicalAerodromeObservation) which is also reported on a METAR and SPECI for observed phenomena. This class is also related but not identical to MeteorologicalAerodromeForecast which is reported on a TAF - conditions reported in trend forecasts in METAR/SPECI differ from forecast groups in a TAF.



D.2.7 MeteorologicalAerodromeTrendForecastRecord

Type: Class.

Notes: A specialized Record type containing meteorological conditions for trend forecasting at an aerodrome. This class is also related but not identical to MeteorologicalAerodromeForecastRecord which is reported on a TAF - conditions reported in trend forecasts in METAR/SPECI differ from forecast groups in a TAF.

When no clouds of operational significance or no weather of operational significance is predicted, the NothingOfOperationalSignificance nilReason should be used for the cloud or presentWeather association. When no clouds were detected by the automatic observing system, the NotDetectedByAutoSystem nilReason should be used for the cloud association.


Type Notes

changeIndicator [1] ForecastChangeIndicator The change indicator for this trend forecast - becoming, temporary conditions, or no significant change



prevailingVisibility [0..1] Distance The prevailing horizontal visibility reported in a trend forecast




Type Notes

prevailingVisibilityOperator [0..1] RelationalOperator The reported relational operator for the prevailing horizontal visibility. When reported, this operator is reported in conjunction with prevailing visibility.

To report a prevailing visibility of at least 10000 meters, prevailing visibility is reported as 10000 meters and the operator is reported as "above".

When no operator is reported, prevailing visibility represents an exact value with identical semantics to other measured quantities

D.2.8 AerodromeSurfaceWind

Type: Class.

Notes: An aggregation of surface wind conditions typically reported together at an aerodrome, including wind direction information, wind speed, and wind gusts.

Wind direction is reported according to ICAO Annex 3 / WMO No. 49-2 Section 4.1.5.2b.




Type Notes

extremeClockwiseWindDirection [0..1] Angle The extreme clockwise direction from which the wind is blowing, inclusive.

ICAO Annex 3 / WMO No. 49-2: Section 4.1.5.2bextremeCounterClockwiseWindDirection [0..1] Angle The extreme counter-clockwise direction from which the wind is blowing,

inclusive.

ICAO Annex 3 / WMO No. 49-2: Section 4.1.5.2bmeanWindDirection [0..1] Angle The observed average wind direction from which the wind is blowing over

the past ten minutes. Not reported when winds are variablemeanWindSpeed [1] Velocity The average observed wind speed over the past ten minutes

ICAO Annex 3 / WMO No. 49-2: Section 4.1.5.2avariableDirection [0..1] Boolean When true, indicates that the wind direction is variable. A wind direction

value may still be reportedwindGust [0..1] Velocity The maximum wind speed observed over the past ten minutes

ICAO Annex 3 / WMO No. 49-2: Section 4.1.5.2c

D.2.9 AerodromeHorizontalVisibility

Type: Class.

Notes: An aggregation of horizontal visibility conditions typically reported together at an aerodrome, including the prevailing visibility and minimum visibility.




Type Notes

minimumVisibility [0..1] Distance The minimum observed visibility.

ICAO Annex 3 / WMO No. 49-2 Section 4.2.4.4a:"When the visibility is not the same in different directions anda) when the lowest visibility is different from the prevailing visibility, and 1) less than 1500 m or 2) less than 50 percent of the prevailing visibility and less than 5000 m; the lowest visibility observed should also be reported and, when possible, its general direction in relation to the aerodrome reference point indicated by reference to one of the eight points of the compass. If the lowest visibility is observed in more than one direction, then the most operationally significant direction should be reported; andb) when the visibility is fluctuating rapidly, and the prevailing visibility cannot be determined, only the lowest visibility should be reported, with no indication of direction."

minimumVisibilityDirection [0..1] Angle The direction of the minimum visibility relative to the reporting station. This is optional in cases where minimum visibility is reported but the visibility is fluctuating rapidly. Minimum visibility is reported in cardinal and inter-cardinal directions (N, NE, E, SE, S, SW, W, and NW)




Type Notes

prevailingVisibility [1] Distance The reported prevailing horizontal visibility at the surface that is representative of the aerodrome.

The greatest visibility value, observed in accordance with the definition of "visibility", which is reached within at least half the horizon circle or within at least half of the surface of the aerodrome. These areas could comprise contiguous or non-contiguous sectors.

ICAO Annex 3 / WMO No. 49-2: Section 4.2.4.4bprevailingVisibilityOperator [0..1] RelationalOperator The reported relational operator for the prevailing horizontal visibility. When

reported, this operator is reported in conjunction with prevailing visibility.



D.2.10 AerodromeSeaState

Type: Class.

Notes: An aggregation of sea state conditions typically reported together at an aerodrome. This includes information on sea-surface temperature and either the state of the sea or significant wave height from aeronautical meteorological stations established on offshore structures in support of helicopter operations




Type Notes

seaState [0..1] SeaSurfaceState The state of the sea observed by aeronautical meteorological stations established on offshore structures in support of helicopter operations

ICAO Annex 3 / WMO No. 49-2: Section 4.8.1.5a

WMO 306: Table 3700seaSurfaceTemperature [1] Measure The sea-surface temperature observed by aeronautical

meteorological stations established on offshore structures in support of helicopter operations.

The term sea surface temperature is generally meant to be representative of the upper few meters of the ocean as opposed to the skin temperature, which is the temperature of the upper few centimeters.

ICAO Annex 3 / WMO No. 49-2: Section 4.8.1.5asignificantWaveHeight [0..1] Distance The significant wave height observed

D.2.11 SeaSurfaceState

Type: Class.



Notes: Categorical assessment of sea surface state (or other large open body of water) based on height of waves.

See WMO No. 306 Vol I.1 code table 3700 "State of the sea" and WMO No. 306 Vol I.2 FM 94 BUFR code table 0 22 061 "State of the sea".

D.2.12 AerodromeRunwayVisualRange

Type: Class.

Notes: An aggregation of runway visual range conditions for a single runway, typically reported together at an aerodrome


Type Notes

meanRVR [1] Distance The mean recent runway visual range value observed. This mean represents the 10 minute average for observed RVR except when the 10-minute period immediately preceding the observation includes a marked discontinuity in runway visual range values, only those values occurring after the discontinuity is used for obtaining mean values.

To report a mean RVR of at least 2000 meters, mean RVR is reported as 2000 meters and the operator is reported as "above"

Annex 3: Table A3-2 "RVR/RVR" Section 4.3.6.6




Type Notes

meanRVROperator [0..1] RelationalOperator The reported relational operator for the mean RVR. When reported, this operator is reported in conjunction with mean RVR.

To report a mean RVR of at least 2000 meters, mean RVR is reported as 2000 meters and the operator is reported as "above".

When no operator is reported, mean RVR represents an exact value with identical semantics to other measured quantities

pastTendency [0..1] VisualRangeTendency The runway visual range tendency (up, down, none).

If the runway visual range values during the 10-minute period have shown a distinct tendency, such that the mean during the first 5 minutes varies by 100 m or more from the mean during the second 5 minutes of the period, this should be indicated. When the variation of the runway visual range values shows an upward or downward tendency, this should be indicated by "Up" or "Down", respectively. In circumstances when actual fluctuations during the 10-minute period show no distinct tendency, this should be indicated using "No Change?. When indications of tendency are not available, no information should be reported

ICAO Annex 3 / WMO No. 49: Table A3-2 Note 9 Section 4.3.6.6arunway [1] RunwayDirection The runway to which reported runway visual range information applies

D.2.13 VisualRangeTendency

Type: Enumeration.



Notes: The tendency of visual range (e.g., upward, downward). Defined for the purposes of aviation meteorology reporting of the visual range on runways (WMO No. 49-2).

If the [runway] visual range (RVR) values during the 10-minute period preceding the nominal observation time show a distinct upward or downward tendency such that the mean during the first five minutes varies by 100 metres or more from the mean in the second five minutes of the period, an UPWARD [U] or DOWNWARD [D] tendency is recorded. When no distinct change in RVR is observed, NO CHANGE [N] is recorded.

See WMO No. 306 Vol I.2 FM 94 BUFR code-table 0 20 018 "Tendency of runway visual range".


Type Notes

UPWARD [1] Upward (increasing) tendency

NO_CHANGE [1] No change

DOWNWARD [1] Downward (decreasing) tendency

D.2.14 AerodromePresentWeather

Type: Class.

Notes: The present weather observed at, or in near vicinity of, an aerodrome.

Only a specific set of weather phenomenon are reported within aviation meteorology as defined in Regulation ICAO Annex 3 / WMO No. 49-2.



This CodeList is specifically defined for aviation purposes as defined in WMO No. 49-2. A superset of definitions are defined in WMO No. 306 Vol I.1 code-table 4678 "Significant weather phenomena".



D.2.15 AerodromeObservedClouds

Type: Class.

Notes: An aggregation of observed cloud conditions typically reported together at an aerodrome, including cloud types, cloud layers, and vertical visibility.


Type Notes

amountAndHeightUnobservableByAutoSystem [0..1] Boolean An automatic observing system observed cumulonimbus clouds or towering cumulus clouds but the cloud amount and height could not be observed

ICAO Annex 3 / WMO No. 49-2:Section 4.5.4.5c - When cumulonimbus clouds or towering cumulus clouds are detected by the automatic observing system and the cloud amount and the height of cloud base cannot be observed, the cloud amount and the height of cloud base should be replaced by "//////"




Type Notes

verticalVisibility [0..1] LengthWithNilReason The reported vertical visibility. Vertical visibility is defined as the vertical visual range into an obscuring medium.

Note: vertical visibility is only reported in aviation-specific WMO Code-forms (FM-15 METAR, FM-16 SPECI and FM-51 TAF) thus prevailing visibility is considered to be an aviation-specific quantity.

When the sky is obscured and the value of the vertical visibility cannot be determined by the automatic observing system due to a temporary failure of the system/sensor ("VV///") the vertical visibility is missing with a nil reason of notObservable

D.2.16 AerodromeRecentWeather

Type: Class.

Notes: Weather phenomenon of operational significance to aviation observed during the period since the last routine report, or last hour, whichever is shorter, but not at the time of observation.




This CodeList is specifically defined for aviation purposes as defined in WMO No. 49-2. A superset of definitions are defined in WMO No. 306 Vol I.1 code-table 4678 "Significant weather phenomena".

D.2.17 AerodromeWindShear

Type: Class.

Notes: An aggregation of wind shear conditions typically reported together at an aerodrome, including the set of affected runways.


Type Notes

allRunways [0..1] Boolean When true, all runways are observed to have wind shear

runway [0..*] RunwayDirection The specific runway(s) affected by wind shear at this aerodrome. No specific runways are reported when all runways are affected by wind shear

D.2.18 AerodromeRunwayState

Type: Class.

Notes: An aggregation of runway conditions typically reported together at an aerodrome, including the runway contamination, friction, and deposits.




Type Notes

allRunways [0..1] Boolean When true, indicates the reported conditions apply to all runways

cleared [0..1] Boolean Indicates that reported runway has been cleared of meteorological deposits, such as snow.

ICAO Annex 3 / WMO No. 49-2: "CLRD"

Section 4.8.1.5, Table A3-2 "State of the runway"contamination [0..1] RunwayContamination Proportion of runway surface that is contaminated - usually expressed as a

percentage of the total runway area.

See WMO No. 306:WMO Code table 0519 and BUFR Code table 0 20 087

depositType [0..1] RunwayDeposits The type of runway deposit, such as damp conditions, wet snow, or ice.

WMO 306: Table 0919depthOfDeposit [0..1] Distance Depth of deposit on the surface of the runway.

See WMO No. 306 WMO Code table 1079.estimatedSurfaceFriction

[0..1] Scale The estimated surface friction for the affected runway. Between 0.0 and 0.9.

When braking conditions are not reported and/or the runway is not operational estimatedSurfaceFriction will not be reported.

WMO 306: Table 0366




Type Notes

estimatedSurfaceFrictionUnreliable

[0..1] Boolean When true, the estimated surface friction is unreliable and is not reported.

WMO 306: Table 0366runway [0..1] RunwayDirection The runway to which the conditions apply. The runway may be missing in cases

where all runways are closed due to snowsnowClosure [0..1] Boolean Indicates whether the aerodrome is closed due to an extreme deposit of snow. This

affects all runways

WMO 306: Section 15.13.6.1



D.2.19 RunwayContamination

Type: Class.

Notes: Extent of runway surface that is contaminated (covered)

D.2.20 RunwayDeposits

Type: Class.

Notes: Type of deposit on a 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".

D.2.21 MeteorologicalAerodromeReportStatus

Type: Enumeration.

Notes: The status of a MeteorologicalAerodromeObservationReport (e.g., a normal issuance, correction of an earlier report, etc.)


Type Notes

NORMAL [1] Normal report status: not a correction of an earlier report




Type Notes

CORRECTION [1] A correction of an earlier report

MISSING [1] The report is missing ("NIL" from ICAO Annex 3 / WMO No. 49)

D.2.22 ForecastChangeIndicator

Type: Enumeration.

Notes: Change qualifier of a trend-type forecast or an aerodrome forecast.

Defined in WMO No. 306 Vol I.1; FM-15 METAR, FM-16 SPECI and FM-51 TAF.

Also see WMO No. 306 Vol I.2 Part B FM 94 BUFR code-table 0 08 016 'Change qualifier of a trend forecast or an aerodrome forecast'.


Type Notes

NO_SIGNIFICANT_CHANGES [1] No significant changes are forecast (NOSIG)

BECOMING [1] When the change is forecast to commence at the beginning of the forecast period and be completed by the end of that period, or when the change is forecast to occur within the forecast period but the time of the change is uncertain (possibly shortly after the beginning of the forecast period, or midway or near the end of that period), the change is indicated by only the change indicator BECMG.




Type Notes

TEMPORARY_FLUCTUATIONS [1] The change indicator TEMPO is used to describe expected temporary fluctuations to meteorological conditions which reach or pass specified threshold criteria and last for a period of less than one hour in each instance and in the aggregate cover less than half of the forecast period during which the fluctuations are expected to occur.



ANNEX E: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR THE ICAO METEOROLOGICAL INFORMATION EXCHANGE MODEL (IWXXM), TAF

E.1 Introduction

The authoritative version of the METCE is maintained within AvXML as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model . (N.B.: There are no whitespace characters in the URL.) What follows is abridged to suit the needs of the print medium.

E.2 2 The TAF leaf of IWXXM

The TAF leaf of the ICAO Meteorological Information Exchange Model (IWXXM) models theNotes: TAF reporting constructs as defined in ICAO Annex 3 / WMO No. 49-2.

An Aerodrome Forecast (TAF) report is a routine forecast of meteorological conditions at an aerodrome intended for distribution. TAF reports include base forecast conditions, and modifications to those conditions throughout the valid period.

E.2.1 TAF

Type: Class.

Notes: An Aerodrome Forecast (TAF) report is a routine aerodrome forecast intended for distribution beyond an aerodrome. TAF reports report base forecast conditions, and modifications to those conditions throughout the valid period.

TAF reports include similar information to a METAR/SPECI trend forecast. However, TAF forecast information includes additional detail.

Aerodromes can issue both METAR/SPECI and TAF reports on a routine basis, but TAFs are not issued by every METAR-reporting aerodrome.

http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model





The issuance of a new forecast by a meteorological office, such as a TAF, cancels any forecast of the same type previously issued for the same place and for the same period of validity or part thereof.

Prevailing conditions and forecast changes differ in that the prevailing conditions can include temperatures, base conditions do not include a change indicator, and that forecast changes may report no significant weather (NSW). Rather than have two class hierarchies, constraints are present ensuring that each (base and forecast conditions) only include relevant information


Type Notes

baseForecast [0..1] MeteorologicalAerodromeForecast The prevailing conditions. Mandatory in all cases except missing or cancelled reports

changeForecast [0..*] MeteorologicalAerodromeForecast Forecast that modifies the base forecast. While there is no maximum number of forecasts, this should normally not exceed five in number.

ICAO Annex 3 / WMO No. 49-2:

Section 1.5: "The number of change and probability groups should be kept to a minimum and should not normally exceed five groups".




Type Notes

issueTime [1] TM_Instant The time at which this report was issued. Note that this should be identical to the resultTime of each MeteorologicalAerodromeForecast, whose results are made available at the same time as this report. TAF reports have an issueTime to assist in discovery and to provide unambiguous semantics at the report level.

previousReportAerodrome [0..1] Aerodrome The aerodrome of the previously-issued report being amended or cancelled

previousReportValidPeriod [0..1] TM_Period The valid time period for the previously amended and/or cancelled report

status [1] TAFReportStatus The status of this report, including amended, cancelled, normal, or corrected.

Missing reports indicate that a report was not issued from the responsible reporting party as expected. Missing reports are typically issued by third parties that were expecting a report.

validTime [0..1] TM_Period The time frame at which this report is valid. All forecast elements should be valid within this period



E.2.2 MeteorologicalAerodromeForecast

Type: Class.

Notes: A specialized OM_Observation type used for reporting an aggregate set of forecast meteorological conditions at an Aerodrome. The result of this observation type refers to an entity of type MeteorologicalAerodromeForecastRecord.

MeteorologicalAerodromeForecast enforces one constraint--the sampled feature must be an Aerodrome. This class is also related but not identical to MeteorologicalAerodromeTrendForecast which is reported on a METAR/SPECI - conditions reported in trend forecasts in METAR/SPECI differ from forecast groups in a TAF.

The TAF forecast group from/to variants (FM, TL, AT, etc.) are represented on the OM_Observation validTime, which is always an instance of TM_Period. When there is only an instant at which a condition occurs, the start and end time are the same.



E.2.3 MeteorologicalAerodromeForecastRecord

Type: Class.

Notes: A specialized Record type containing meteorological conditions forecast at an aerodrome. This class is also related but not identical to MeteorologicalAerodromeTrendForecastRecord, which is reported on a METAR/SPECI - conditions reported in trend forecasts in METAR/SPECI differ from forecast groups in a TAF.

When no clouds of operational significance or no weather of operational significance is predicted, the nothingOfOperationalSignificance nilReason should be used for the cloud or presentWeather association.

Note that the TAC representations for "FM", "TL", and "AT" are represented by the phenomenonTime on the change forecast (MeteorologicalAerodromeForecast):

FM and TL - a phenomenonTime with a TimePeriod (start is FM and end is TL)

TL - a phenomenonTime with a TimePeriod (start is beginning of forecast validity and end is TL)

FM - a phenomenonTime with a TimePeriod (start is FM and end is end of forecast validity)

AT - a phenomenonTime with a TimeInstant




Type Notes

changeIndicator [0..1] AerodromeForecastChangeIndicator The type of change being reported (FROM, BECOMING, TEMPORARY, etc.).

A change indicator is required for all MeteorologicalAerodromeForecastRecords excepting reported base conditions.



prevailingVisibility [0..1] Distance The prevailing horizontal visibility, mandatory except when ceiling and visibility is reported as OK




Type Notes

prevailingVisibilityOperator

[0..1] RelationalOperator The reported relational operator for the prevailing horizontal visibility. When reported, this operator is reported in conjunction with prevailing visibility.



E.2.4 TAFReportStatus

Type: Enumeration.

Notes: The report status for a TAF report (e.g., a normal issuance, an amendment of an earlier report, a cancellation of an earlier report)


Type Notes

NORMAL [1] An normal issuance of a TAF




Type Notes

AMENDMENT [1] An amendment of an earlier TAF

CANCELLATION [1] A cancellation of an earlier TAF

CORRECTION [1] A correction of an earlier TAF

MISSING [1] The report is missing ("NIL" from ICAO Annex 3 / WMO No. 49)

E.2.5 AerodromeForecastChangeIndicator

Type: Enumeration.

Notes: The forecast change indicator type, including temporary, permanent, or probable conditions. This is an extension of ForecastChangeIndicator that includes report-specific entries, and in particular the 30 and 40% probability conditions.

Note that the TAC representations for "FM", "TL", and "AT" are represented by the phenomenonTime on the change forecast (MeteorologicalAerodromeForecast):

FM and TL - a phenomenonTime with a TimePeriod (start is FM and end is TL)

TL - a phenomenonTime with a TimePeriod (start is beginning of forecast validity and end is TL)

FM - a phenomenonTime with a TimePeriod (start is FM and end is end of forecast validity)



AT - a phenomenonTime with a TimeInstant

Design note:

These values represent the operationally-representable types, but are not very general-purpose. Especially with temporary conditions and probability it might be better to turn these into a "probability" property and constraints could be applied to the value to match operational constraints


Type Notes

BECOMING [1] Conditions are expected to reach or pass through specified threshold values at a regular or irregular rate and at an unspecified time during the time period. The time period should normally not exceed 2 hours but in any case should not exceed 4 hours.


"BECMG"

TEMPORARY_FLUCTUATIONS [1] Expected temporary fluctuations to meteorological conditions which reach or pass specified threshold criteria and last for a period of less than one hour in each instance and in the aggregate cover less than half of the forecast period during which the fluctuations are expected to occur.




"TEMPO"

FROM [1] One set of prevailing weather conditions is expected to change significantly and more or less completely to a different set of conditions. Conditions in a FROM group supersede conditions in earlier groups.


"FM"

PROBABILITY_30 [1] A 30% probability of occurrence of an alternative value of a forecast element or elements.


"PROB30"

PROBABILITY_30_ TEMPORARY_ FLUCTUATIONS [1] A 30% probability of occurrence of temporary conditions of an alternative value of a forecast element or elements.




"PROB30 TEMPO"

PROBABILITY_40 [1] A 40% probability of occurrence of an alternative value of a forecast element or elements.


"PROB40"

PROBABILITY_40_ TEMPORARY_ FLUCTUATIONS [1] A 40% probability of occurrence of temporary conditions of an alternative value of a forecast element or elements.


"PROB40 TEMPO"

E.2.6 AerodromeAirTemperatureForecast

Type: Class.



Notes: An aggregation of air temperature forecast conditions typically reported together at an aerodrome, including the minimum and maximum anticipated air temperatures and when they occur.

AerodromeAirTemperatureForecast is only reported on base conditions on a TAF, not change forecasts.


Type Notes

maximumAirTemperature [1] Measure The maximum air temperature


"TX"

maximumAirTemperatureTime [1] TM_Instant The time of occurrence of the maximum air temperature. This must be within the period of the phenomenon time for this forecast record


"TX"



minimumAirTemperature [1] Measure The minimum air temperature


"TN"

minimumAirTemperatureTime [1] TM_Instant The time of occurrence of the minimum air temperature. This must be within the period of the phenomenon time for this forecast record


"TN"



ANNEX F: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR THE ICAO METEOROLOGICAL INFORMATION EXCHANGE MODEL (IWXXM), SIGMET

F.1 Introduction

The authoritative version of IWXXM is maintained within AvXML as an online resource at the following URL: http://wis.wmo.int/AvXML/AvXML-1.1/index.htm http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0- Release&pagenum=2#UML_Model. (N.B.: There are no whitespace characters in the URL.) What follows is abridged to suit the needs of the print medium.

F.2 The SIGMET Lleaf of IWXXM

Notes:The SIGMET leaf of the ICAO Meteorological Information Exchange Model (IWXXM) models the SSIGMET reporting constructs as defined in ICAO Annex 3 / WMO No. 49-2.

SIGMETs report the occurrence and/or expected occurrence of specified en-route weather phenomena which may affect the safety of aircraft operations, and of the development of those phenomena in time and space. These weather phenomena are reported as impacted regions of airspace.

F.2.1 SIGMET

Type: Class.

Notes: A SIGMET (significant meteorological) report. SIGMETs report the occurrence and/or expected occurrence of specified en-route weather phenomena which may affect the safety of aircraft operations, and of the development of those phenomena over time.






The SIGMET report class represents the base SIGMET types that may be reported such as squall lines, thunderstorms, dust storms, turbulence, etc. Tropical cyclone and volcanic ash SIGMET reports are subclasses of SIGMET due to their ability to report additional information, including volcano/tropical cyclone identification and forecast position(s).

SIGMETs may report either observed or forecast hazardous conditions. Additionally, a forecast position may be reported.


Type Notes

analysis [0..*] SIGMETEvolvingConditionAnalysis SIGMETs may include the same phenomenon covering more than one area within the FIR/UIR/CTA, as well as observed and forecast conditions for each of these reported areas. All combinations of observations and forecasts of meteorological conditions, including changing conditions, are represented by their own SIGMETEvolvingMeteorologicalCondition.

Each analysis has a single EvolvingMeteorologicalCondition as its result.




Type Notes

cancelledSequenceNumber [0..1] CharacterString The cancelled SIGMET sequence number. Mandatory when this is a cancellation report, must be missing otherwise

Examples:

YUDD SIGMET 2 VALID ...

YUDD SIGMET A3 VALID ...

cancelledValidPeriod [0..1] TM_Period The valid period of a previous SIGMET that is cancelled by this SIGMET. Mandatory when this is a cancellation report, must be missing otherwise

forecastPositionAnalysis [0..1] SIGMETPositionAnalysis One or more forecast positions at the end of the valid period - one for each phenomenon area within an FIR. These are modeled as a single OM_Observation sub-type with a feature collection result due to the shared time and other observation metadata for all forecast positions.




Type Notes

issuingAirTrafficServicesUnit [1] Unit The ATS unit serving the FIR or CTA to which the SIGMET refers


A6-1: "Location indicator of FIR/CTA"

OriginatingMeteorologicalWatchOffice [1] Unit MWO originating this report

phenomenon [1] AeronauticalSignificantWeatherPhenomenon The reported phenomenon, such as thunderstorm, tropical cyclone, icing, mountain wave, etc.

The expected end of occurrence of volcanic ash ("NO VA EXP") is indicated with a missing SIGMET phenomenon with a nil reason of nothingOfOperationalSignificance

sequenceNumber [1] CharacterString The sequence number of this message. For example: "5", "A3", or "2"

status [1] SIGMETReportStatus The SIGMET report status - cancelled or normal




Type Notes

validPeriod [1] TM_Period The valid period for the entire report, including all observations and forecast conditions. Each observation/forecast phenomenon includes its own period of validity for described meteorological conditions, which is represented as the O&M Observation validTime.

For example, an issued tropical cyclone SIGMET may be valid from 1600 UTC to 2200 UTC with an observed position at 1600 UTC and a forecast position of the centre of the tropical cyclone at 2200 UTC. In this case the SIGMET validPeriod would be 1600 UTC to 2200 UTC, the analysis validTime would be 1600 UTC, and the forecastPositionAnalysis validTime would be 2200 UTC.



F.2.2 TropicalCycloneSIGMET

Type: Class.

Notes: A SIGMET that reports the presence of a tropical cyclone conditions. This extends the base SIGMET type by including additional information necessary for tropical cyclones.


Type Notes

tropicalCyclone [1] TropicalCyclone The tropical cyclone being reported in this SIGMET

F.2.3 VolcanicAshSIGMET

Type: Class.

Notes: A SIGMET that reports the presence of volcanic ash conditions hazardous to flight. This extends the base SIGMET type by including additional information necessary for volcanoes and volcanic ash.


Type Notes

eruptingVolcano [1] Volcano The volcano that is erupting



F.2.4 SIGMETEvolvingConditionAnalysis

Type: Class.

Notes: A specialized OM_Observation type used for reporting an aggregate set of meteorological conditions hazardous to flight over a large airspace, including anticipated characteristics. The result of this observation type refers to a single EvolvingMeteorologicalCondition which represents a SIGMET observation or forecast of meteorological conditions.



F.2.5 EvolvingMeteorologicalCondition

Type: Class.

Notes: Conditions that indicate the presence of a specific SIGMET phenomenon such as volcanic ash or a thunderstorm, along with expected changes to the phenomenon such as intensity, speed, and direction. These conditions are reported with OBS/FCST conditions on all SIGMET types.

TC TOP (ABV and BLW) conditions are represented by the vertical component of the geometry. For example: CB TOP FL500 is represented as a missing lowerLimit and an upperLimit of 500FL.


Type Notes

directionOfMotion [0..1] Angle The expected direction of movement of a meteorological condition. When no movement is expected, this is a http://www.opengis.net/def/nil/OGC/0/inapplicable nilReason and the speedOfMotion will be 0.

geometry [1] AirspaceVolume The expected geographic region affected by the reported phenomenon at a particular time (thunderstorms, volcanic ash, etc.). This geometry covers all combinations of phenomenon historically reported in ICAO Annex 3 / WMO No. 49-2: a boundary with a base and top, a TC center position, and a VA line with a width

http://www.opengis.net/def/nil/OGC/0/inapplicable




Type Notes

intensityChange [1] ExpectedIntensityChange The expected change in intensity for the reported meteorological condition (e.g., intensifying, weakening, or no change) determined at the time of SIGMET analysis based on the current state of the meteorological condition

speedOfMotion [1] Velocity The expected speed of movement of a meteorological condition. When no movement is expected, this will have a value of 0 and directionOfMotion will have a http://www.opengis.net/def/nil/OGC/0/inapplicable nilReason.

F.2.6 SIGMETPositionAnalysis

Type: Class.

Notes: A specialized OM_Observation type used for reporting the forecast position of meteorological conditions hazardous to flight. The result of this observation type refers to one or more MeteorologicalPositions which represents the forecast positions of SIGMET phenomena.

http://www.opengis.net/def/nil/OGC/0/inapplicable



F.2.7 MeteorologicalPositionCollection

Type: Class.

Notes: A collection of MeteorologicalPositions, each representing a location where meteorological conditions exist. All members of this collection are of type MeteorologicalPosition.

F.2.8 MeteorologicalPosition

Type: Class.

Notes: Conditions that indicate the presence of a specific SIGMET phenomenon such as volcanic ash or a thunderstorm. Used to represent the forecast positions of SIGMET phenomena.

TC TOP (ABV and BLW) conditions are represented by the vertical component of the geometry. For example: CB TOP FL500 is represented as a missing lowerLimit and an upperLimit of 500FL.

In cases where the position covers an entire FIR or CTA, ("ENTIRE CTA or ENTIRE FIR" from ICAO Annex 3 / WMO No. 49-2) the geometry should be an xlink to the sampled feature for this SIGMET.




Type Notes

geometry [1] AirspaceVolume The geographic region affected by the reported phenomenon at a particular time (thunderstorms, volcanic ash, etc.). This geometry covers all combinations of phenomenon historically reported in Annex 3: a boundary with a base and top, a TC center position, and a VA line with a width

F.2.9 ExpectedIntensityChange

Type: Enumeration.

Notes: Expected change in intensity for (significant) meteorological phenomena.

See WMO No. 306 Vol I.2 Part B FM 94 BUFR code-table 0 20 028 'Expected change in intensity'.


Type Notes

NO_CHANGE [1] No change (NC)

WEAKEN [1] Forecast to weaken (WKN)

INTENSIFY [1] Forecast to intensify (INTSF)



F.2.10 SIGMETReportStatus

Type: Enumeration.

Notes: The status of a SIGMET report (e.g., a normal issuance, a cancellation of an earlier SIGMET)


Type Notes

NORMAL [1] A normal SIGMET report (not a cancellation)

CANCELLATION [1] A cancellation of an earlier SIGMET report

F.2.11 AeronauticalSignificantWeatherPhenomenon

Type: Class.

Notes: Weather phenomenon of significance to aviation operations; used in SIGMET and AIRMET reports. The set of permitted options are defined in ICAO Annex 3 / WMO No. 49-2 C.3.1 sub-clause 1.1.4



ANNEX G: ABRIDGED CLASS DEFINITIONS AND CONTEXT DIAGRAMS FOR THE ICAO METEOROLOGICAL INFORMATION EXCHANGE MODEL (IWXXM), COMMON

G.1 Introduction

The authoritative version of IWXXM is maintained within AvXML as an online resource at the following URL: http://www.wmo.int/pages/prog/www/WIS/wiswiki/tiki-index.php?page=AvXML-1.0-Release&pagenum=2#UML_Model http://wis.wmo.int/AvXML/AvXML-1.1/index.htm. (N.B.: There are no whitespace characters in the URL.) What follows is abridged to suit the needs of the print medium.

G.2 The Common leaf of IWXXM

Notes: CThe Common leave of the ICAO Meteorological Information Exchange Model (IWXXM) models common constructs used across multiple packages. This package includes constructs closely related to the aviation weather domain.

G.2.1 AerodromeCloudForecast

Type: Class.

Notes: Forecast cloud conditions, including predicted vertical visibility and cloud layers.

A single vertical visibility may be reported, but cannot be reported with cloud layers.


Type Notes

verticalVisibility [0..1] Distance The vertical visibility. Vertical visibility is defined as the vertical visual range into an obscuring medium.





G.2.2 CloudLayer

Type: Class.

Notes: A cloud layer, including a cloud amount, cloud base and cloud type


Type Notes

amount [1] CloudAmountReportedAtAerodrome The observed cloud amount

base [1] DistanceWithNilReason For a given cloud or cloud layer, height of the lowest level in the atmosphere at which the air contains a perceptible quantity of cloud particles.

cloudType [0..1] SigConvectiveCloudType The observed significant cloud types: cumulonimbus or towering cumulus

G.2.3 CloudAmountReportedAtAerodrome

Type: Class.

Notes: Amount of cloud - assessed by category.

This CodeList is specifically defined for aviation purposes, as defined in WMO No. 49-2. A superset of cloud-amount categories are defined in WMO No. 306 Vol I.2 FM 94 BUFR code-table 0 20 008 "Cloud distribution for aviation".



G.2.4 SigConvectiveCloudType

Type: Class.

Notes: Genus of cloud of operational significance to aviation: significant convective clouds only.

This CodeList is specifically defined for aviation purposes, as defined in WMO No. 49-2. A superset of definitions are defined in WMO No. 306 Vol I.2 FM 94 BUFR code-table 0 20 012 "Cloud type".

G.2.5 AerodromeSurfaceWindTrendForecast

Type: Class.

Notes: A trend forecast of surface wind conditions at an aerodrome.


Type Notes

meanWindDirection [0..1] Angle The forecast average wind direction from which wind is blowing

meanWindSpeed [1] Velocity The forecast average wind speed

windGustSpeed [0..1] Velocity The forecast maximum speed of a gust.



G.2.6 AerodromeSurfaceWindForecast

Type: Class.

Notes: A forecast of wind conditions at an aerodrome.

This extends AerodromeSurfaceWindTrendForecast to allow for a variable wind direction to be reported. This class differs from a aerodrome wind observation in that the observations may include a min/max directional variability. This class only carries a true/false indication that it will be variable.


Type Notes

variableWindDirection [1] Boolean Indicates variable wind direction. Cannot be reported with a mean wind direction

G.2.7 AerodromeForecastWeather

Type: Class.

Notes: AerodromeForecastWeather enables the forecast weather at an aerodrome to be reported.


This ?CodeList? is specifically defined for aviation purposes as defined in WMO No. 49-2. A superset of definitions are defined in WMO No. 306 Vol I.1 code-table 4678 "Significant weather phenomena".



G.2.8 RelationalOperator

Type: Enumeration.

Notes: RelationalOperator defines the restricted set of operators that may be specified alongside numerical quantities in ICAO Annex 3/WMO No. 49.

These operators are used in cases where a precise value is not measurable, not precisely known due to measurement limitations, or not reported due to reporting restrictions.

For example, the "above" operator in conjunction with the reported quantity 10.6 indicates that the actual physical quantity is above 10.6 (at least 10.6).


Type Notes

ABOVE [1] The actual value is above the maximum value that can be determined by the system ("ABV", "P")

BELOW [1] The actual value is below the minimum value that can be determined by the system ("BLW", "M")



ANNEX H: METHODS FOR GENERATING DATA REPRESENTATIONS FROM UNIVERSAL MODELLING

LANGUAGE (UML)

H.1 INTRODUCTION

TT_AvXML spent a substantial level of effort developing a repeatable set of “mostly automated” procedures that successfully generated XML schemas from UML. These procedures were presented at the first meeting of the WMO’s Inter-Programme Expert Team on Metadata and Data Representation Development (IPET-MDRD) as Discussion Paper D24. A subsequent paper, D25, presented information on alternatives to these procedures which were still in development. Both papers can be downloaded from the WMO website. D24 is at http://wis.wmo.int/file=903 and D25 is at http://wis.wmo.int/file=949.

Discussion Paper D24 of IPET-MDRD-1 follows in its entirety. Both papers refer to the process as a “serialization procedure.”

http://wis.wmo.int/file=949

http://wis.wmo.int/file=903



OVERVIEW OF SERIALIZATION PROCEDURE FROM APPLICATION SCHEMA (UML) TO GML SCHEMA (XML SCHEMA)INTRODUCTION1. TT-AvXML at its first meeting (TT-AvXML-1) considered it essential to have a tool to

automatically transform the AvXML logical data model in UML into the corresponding physical model in XML to ensure consistency and integrity of the conversion products.

[2.] Historically, Enterprise Architect (EA) is being used for the development of the UML model and FullMoon has been chosen for the automatic transformation of the UML model into XML schema for AvXML-1.0.

2.[3.] For compatibility reasons, EA Version 9 Build 9.3.932 and FullMoon Version 2302 are being used for the transformation.

PRE-REQUISITES1. EA with Solid Ground Toolset from CSIRO1. This provides ISO 191xx profiled UML elements

to be used during modelling. This should be installed before development of the GML application or importing of the respective XMI file into EA.

2. FullMoon with patches and scripts developed by HKO. These fix a number of bugs, implement new transformation behaviour2 and streamline transformation. An Oracle VirtualBox disk image containing FullMoon with the patches applied and associated script/software configured on Ubuntu is available.

3. Oxygen XML Developer, Apache Tomcat 6.0 and scripts developed by HKO for post-processing of XSD files generated.

PROCEDURES1. Create GML application packages

a) Import ISO TC 211 UML model in XMI format into EA. The latest version can be downloaded from the ISO/TC211 Harmonized Model Web server3.

b) Develop GML application packages on or import packages in XMI format into EA. Ensure that the packages complies with the ISO 19100 series Application Schema profile, in particular the GML stereotypes and tagged values should be appropriately set4 (see Appendix A).

1 See https://wiki.csiro.au/display/solidground/Solid+Ground+Toolset

2 See Doc (13) of TT-AvXML-3 at http://wis.wmo.int/file=529 for details

3 See http://www.isotc211.org/hmmg/EArchitect/

4 Apart from the stereotypes and tagged values, there are also known problems if sequence numbers, directed associations and aggregations are not properly assigned.



c) Ensure that any class in the model has a dependent association to another model (see Figure 1). The process of creating these package associations can be automated through the use of Solid Ground function “Generate Package Dependencies Diagram”. Prior to using this function any existing package associations of the model should be deleted.

d) Publish model packages individually in XMI format with options (a) XML Type: UML 1.3 (XMI 1.1) and (b) General options: Export Diagrams, Format XML Output (see Figure 2). Confirm the code page in XML specifications is “utf-8” (see Figure 3).

2. Transform the GML application packages

Figure 1

Figure 3Figure 2

Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1Figure 1

Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2Figure 2 Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3Figure 3



a) Copy the exported XMIs to the VirtualBox Virtual Machine. Edit the configuration file for the automation script as necessary.

(Using OPM of AvXML as an example)

Copy the exported OPM XMI “wmo-opm.xml” to “/home/user/fullmoon_2302/resources/xmi-samples”

Uncomment the parts corresponding to OPM in “/home/user/fullmoon_2302/deploy-config/properties/fullmoon.properties”

Execute “cd /home/user/fullmoon_2302; ant deploy-all”

b) Confirm packages are in conformance to the (modified) standards with FullMoon’s conformance test feature


Execute “cd to /home/user/fullmoon_2302/bin; ant –f run.xml init-then-add; ant –f run.xml test”

The package conforms to the standards if output failed=0

c) In hierarchal order

i. Transform the package with FullMoon


Execute “cd to /home/user/fullmoon_2302/bin; ant –f run.xml exec-enc-and-export-then-copy”

The output XSD files are located at “/home/user/Desktop/Schema-local”

ii. Create class map of the transformed output and feed into FullMoon if this package is required by subsequent packages




Copy the XSD files from the virtual machine at “/home/user/Desktop/Schema-local” to “Drive:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/fullmoon-required/wmo/opm”

Drag “GenerateFromXSDV4.xsl” to the Oxygen XML Developer

Modify “target-process” variable to opm

Modify “classmap-location” path to Tomcat installation directory

Create a new XSLT scenario if not existed

o XML URL: full path to “start.xml”

o XSL URL: full path to “GenerateFromXSDV4.xsl”

o Transformer: Saxon-HE x.x.x.x

Run the transformation

Copy “ClassMap_opm.xml” back to virtual machine “/home/user/apache-tomcat-6.0.36/webapps/fullmoon-required/ClassMaps/WMO”

iii. Repeat until all packages have been transformed

3. Post-process the resulting XSD files

a) Insert schematron rules into the XSD files

b) Apply other modifications to the XSD files, including a change of schema locations from local to global and other documentation changes


Copy the directory containing XSD files “/home/user/Desktop/Schema-local” from the virtual machine to a place accessible by Oxygen XML Developer and renamed it to “Schema-local-emb-sch”

Drag “schematron-mixV2.xsl” to Oxygen XML Developer

Modify the path under CONFIG variables and point to folder “Schema-local-emb-sch”



Create a new XSLT scenario if not existed

o XML URL: full path to start.xml

o XSL URL: full path to schematron-mixV2.xsl

o Transformer: Saxon-HE x.x.x.x

Run the transformation

Repeat with other XSLT documents, viz:

o “schematron-mixV2.xsl” (for injecting schematron and embedded schematron to xsds)

o “appinfo-doc.xsl” (for injecting vocabulary, extensibility and quantity to documentation)

o “correct_import.xsl” (for turning local schema to public schema)

o “RemoveOMSub.xsl” (for replacing OMSub classes with “XXX and relevant components removed” in comment)

o “AddDocumentation.xsl” (for adding “References to WMO and ICAO Tech….” documentation)

o “self-close-fix.xsl” (for beautifing the empty tag to self-close tag)

RECOMMENDED TEXT 1. IPET-MDRD noted the procedures described in “Overview of Serialization Procedure from

Application Schema (UML) to GML Schema (XML Schema)” (Doc 24) and asked the Secretariat to store this so that it was available to those developing future releases of the XML schemas.

--------------------



ANNEX H APPENDIX A: UML STEREOTYPES AND TAGGED VALUES FOR GML APPLICATION SCHEMASSummary of GML stereotypes*

The first set of stereotypes corresponds primarily the set described in Table E.1 of ISO 19136:2007 (GML 3.2.1), and are suitable for a domain model that is ready for direct conversion to XML as a GML Application Schema.

Stereotype name Scope Use XML Implementation

«Application Schema» «applicationSchema»

Package Complete application schema An XML Schema in a single XML namespace

«FeatureType» «featureType»

Class Feature-type XML element whose XML Schema-type is derived from gml:AbstractFeatureType

noStereotype «Type» «type»

Class Referenceable objects other than features XML element whose XML Schema-type is derived from gml:AbstractGMLType

«DataType» «dataType»

Class Structured data type XML element with a complex content model; does not have identity and must appear inline

«Union» «union»

Class Arbitrary set of alternative classes Choice group whose members are GML Objects or Features, or objects corresponding to DataTypes

«CodeList» «codeList»

Class Extensible enumeration Union of an enumeration of string values and a pattern

** Extracted from SEE GRID Community website of CSIRO at https://www.seegrid.csiro.au/wiki/AppSchemas/UmlGmlStereotypesAndTaggedValues

https://www.seegrid.csiro.au/wiki/bin/view/AppSchemas/UmlGmlStereotypesAndTaggedValues?sortcol=3;table=1;up=0#sorted_table






«Enumeration» «enumeration»

Class Fixed enumeration Enumeration of string values

Some additional stereotypes have been found useful in domain modelling. These are packaged as a separate "UML Profile" for use in the HollowWorld environment.

Stereotype name Scope Use XML Implementation

«Leaf» Package Convenient group of elements within an application schema

Single XML Schema document

«PrimitiveType» Class Structured data type Class which has a "canonical" pre-defined XML encoding

«property» attribute, associationRole

property local element (a) having a simple type (b) containing a complex type, or (c) using the GML in-line or by-reference pattern

A set of tagged-values is prescribed for each stereotype, to specify information required for the XML implementation derived from the model. See GML stereotypes and associated tagged values for more detail.







ISO GML stereotypes and associated tagged values*

NOTE: Tag usage is described in ISO 19136:2007 Annex E, except for tags in italics which relate to proposed extensions to the standard . Tags in bold are mandatory.

UML element GML Application Schema implication UML Tagged values

All elements documentation=string

The first group of UML elements are related to packaging and namespaces

Package The default mapping is one W3C XML Schema document per package

targetNamespace=anyURI xmlns=NCName xsdDocument=string version=string

«Application Schema» Components in a single XML Namespace targetNamespace=anyURI xmlns=NCName xsdDocument=string version=string

«Leaf» Components described in a single W3C XML Schema Document

xsdDocument=string

The second group of elements are classes carrying various stereotypes

Classes in the first group are implemented as global XML Schema Type Definitions. They are used to define content models for XML elements

** Extracted from SEE GRID Community website of CSIRO at https://www.seegrid.csiro.au/wiki/AppSchemas/UmlGmlStereotypesAndTaggedValues

https://www.seegrid.csiro.au/wiki/bin/edit/AppSchemas/W3C?topicparent=AppSchemas.UmlGmlStereotypesAndTaggedValues







representing simple properties

«Enumeration» Type defined as a restriction of W3C XML Schema string with enumeration values

«CodeList» Type defined as the union of an enumeration and a string pattern "other:value", or a reference to a dictionary the tags in italics are mandatory for FullMoon processing when asDictionary=true

asDictionary=boolean default="false"codeSpace=anyURI dictionaryIdentifier=anyURI memberIdentifierStem=anyURI

Classes in the next group are implemented as global XML Schema element declarations, supported by global XML Schema Type Definitions. The substitutionGroup affiliation is the element representing the parent class. Note: Abstract classes have the abstract attribute set "true"

«DataType» Global element with a complexType whose content model is normally implemented as a <sequence> of elements representing the properties

noPropertyType=boolean default="false"byValuePropertyType=boolean default="false"

«Type»or no stereotype

Global element with a complexType whose content model is a <sequence> of elements representing the properties. The type definition is immediately or transitively derived from AbstractGMLType, else if xmlSchemaType has a value it has a special implementation as the given XML Schema type

noPropertyType=boolean default="false"byValuePropertyType=boolean default="false"xmlSchemaType=QName

«FeatureType» Global element with a complexType whose noPropertyType=boolean default="false"

https://www.seegrid.csiro.au/wiki/bin/view/AppSchemas/FullMoon




content model is a <sequence> of elements representing the properties. The type definition is immediately or transitively derived from AbstractFeatureType

byValuePropertyType=boolean default="false"

Other class types

«Union» Named choice-group whose members are GML Objects or Features, or objects corresponding to DataTypes

noPropertyType=boolean default="false"

Properties

Attribute Local element within the content model (i.e. the complexType definition) of a DataType, ObjectType or FeatureType* the name of the property is given by the attribute name* when the UML type of the attribute is a class stereotyped «Enumeration» or «CodeList», the type of the property element is the XML Schema type mapped to the attribute type or target class* when the UML type of the attribute is a class stereotyped «DataType», the property element has a complexType following the "inline" pattern described in GML 3.2 clause 7, that contains the element with the name of the target class * when the UML type of the attribute is a class stereotyped «Type» or «FeatureType», the

inlineOrByReference=(inline,byReference,inlineOrByReference) default="inlineOrByReference" sequenceNumber=integer isMetadata=boolean default="false" ownedBy=string



property element has a complexType following the standard by-value or by-reference pattern described in GML 3.2 clause 7

Association end Local element within the content model (i.e. the complexType definition) of a DataType, Type or FeatureType* the name of the property is given by the roleName on the target end of a navigable association* when the UML type of the association target is a class stereotyped «DataType», the property element has a complexType following the "inline" pattern described in GML 3.2 clause 7, that contains the element with the name of the target class * when the UML type of the association target is a class stereotyped «Type» or «FeatureType», the property element has a complexType following the standard by-value or by-reference pattern described in GML 3.2 clause 7

inlineOrByReference=(inline,byReference,inlineOrByReference) default="inlineOrByReference" sequenceNumber=integer isMetadata=boolean default="false" isCollection=boolean default="false" ownedBy=string

METCE GML stereotypes and associated tagged values



UML element GML Application Schema implication UML Tagged values

«CodeList» Transformation serializes «CodeList» Type to XSD as:

<element name="{Class.Name}" type="{ApplicationSchema.xmlns}:{Class.Name}Type"/>

<complexType name="{Class.Name}Type">

<annotation>

<appinfo>

<vocabulary>{Class.TaggedValues.vocabulary.value}</vocabulary>

<extensibility>{Class.TaggedValues.extensibility.value}</extensibility>

</appinfo>

<documentation>

{Class.Notes}

</documentation>

</annotation>

<complexContent>

xsdEncodingRule=

”iso19136_2007_METCE_Extension”

asDictionary=”true”

vocabulary and extensibility are not empty






<extension base="gml:ReferenceType"></extension>

</complexContent>

</complexType>

«Type»

«DataType»

«FeatureType»

Transformation serializes UML attributes of the types to XSD attribute as:

<attribute name="{Attribute.Name}" type="{Attribute.Type.Namespace}:{Attribute.Type}"/>

xsdEncodingRule=


xsdAsAttribute=”true”

«Type»

«DataType»

Transformation serializes UML attributes of the types to XSD elements as:

<element name="{Attribute.Name}" type="{Attribute.Type.Namespace}:{Attribute.Type}">

<annotation>

<appinfo>

<quantity>{Attribute.TaggedValues.quantity.value}</quantity>

</appinfo>

<documentation>{Attribute.Notes}</documentation>

</annotation>

xsdEncodingRule=


quantity not empty



</element>

«Type» Transformation add “nilReason” attribute to the complexType as:

<attribute name="nilReason" type="gml:NilReasonType"/>

xsdEncodingRule=


Nillable=”true”

guidelines for data modeling for wmo codeswgds/...manual-codes-mo… · web viewdata modeling for...

Documents