Report to ICAO MARIE-PT from WMO TT-AvXML

Jeremy Tandy(Feb 2012)

1

2

Understanding of ICAO requirement

Urgency is required on the specification of XML/GML Schema for TAF, METAR/SPECI and SIGMET (VA SIGMET, TC SIGMET & WS SIGMET) to support Amendment 76 to ICAO Annex 3 (WMO No. 49): (for States in a position to do so) permitting bilateral exchange of OPMET data via XML.

Aviation community seek to harmonise data exchange technology around GML/XML to reduce overall cost-base of ATM / SWIM system.

Additional pressures beyond those of ATM /SWIM exist for adopting GML/XML. Commercial entities worldwide have long desired provision of weather data encoded in widely-used, vendor neutral formats.

Target delivery date for XML schema to support Amendment 76: July 2012.

ICAO shall own the MET information Logical Data Model from which the XML schema is derived.

¿WXXM2.0 shall be baseline input to ICAO MET information Logical Data Model?Use of WXXM2.0 implies a dependency on ISO 19156 Observations and Measurements

3

Distributed governance: importing WMO Logical Data Model ‘generic weather’ packages

ICAO MET information Logical Data Model will build on many generic meteorological concepts.

Such generic ‘weather’ Classes and Concepts will be re-used across other domains.

Generic weather Classes shall be managed by WMO – importing definitions from ISO/TC 211 reference models and existing WMO Codes.

WMO shall publish a ‘Generic MET information’ Logical Data Model (WMO Logical Data Model) that contains generic meteorological definitions for use in other (non-aviation) domains / industries.

WMO is committed to maintaining the ‘Generic MET information’ Logical Data Model to support ICAO requirements. Broader exploitation of the Logical Data Model shall be debated at WMO Commission for Basic Systems [CBS] (Sept 2012).

ICAO MET information Logical Data Model should import Packages as necessary from WMO Logical Data Model – in the same manner as ICAO information models import Packages from ISO/TC 211 reference models.

4

Conversion to XML/GML schema

WMO shall own the Physical Data Model (e.g. the XML Schema). ¿WXXS?

ISO19136 (GML) provides rules for conversion of Application Schema to XML/GML Schema.

‘Application Schema’ is ISO/TC 211 parlance for Logical Data Model.

WXXS shall be automatically derived from ICAO MET information Logical Data Model.

WMO shall identify software tools that enable automated conversion from ICAO Met information Logical Data Model and underpinning WMO ‘generic weather’ Logical Data Model to XML Schema. The ‘Fullmoon’ application is currently being investigated.

5

Outline process

1. WMO _LOGICAL DATA MODEL_ shall be inferred from the TDCF and maintained in synchronisation

2. WMO shall derive XSD from WMO _LOGICAL DATA MODEL_ using an automated process such as Fullmoon

3. ICAO MET information _LOGICAL DATA MODEL_ should import packages from WMO _LOGICAL DATA MODEL_ as appropriate

4. ICAO MET information _LOGICAL DATA MODEL_ shall compose Classes and Datatypes imported from WMO _LOGICAL DATA MODEL_ into (new) locally defined Classes

5. On behalf of ICAO, WMO shall derive XSD from ICAO MET information _LOGICAL DATA MODEL_ - importing WMO XSD as necessary (WMO owns WXXS)

Defining the WMO Logical Data Model

6

© Crown copyright Met Office

WMO’s World Weather Watch Programme combines observing systems, telecommunication facilities, and data-processing and

forecasting centres to support weather prediction … time & safety critical

8

WMO Regulation

The successful facilitation of free and unrestricted exchange of data and

information, products and services in real- or near-real time throughout

the WMO community is due to strong governance

Procedures; i.e. Manual on GTS & Manual on Observing

Data formats; i.e. Manual on Codes

WMO has created a SUSTAINABLE infrastructure wherein regulation is

MAINTAINED

9

Manual on Codes

The Code-Tables underpinning WMO Table-Driven Code Forms (GRIB and BUFR) are WMO’s crown jewels …

Decades of expert effort have gone into establishing authoritative

terminologies to describe meteorological phenomena

10

WMO TDCF:

authoritative definitions for meteorologyWMO Code-Tables combine authoritative

definitions with encoding information – e.g. unit of measure and precision (derived from

‘scale’, ‘reference value’ and ‘data width (bits)’

(note: this approach is at variance with WXXM / GML where the unit of measure and

precision is not prescribed in the Schema)BUFR Code Table B – Class 12

Generalized Coordinates

Significance Qualifiers

Measures

WMO TDCF: BUFR Table B

11

WMO TDCF:

BUFR Templates for OPMET dataBUFR Code Table D – Category 07 “Surface Report Sequences (Land)”

BUFR Code Table D – Category 16 “Synoptic Feature Sequences”

12

1313

Analysis of BUFR Templates based on the

incidence of Generalised

Coordinates and Significance Qualifiers can be used to define modular components

14

class D07-051_METAR-SPECI (sympathetic model of BUFR Table D Sequence)

[d]D07-303_METAR-SPECI_Product

- weatherIndicator: B20-009_WeatherIndicator- prevail ingVisbil ity: B20-060_PrevailingVisibil ity- presentSignificantWx: B20-019_PresentWeather [0..3]- verticalVisibil ity_m: B20-002_VerticalVisibil ity_m- verticalVisibil ity_ft: B20-091_VerticalVisibil ity_ft- recentSignificantWx: B20-020_RecentWeather [0..3]- runwayShear: B11-070_WindShearAffectedRunway [0..4]- runwayState: B20-085_RunwayCondition [0..1]

D07-307_WindSpeedGroup

- windSpeed_kmh-1: B11-083_WindSpeed_kmh-1- windSpeed_knots: B11-084_WindSpeed_knots- windSpeed_ms-1: B11-002_WindSpeed_ms-1

«modifier»- windSpeedQualifier: B08-054_WindSpeedOrGustQualifier

D07-308_WindGustGroup

- maxWindSpeed_kmh-1: B11-085_MaxWindSpeed_kmh-1- maxWindSpeed_knots: B11-086_MaxWindSpeed_knots- maxWindSpeed_ms-1: B11-041_MaxWindSpeed_ms-1

«modifier»- windGustQualifier: B08-054_WindSpeedOrGustQualifier

D07-302_DirectedMinVisibility

- minVisibil ity: B20-059_MinVisibil ity

«modifier»- direction: B05-021_Bearing

D07-306_RunwayVisualRange

- range: B20-061_RunwayVisualRange

«modifier»- qualifier: B08-014_RVRQualifier

D07-013_RunwayVisualRangeGroup

- rvrTendency: B20-018_RVRTendency

«modifier»- runway: B01-064_RunwayDesignator

D07-301_CloudGroup

- cloudAmount: B20-011_CloudAmount- cloudType: B20-012_CloudType- cloudBaseHeight_m: B20-013_CloudBaseHeight_m- cloudBaseHeight_ft: B20-092_CloudBaseHeight_ft

«modifier-Discriminator»- verticalSignificance: B08-002_VerticalSignificance

D07-049_SeaConditions

- waterTemperature: B22-043_WaterTemperature- waveHeight: B22-021_WaveHeight

[d]D07-305_RunwayConditionSummary

- condition: B20-085_RunwayCondition

«modifier-ID»- runway: B01-064_RunwayDesignator

[d]D07-304_RunwayConditionDetails

- deposits: B20-086_RunwayDeposits- contamination: B20-087_RunwayContamination- depthOfDeposit: B20-088_RunwayDepositDepth- frictionCoefficient: B20-089_RunwayFrictionCoefficient

«modifier-ID»- runway: B01-064_RunwayDesignator

D07-048_TrendForecast

- weatherIndicator: B20-009_WeatherIndicator- prevail ingVisbil ity: B20-060_PrevailingVisibil ity [0..1]- presentSignficantWx: B20-019_PresentWeather [0..3]- verticalVisibil ity_m: B20-002_VerticalVisibil ity_m- verticalVisibil ity_ft: B20-091_VerticalVisibil ity_ft

«modifier»- changeIndicator: B08-016_TrendForecastChangeQualifier

Category01_LocationAndIdentification::D01-301_ForecastTimeOfChange

- time: D01-012_Time

«modifier»- qualifier: B08-017_TimeQualifierForForecastedChange

D07-051_METAR-SPECI

«modifier»- icaoLocationIndicator: B01-063_ICAOLocationIdentifier- productStatus: B08-079_AviationProductStatus- stationType: B02-001_StationType- date: D01-011_Date- time: D01-012_Date- position: D01-023_position- stationHeight: B07-030_StationHeight

It seems odd that DesignatedRunwayCondition and RunwayConditionDetails have been factored out into 2 independent Classes; this is because of the way the replication factors are structured in BUFR Table D Sequence [3 07 051] - each group of replicated elements includes the runway designator.

This is a candidate for merging as the model evolves.

[d]D07-309_QNH

- qnh: B10-052_QNH

«modifier»- barometerHeight: B07-031_BarometerHeight

[d]D07-310_SpotTemperature

- temperature: B12-023_Temperature- dewpoint: B12-024_Dewpoint

«modifier»- temperatureSensorHeight: B07-032_SensorHeight

[d]D07-311_WindGroup

- windDirection: B11-001_WindDirection- variableWindDirectionCCW: B11-016_VariableWindDirectionCCW- variableWindDirectionCW: B11-017_VariableWindDirectionCW

«modifier»- windSensorHeight: B07-032_SensorHeight

barometerHeight attribute moved from top-level to apply directly to QNH section as it is the only element relating to pressure. However it should also be recognised that barometerHeight is another measure of station height for aviation purposes. So this may need to be reconsidered at a later stage.

Amendment to Gil 's model: trend forecast does not include variable wind direction elements

[d]D07-312_ForecastWindGroup

- windDirection: B11-001_WindDirection

«modifier»- windSensorHeight: B07-032_SensorHeight

+rvr 2

+windGroup

1

+product

1

+spotTemperature1

+windGroup 1

+windSpeedGroup 1

+windSpeedGroup 1

+windGustGroup 1

+stationPressure

1

+minVisibil ity

0..2

+timeGroup

0..2

+runwayVisualRange

0..4

+clouds 0..3

+clouds

0..3

+seaConditions 0..1

+runwayCondition 0..4

+runwayConditionDetail 0..4

+trendForecast

0..3+windGustGroup 1

METAR/SIGMET model derived from BUFR

OGC Met-Ocean Domain Working Group:

Conceptual Modelling

15

OGC

Met-Ocean DWG

INSPIRE Thematic Working Group:Atmospheric Conditions &

Meteorological Features

OGC Met-Ocean domain working group provided the forum for

development of a harmonized data model

for meteorology

Weather model convergence …

OGC Observations and Measurements (O&M2) ISO 19156 Geographic Information – Observations and measurements

16

Aviation

CF-conventions

netCDF

ISO19156 Observations and measurements

17

OM_Observation: an EVENT whose RESULT is an estimate of a value of some PROPERTY of some THING obtained using a specified

PROCEDURE …

18

12Z7-May 9-May8-May6-May5-May

00Z00Z12Z00Z12Z12Z00Z12Z 00Z

result

forecast : OM_Observation

parameter.name = “analysisTime”parameter.value = 2010-05-06T00:00ZphenomenonTime.begin = 2010-05-06T00:00ZphenomenonTime.end = 2010-05-09T12:00ZresultTime = 2010-05-06T04:30ZvalidTime [optional – not specified]resultQuality [optional – not specified]

ISO19156 Observations and measurements:also suitable for numerical simulations – including forecasts

OM_Process can describe a numerical

simulation to ESTIMATE a value in the future

(e.g. a FORECAST)

Describing the Observation procedure

class Procedure context

«FeatureType»observation::OM_Process

«FeatureType»SimpleProcess

- documentation: CI_Citation [0..*]- processParameter: NamedValue [0..*]

constraints{processParameter.name shall not be repeated}

Each Observation event shall be executed according to a specified Procedure.

The Procedure can range from a repeatable list of instructions through to a specific instrument (or numerical simulation) in a particular calibrated state.

Essentially, the Process object provides context regarding how one should interpret the Result.

The WMO Logical Data Model provides a SimpleProcess definition providing the barest minimum of information: (optional) documentation and (optional) configuration parameters for the process.

19

Relationship to the real-world: featureOfInterest & SamplingFeature

20

class DomainFeatures context

«FeatureType»Aerodrome

- icaoLocationIndicator: B01-063_ICAOLocationIdentifier [0..1]- name: CharacterString [0..1]- position: GM_Point [0..1]

«FeatureType»Runway

- runwayDesignator: B01-064_RunwayDesignator- extent: EX_GeographicExtent [0..1]

SF_SpatialSamplingFeature

«FeatureType»samplingPoint::SF_SamplingPoint

::SF_SpatialSamplingFeature+ positionalAccuracy:

DQ_PositionalAccuracy [0..2]::SF_SamplingFeature+ parameter: NamedValue [0..*]+ l ineage: LI_Lineage [0..1]

GM_Primitive

«type»Geometric primitiv e::GM_Point

+ position: DirectPosition

+aerodrome 1

+runway 0..*

Intention

+sampledFeature

1..*

Geometry

+shape

class DomainFeatures context

«FeatureType»Aerodrome

- icaoLocationIndicator: B01-063_ICAOLocationIdentifier [0..1]- name: CharacterString [0..1]- position: GM_Point [0..1]

«FeatureType»Runway

- runwayDesignator: B01-064_RunwayDesignator- extent: EX_GeographicExtent [0..1]

SF_SpatialSamplingFeature

«FeatureType»samplingPoint::SF_SamplingPoint

::SF_SpatialSamplingFeature+ positionalAccuracy:

DQ_PositionalAccuracy [0..2]::SF_SamplingFeature+ parameter: NamedValue [0..*]+ l ineage: LI_Lineage [0..1]

GM_Primitive

«type»Geometric primitiv e::GM_Point

+ position: DirectPosition

+aerodrome 1

+runway 0..*

Intention

+sampledFeature

1..*

Geometry

+shape

‘domain objects’ are related to the Observation via ‘featureOfInterest’ association

SamplingFeatures are used where the Observation is taken at a location that is purely an artefact of the

sampling regime (e.g. the location of a sensor platform within the boundary of an aerodrome)

Describing the Observed phenomenon

21

class Observ ableProperty context

«type»AbstractObservableProperty

- label: CharacterString [0..*]

«type»CompositeObserv ableProperty

- count: Integer

«type»Observ ableProperty

- basePhenomenon: GF_PropertyType- uom: UnitOfMeasure [0..1]

«dataType»StatisticalQualifier

- aggregationArea: Area [0..1]- aggregationLength: Length [0..1]- aggregationTimePeriod: TM_Duration [0..1]- aggregationVolume: Volume [0..1]- description: CharacterString [0..1]- statisticalFunction: ScopedName [0..1]- otherAggregation: Any [0..1]

«dataType»Constraint

- contrainedProperty: GF_PropertyType [0..1]- description: CharacterString [0..1]

«dataType»RangeBounds

- rangeStart: Real- rangeEnd: Real

«dataType»ScalarConstraint

- value: Real [1..*]- uom: UnitOfMeasure [0..1]

«dataType»RangeConstraint

- value: RangeBounds [1..*]- uom: UnitOfMeasure [0..1]

«dataType»CategoryConstraint

- value: CharacterString [1..*]

+constraint 0..*+qualifier 0..*

+derivedFrom 0..1

+component

2..*

An Observation is limited to a single Phenomenon

The ObservableProperty model (developed within OGC SWE-WG)

provides a mechanism to group measures that estimated by a

single Observation

The ObservableProperty model also allows basePhenomena to be qualified / constrained

(e.g. maximum windspeed during 10-minute period)

Describing the Observation Result

The WMO Logical Data Model is aligned with the patterns developed within the Climate Science Modelling Language (CSML3) – this is predicated on Observation sub-classes derived from SamplingCoverageObservation

SamplingCoverageObservation constrains the featureOfInterest to type ‘SF_SpatialSampingFeature’ and result to type ‘CV_DiscreteCoverage’

class ISO19156 SamplingCov erageObserv ation model ov erv iew

OM_DiscreteCoverageObservation

«FeatureType»Sampling Cov erage Observ ation::SamplingCov erageObserv ation

::OM_Observation+ phenomenonTime: TM_Object+ resultTime: TM_Instant+ validTime: TM_Period [0..1]+ resultQuality: DQ_Element [0..*]+ parameter: NamedValue [0..*]

constraints{observedProperty shall be consistent with result.rangeType}{featureOfInterest.shape shall be consistent with spatial components of result.domain}{phenomenonTime shall be consistent with temporal component of result.domain}

CV_Coverage

«type»Discrete Coverages::CV_DiscreteCoverage

::CV_Coverage+ domainExtent: EX_Extent [1..*]+ rangeType: RecordType+ commonPointRule: CV_CommonPointRule

Temporal Cov erage::CVT_DiscreteTimeInstantCov erage

«type»Discrete Cov erages::

CV_DiscretePointCov erage

Range

+result

22

23

class D07-051_METAR-SPECI (sympathetic model of BUFR Table D Sequence)

[d]D07-303_METAR-SPECI_Product

- weatherIndicator: B20-009_WeatherIndicator- prevail ingVisbil ity: B20-060_PrevailingVisibil ity- presentSignificantWx: B20-019_PresentWeather [0..3]- verticalVisibil ity_m: B20-002_VerticalVisibil ity_m- verticalVisibil ity_ft: B20-091_VerticalVisibil ity_ft- recentSignificantWx: B20-020_RecentWeather [0..3]- runwayShear: B11-070_WindShearAffectedRunway [0..4]- runwayState: B20-085_RunwayCondition [0..1]

D07-307_WindSpeedGroup

- windSpeed_kmh-1: B11-083_WindSpeed_kmh-1- windSpeed_knots: B11-084_WindSpeed_knots- windSpeed_ms-1: B11-002_WindSpeed_ms-1

«modifier»- windSpeedQualifier: B08-054_WindSpeedOrGustQualifier

D07-308_WindGustGroup

- maxWindSpeed_kmh-1: B11-085_MaxWindSpeed_kmh-1- maxWindSpeed_knots: B11-086_MaxWindSpeed_knots- maxWindSpeed_ms-1: B11-041_MaxWindSpeed_ms-1

«modifier»- windGustQualifier: B08-054_WindSpeedOrGustQualifier

D07-302_DirectedMinVisibility

- minVisibil ity: B20-059_MinVisibil ity

«modifier»- direction: B05-021_Bearing

D07-306_RunwayVisualRange

- range: B20-061_RunwayVisualRange

«modifier»- qualifier: B08-014_RVRQualifier

D07-013_RunwayVisualRangeGroup

- rvrTendency: B20-018_RVRTendency

«modifier»- runway: B01-064_RunwayDesignator

D07-301_CloudGroup

- cloudAmount: B20-011_CloudAmount- cloudType: B20-012_CloudType- cloudBaseHeight_m: B20-013_CloudBaseHeight_m- cloudBaseHeight_ft: B20-092_CloudBaseHeight_ft

«modifier-Discriminator»- verticalSignificance: B08-002_VerticalSignificance

D07-049_SeaConditions

- waterTemperature: B22-043_WaterTemperature- waveHeight: B22-021_WaveHeight

[d]D07-305_RunwayConditionSummary

- condition: B20-085_RunwayCondition

«modifier-ID»- runway: B01-064_RunwayDesignator

[d]D07-304_RunwayConditionDetails

- deposits: B20-086_RunwayDeposits- contamination: B20-087_RunwayContamination- depthOfDeposit: B20-088_RunwayDepositDepth- frictionCoefficient: B20-089_RunwayFrictionCoefficient

«modifier-ID»- runway: B01-064_RunwayDesignator

D07-048_TrendForecast

- weatherIndicator: B20-009_WeatherIndicator- prevail ingVisbil ity: B20-060_PrevailingVisibil ity [0..1]- presentSignficantWx: B20-019_PresentWeather [0..3]- verticalVisibil ity_m: B20-002_VerticalVisibil ity_m- verticalVisibil ity_ft: B20-091_VerticalVisibil ity_ft

«modifier»- changeIndicator: B08-016_TrendForecastChangeQualifier

Category01_LocationAndIdentification::D01-301_ForecastTimeOfChange

- time: D01-012_Time

«modifier»- qualifier: B08-017_TimeQualifierForForecastedChange

D07-051_METAR-SPECI

«modifier»- icaoLocationIndicator: B01-063_ICAOLocationIdentifier- productStatus: B08-079_AviationProductStatus- stationType: B02-001_StationType- date: D01-011_Date- time: D01-012_Date- position: D01-023_position- stationHeight: B07-030_StationHeight

It seems odd that DesignatedRunwayCondition and RunwayConditionDetails have been factored out into 2 independent Classes; this is because of the way the replication factors are structured in BUFR Table D Sequence [3 07 051] - each group of replicated elements includes the runway designator.

This is a candidate for merging as the model evolves.

[d]D07-309_QNH

- qnh: B10-052_QNH

«modifier»- barometerHeight: B07-031_BarometerHeight

[d]D07-310_SpotTemperature

- temperature: B12-023_Temperature- dewpoint: B12-024_Dewpoint

«modifier»- temperatureSensorHeight: B07-032_SensorHeight

[d]D07-311_WindGroup

- windDirection: B11-001_WindDirection- variableWindDirectionCCW: B11-016_VariableWindDirectionCCW- variableWindDirectionCW: B11-017_VariableWindDirectionCW

«modifier»- windSensorHeight: B07-032_SensorHeight

barometerHeight attribute moved from top-level to apply directly to QNH section as it is the only element relating to pressure. However it should also be recognised that barometerHeight is another measure of station height for aviation purposes. So this may need to be reconsidered at a later stage.

Amendment to Gil 's model: trend forecast does not include variable wind direction elements

[d]D07-312_ForecastWindGroup

- windDirection: B11-001_WindDirection

«modifier»- windSensorHeight: B07-032_SensorHeight

+rvr 2

+windGroup

1

+product

1

+spotTemperature1

+windGroup 1

+windSpeedGroup 1

+windSpeedGroup 1

+windGustGroup 1

+stationPressure

1

+minVisibil ity

0..2

+timeGroup

0..2

+runwayVisualRange

0..4

+clouds 0..3

+clouds

0..3

+seaConditions 0..1

+runwayCondition 0..4

+runwayConditionDetail 0..4

+trendForecast

0..3+windGustGroup 1

Harmonizing WMO BUFR models

with ISO/TC211 reference models

class D07-051_METAR-SPECI (sympathetic model of BU...

[d]D07-310_SpotTemperature

- temperature: B12-023_Temperature- dewpoint: B12-024_Dewpoint

«modifier»- temperatureSensorHeight: B07-032_SensorHeight

The process used to derive the UML model from BUFR Templates yields Classes that cluster physical properties (e.g. measures) and procedure information into well-defined modules.

Analysis of these modules indicates that the METAR/SPECI is comprised of multiple individual Observation instances.

class D07-051_METAR-SPECI (sympathetic model of BUFR Ta...

D07-051_METAR-SPECI

«modifier»- icaoLocationIndicator: B01-063_ICAOLocationIdentifier- productStatus: B08-079_AviationProductStatus- stationType: B02-001_StationType- date: D01-011_Date- time: D01-012_Date- position: D01-023_position- stationHeight: B07-030_StationHeight

The METAR/SPECI product includes attributes that define the time & location of the Observation event plus procedure information (e.g. stationHeight*).

The METAR/SPECI is defined for a single geographic location at an instant in time – we can consider this to be a degenerate coverage with only a single domain object.

* stationHeight is considered to be procedure information as this value is required in order to correctly interpret the Observation result (e.g. temperature measures)

24

PointObservation

METAR/SPECI expressed as Observations

METAR / SPECI Product

AerodromeObservationGroup

RunwayObservationGroup

AerodromeTrendForecast

runwayConditionElements

seaConditionElements

runwayWindShearElements

observedPhenomenaElements

qnhElements

windElements

phenomenonTime

SimpleProcess

documentation(title + link to online resource)

processParameter(e.g. sensorHeightParameter)

CompositeObservableProperty

component(e.g. temperature)

component(e.g. dew-point temperature)

SF_SamplingPoint

sampledFeature(e.g. Karlovy Vary Airport)

shape

temperatureElements

procedure

observedProperty

featureOfInterest

result

GM_Point(e.g. lon 12.92, lat 50.20)

CV_DiscretePointCoverage

OM_Observation: an EVENT whose RESULT is

an estimate of a value of some PROPERTY of some THING obtained using a specified PROCEDURE …

resultTime

25

CV_DiscretePointCoverage

METAR/SPECI temperatureElements result:

degenerate discrete point coverage

DataRecord

field(e.g. temperature)

field(e.g. dew-point temperature)

CV_DiscretePointCoverage

domainExtent

rangeType

element

EX_Extent

temporalElement

CV_PointValuePair

geometry

value

GM_Point(e.g. lon 12.92, lat 50.20)

Recordtemperature = 27 oC

dew-point temperature = 10 oC

geographicElement

The Coverage model seems over-engineered for a single point-observation.

However, its use does ensure that the WMO Logical Data Model is extensible and can easily adapt to future requirements where values are measured at multiple locations or at specified intervals over a time-period.

Adoption of the Coverage model also means that the data will be simple to publish via OGC WCS.

26

Logical Data Model for OPMET:conclusions

ISO/TC 211 provides standard reference models to underpin MET information Logical Data Model: ISO19103, ISO19107, ISO19108, ISO19123, ISO19156.

WMO Logical Data Model provides standard patterns for expressing observation and forecast data based on sub-Classes of SamplingCoverageObservation.

WMO Logical Data Model provides a palette of Measures, CodeLists and other entities (derived from BUFR Table B and BUFR Code&Flag Tables) that are used to define data value types and, where appropriate, ranges of permissible values.

ICAO MET information model can define sub-Classes of ‘Record’ that group Measures as necessary – importing Classes from WMO Logical Data Model.

ICAO MET information model can define Classes to represent aviation ‘data products’ (e.g. METAR/SIGMET) that group multiple Observations into a single report.

The resulting ‘data products’ are highly modular (e.g. Report | Observation | Coverage) – with each sub-component sufficiently self-contained that it does not require the context from enclosing component to be correctly interpreted.

Thank you

Questions and answers

27