Fullscreen
Loading...
 

Interim extranet supporting technical-related activities

WMO public web site | WMO Extranet (Community members) site

Go to wiki: WIS, CCl, WIGOS, DPFS, DRR.

Print

AvXML-1.0RC1-Issues

AvXML Version 1.0 RC1 - Issues Log

This list is a summary of the comments received on AvXML 1.0RC1. Only the first entry in a "conversation" has been copied here. Follow the links to see any subsequent discussions on the topics.

The comments have been copied verbatim. WMO takes no responsibility for the views expressed in these comments.

IdIssueLinkStatusResponse
1Temperatures between -0.5 and 0: coded as M00 in METAR. Link to commentOpen (See post 160)
2Include examples of coverages in RC2. Link to commentOpen
3 http://data.wmo.int/def/nil-reason/nothingOfOperationalSignificance nilReason was created.
This was intended to cover cases where a specific value was measured but was not deemed to be operationally significant such as "NSC" and "NSW". To support nilReasons the stereotype must be changed from a DataType to a Type in the UML model. Specific classes include:
AerodromeObservedClouds; AerodromeCloudForecast.
Link to commentOpen
4Add location and identification to SAF features. Link to commentOpen
5ObservablePropertyModel: should ObservableProperty/StatisticalQualifier@aggregationTimePeriod be type TM_PeriodDuration (from ISO 19108)? Link to commentOpen
6CAVOK only suppresses CAVOK only suppresses Visibility, Cloud, RVR and Significant Weather in the TAC. Link to commentOpen
7Wind direction should be specified as relative to true or magnetic north. Link to commentOpen
8RVR out of range
Manual on codes FM15 METAR/ FM16 SPECI covers runway visual range:
15.7.6 Extreme values of runway visual range
Special codings are used when RVR is above or below set limits, or when the RVR is outside the range that can be measured by the equipment. It does not seem possible to record this.
Link to comment Open
9I cannot find a way of coding missing values like for example /////KT. Is there a standard way of doing it in GML?Link to commentOpen
10Description of "Met Basic" package contents is broader than the abbreviated name implies (all of meteorology, climatology, water - and, not currently in the description, space weather). Should the name be changed Link to comment
11Ordering of elements in XML documents does not match the order in the UML model.Link to comment
12METCE Procedure "CompositeMeasurementContext" over complicates the model without adding value.link to comment
13Cannot encode any text within the iwxxm:LanguageString type. Link to comment
14Why are all the TAFs, METAR/SPECI, SIGMETs etc Objects and not Features?. Link to comment
15Referencing a runway: more guidance is needed on how to refer to a runway - ideally this will be consistent with other elements of AIXM. Link to commentOpen
16List of acceptable present weather codes.Link to comment 1
Link to comment 2
17In the Observable Property Model the property StatisticalQualifier/aggregationTimePeriod currently is type 'Time' (from ISO 19103 basic types). However, it is recommended that temporal properties are defined using types from ISO 19108 Temporal Schema. Proposal to change StatisticalQualifier/aggregationTimePeriod to type TM_PeriodDuration (from ISO 19108). The GML encoding rule for TM_PeriodDuration implements this type as xsd:duration ... therefore a 10-minute period would be encoded as the ISO 8601 duration "PT10M".Link to comment
18The <Type> stereotype is intended to convey an abstraction that is used in the underpinning ISO/TC211 harmonised model; it should _not_ be used in Application Schema. The appropriate practice is to have _no_ declared stereotype (e.g. blank). This change will have no impact on the the derived GML schema. Also note that the stereotype <FeatureType> should be used for entities that you want to access and/or query; therefore it is likely that the 'report' classes should be defined as <FeatureType> (this echoes the comment from Debbie Wilson)Link to comment
19Whilst the use of XML attributes is not part of the GML standard it is a commonly used encoding practice; ShapeChange already supports this encoding rule using the tagged value 'xsdAsAttribute'. We use a combination of acceptXMLAttribute and allowXMLAttribute for this purpose. To avoid confusion in the wider community, recommend using _existing_ tagged values for expressing this encoding mechanism rather than creating a new one ... http://shapechange.net/targets/xsd/extensions/#rule-xsd-prop-xsdAsAttribute refers. Note that encoding a property as XML attribute means that "standard" GML software tools will not recognise the attribute as property of the DataType or FeatureType; but the real world impact of this limitation is (likely to be) minimal. link to comment
20The constraint expressed in AerodromeRunwayState is not valid OCL ... (note, this was just a random sample; there is no inference that all the other constraints _are_ valid OCL!)Link to comment
21{on behalf of Clemens Portele}
i) Clemens has never seen or cannot recall seeing the rule in the ISO 191xx specifications prohibiting extension of types from ISO 19103
ii) the extension of types in ISO 19103 has been done before; see WXXM (developed by EUROCONTROL et al) as an example
iii) the GML encoding adopted for the 'measure' classes in met-basic (eg. AirTemperature) is fine
iv) strictly speaking, an ApplicationSchema _must_ contain feature types; however, the defacto practice is to declare packages as Application Schema even in the absence of Feature Types.
Recommend declaring met-basic as an Application Schema.
Link to comment
22{on behalf of Clemens Portele}
The use of the extra tagged values for <CodeList> classes (e.g. 'vocabulary' and 'extensibility') is OK.
The revision of ISO 19109 Rules for Application Schema (currently work in progress) will* permit Application Schema developers to use local or community specific tagged values.
Vocabulary and Extensibility tagged values are used within INSPIRE; this seems like an appropriate reuse.
Note that the tagged value 'codespace' is also often used to refer to an externally managed vocabulary, but this is also non-standard ... it is just a community convention. In any case, the controlled vocabularies we refer to are not always simple "flat lists" therefore 'codespace' does not _really_ have the appropriate connotations.
Use of 'vocabulary' and 'extensibility' tagged values should be retained.
Also note that GML encoding we have used is also OK.
* Clemens is pretty sure this was the outcome of discussion, but could not find the exact minuted resolution to refer to
Link to comment
23{on behalf of Clemens Portele}
Recommend that where unit of measure is defined by Unified Code for Units of Measure (UCUM) it is preferable to use the symbol from UCUM rather than the HTTP URI ... e.g.
- currently our examples show
<iwxxm:airTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">27</iwxxm:airTemperature>
and
<saf:upperLimit uom="http://opengis.net/def/uom/UCUM/0/%5Bft_i%5D">55000</saf:upperLimit>
(noting the nastiness in the second example of needing to encode '[' and ']' characters in the URI for the UCUM symbol [ft_i])
- recommendation
<iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature>
and
<saf:upperLimit uom="[ft_i]">55000</saf:upperLimit>
Where the unit of measure is _not_ specified in UCUM, the full URI is required (e.g. oktas and degrees-true ... and perhaps icao standard flight level) ... e.g.
<iwxxm:directionOfMotion uom="http://data.wmo.int/def/uom/degrees-true">180</iwxxm:directionOfMotion>

Subsequent note: also a problem for units of measure such as m/s, where the solidus is a separator in a URL.
Link to comment
24Reporting wind gusts
This is the current situation

AerodromeSurfaceWind.windSpeed of type WindSpeedType
AerodromeSurfaceWindTrendForecastType.windGustSpeed of type GustSpeedType
AerodromeSurfaceWind.windGust of type GustSpeedType

it is desirable to harmonise the naming to avoid the users spending time on searching the appropriate type.
It should be

AerodromeSurfaceWind.windSpeed of type WindSpeedType
AerodromeSurfaceWindTrendForecastType.windGust of type WindGustType
AerodromeSurfaceWind.windGust of type WindGustType

or

AerodromeSurfaceWind.windSpeed of type WindSpeedType
AerodromeSurfaceWindTrendForecastType.windGust of type WindSpeedType
AerodromeSurfaceWind.windGust of type WindSpeedType

Link to comment
25In the conversion of metar to xml I have found that the runway state is reported for several runways. This is not allowed in the xml schema as only one runway state is defined. I think we should add more runway states.Link to comment
26 As response to our tests und discussions I send our first(draft) result. I hope we can send more details end of next week.
As attachments you can find a summary of questions and results (DWD_statements_first_iteration.doc). For clarification of some of our ideas, I have attached two schemas from DWD (airport_customer_telegram.xsd) and Deutsche Flugsicherung (dfsMetar.xsd).
Additional to these results, i have a technical question/problem:
We use the oxygenXML tool to valitate xml-metats. But we will validate (against schema and schematron rules) all incomming xml-metars automatically. Currently i have not found opensource libraries to valitate (xml schema AND schematron rules) xml-documents against a combinated xsd-document (xml schema with embedded schematron rules). If schematron rules exist as seperated document (like *.sch) i see solutions. If somebody can help, we are happy.
Otherweise: Is it possible to config Fullmoon to separate schematron rules as *.sch during the translation the UML constaints into schematron rules?
Link to comment and attachments
27Inconsistent use of "aviation" and "aerology"
reviewing the XML schema using Notepad++, Altova XMLSpy and browers, I note the following statement in aeronauticalMeteorology.xsd, within <documentation> </documentation>
Often the entities defined herein are specialisations of generic meteorological entities. [&lt;font color="#ff0000"&gt;&lt;i&gt;Note the inconsistent use of "aviation" vs. "aeronautical"; please indicate preference&lt;/i&gt;&lt;/font&gt;]
The text in bold is my emphasis. However, regardless of which software used the effect of highlighting the intervening text (between the bold text) never occurrs.
Link to comment
28RC1 does not include any extensions mechanisms so data producers or downstream middlemen may extend ICAO/WMO content. This is a crucial capability. This has been planned for RC2, but this is a reminder that this should be addressed. Note that this ties closely into the ongoing discussions around XML Schema 1.1 and the open content model. Link to comment
29Impacts of Amendment 76

I understand that this implementation is based on Amendment 75. Amendment 76 comes into force wef 0000 UTC 14 November 2013, and a number of changes are expected. As such, this implementation may quickly become out of date.

What maintenance plans are in place to ensure that this technical standard does not diverge from the ICAO Annex 3 Technical Regulation?
----
Diagram "Context Diagram: SIGMETPositionAnalysis" from IWXXM/SIGMET package includes the following public note (in orange, top-left).
"Used for forecast positions for VolcanicAshSIGMETs and TropicalCycloneSIGMETs"

With Amendment 76 (effective 0000 UTC 14/11/2013) all other SIGMET phenomena will be eligible to have forecast position information.
Link to comment
30I understand that many of the 'constructs' that are used in SIGMET have been ignored, (i.e. N OF, NW of a stated line with coordinates given etc), and that in the XML/GML schema explicit points will be given defining a polygon (or point in some intstances). In certain respects I think that is a forward thinking approach, but how will the conversion from existing constructs as identified above, and perfectly legitimate in TAG SIGMET be handled? Is there any suggestion that TAC SIGMET be forced to use explicit polygons/points beyond a certain date (Nov 2016, Nov 2019, Nov 2022??) to be more explicitly mapped against the GML/XML versions.Link to comment
31There are gaps and inconsistencies in the current SIGMET table {of ICAO Annex 3 / WMO No. 49}, and also conflicting opinions by ICAO Regional Offices themselves with regard to how SIGMET should be constructed.

How is the variation in interpretation resolved?
Link to comment
32number of SIGMETs simultaneously in force for a given FIR
Documentation for class SIGMET from IWXXM/SIGMET package states:

"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 in time and space. Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time."

There is no restriction on how many SIGMETs may be in force of any type within an FIR. Where has this misconception come from?
Link to comment
33ambiguity on use of OBS and FCST for SIGMET
Diagram "Context Diagram: SIGMETEvolvingConditionAnalysis" (from IWXXM/SIGMET package) includes the following public note:

"""Used for OBS and FCST conditions on all SIGMET reports""" ... the orange note in the top right.

Thought this was a bit ambiguous. Just to clarify, you cannot have OBS AND FCST, and where are the references to the optional 'AT'? The options OBS, OBS AT GGggZ, FCST, FCST at GGggZ.

This ambiguity is repeated in the documentation for class EvolvingMeteorologicalCondition (from IWXXM/SIGMET package):

"An EvolvingMeteorologicalCondition is a result of a SIGMETEvolvingConditionAnalysis process, and indicates 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."

Please clarify.
Link to comment
34interpretation of CB base in SIGMET

Documentation for Class EvolvingMeteorologicalCondition (from IWXXM/SIGMET package) states:

"TC TOP (ABV and BLW) conditions are represented by the vertical component of the geometry. For example: CB TOP FL500 is represented as a base of 0 and a top of 500FL."

Consider the example given: CB TOP FL500 is represented as a base of 0 and a top of 500FL. The interpretation is strictly incorrect. There is no information regarding the base of the CB. CB rarely, if ever, has a base at the surface. The base is simply unknown – whether you want to make the assumption that the base is at the surface is up to you, but is not implied in the SIGMET.
Link to comment
35SIGMET validity periods

Documentation for property SIGMET.validPeriod (from IWXXM/SIGMET package) states:
"The valid period for the entire report, including all observations and forecasts. Each observation/forecast also includes its own applicable period of validity"
The statement needs clarifying. There are no separate validity periods within a SIGMET.
Link to comment
36Documentation for property SIGMET.analysis (from IWXXM/SIGMET package) states:
"SIGMETs may include the same phenomenon covering more than one area within the FIR, 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."
Despite the statement, there is actually no specified or agreed method for including other instances of the same phenomena within a single SIGMET. Amendment 75 to Annex 3 is incomplete in this regard, and Amendment 76 is not expected to improve things greatly. UK practice is to only include one instance in any one SIGMET, and to issue separate SIGMETs as necessary.
Link to comment
37RMK prohibited in SIGMET
Class SIGMET (from IWXXM/SIGMET package) includes property "humanReadableText".
The documentation for this property states:
"Human-readable, descriptive text that cannot be sensibly represented in any other form. This report element encapsulates the human-generated text that is intended for other downstream human recipients. All other elements of the report capture machine-readable information that can be anticipated in advance as part of the reporting structure.
It is not valid to include any machine-readable information or extended content in this text under any circumstances. Human-readable text may be considered opaque to parsing software and should be used minimally.
This text is not to be confused with Traditional Alphanumeric Code (TAC) form remarks ("RMK"), which have been used for many purposes beyond human-readable text."
RMK is not permitted in SIGMET. Although this property "is not to be confused with RMK", it is not clear whether SIGMET should include the facility for inclusion of arbitrary text. Please clarify whether 'humanReadableText' is permitted within SIGMET class.
Link to comment
38designation of LONG or SHORT TAFs
Has there been any consideration with regard to explicitly identifying if a TAF is a long TAF or a short TAF?
Link to comment
39use of abbreviations for TAF forecast change indicator
Enumeration AerodromeForecastChangeIndicator (from IWXXM/TAF package) provides unabbreviated terms; e.g. BECOMING.
Maybe I misunderstand, but has somebody stated that these schemas should do away with the abbreviations BECMG, TEMPO, PROB30, PROB40, PROB30 TEMPO, PROB40 TEMPO, FM etc? Or are the references in the top right box simply mnemonics that map to BECMG, TEMPO etc?
Link to comment
40use of forecast change indicator in TAF
Class MeteorologicalAerodromeForecastRecord (from IWXXM/TAF package) includes the property 'changeIndicator'.
A number of business rules need to be made explicit regarding the use of this property:
1) you cannot have PROB30 or PROB40 with BECMG or FM, and
2) the use of FM requires a full set of 'new' base conditions to be established.
Link to comment
41reporting surface wind properties in TAF
In reference to AerodromeSurfaceWindTrendForecast class (from IWXXM/Common package), the documentation for the property meanWindDirection states:
"The forecast average wind direction. Not reported when winds have variable direction"
Maybe I misunderstand the conventions of XML/GML, but the note to MeanWindDirection does not appear to be quite correct. If the wind direction is variable, then 'VRB' is reported, meaning variable. It is followed by the wind speed.
Also note that the documention for property windSpeed does not make reference to it being an average (cf wind direction and reference to 'average'. Strictly, the averaging period is 10 minutes. To that end, the maximum wind speed is that maximum wind speed expected over a 10 minute period.
Finally, it is also confusing to refer to this as 'TREND' in a TAF. Whilst both TREND and TAF may have some similarities is it not confusing to specify a component of TAF as being a TREND? If, to understandably minimise duplication and allow reuse of classes etc, can there not be a more generic title be identified?
Link to comment
42documentation for minimum temperature in TAF
The documentation for properties minimumAirTemperature and minimumAirTemperatureTime for class AerodromeAirTemperatureForecast (from IWXXM/TAF package) incorrectly refer to "TX" ... this should be "TN".
Link to comment
43incorrect implication of CAVOK relating to surface wind
Class MeteorologicalAerodromeForecastRecord (from IWXXM/TAF package) includes the following constraint:
"if( ceilingAndVisibilityOK ) surfaceWind == NULL"
This is incorrect.
Surface wind has nothing to do with CAVOK. When CAVOK applies, then there will be no reference to visibility, weather or cloud (since CAVOK replaces all 3 parameters). If CAVOK is reported in the base conditions (or following the 'FM' change indicator) then a surface wind is mandatory. Thereafter significant changes to surface wind are mandatory regardless of whether CAVOK applies or otherwise.
Link to comment
44METAR missing groups
METAR

As from the email exchanges, for ICAO, when an element is required, then it is not acceptable to have a NIL (or whatever the exact way it is indicated) for this element.

Remarks:
The requirement for an element to be always produced is indicated by the cardinality not at 0.
The impossibility to have an indication of one element be missing due to some technical problems (whatever the exact problem and way to indicate it) and the application of a constraint will lead to the whole rejection of the XML METAR data, that will not be produced.
Consequently, all the other elements of the data which are as well required (and sometimes of more operational importance ) will therefore not be produced due to the applied constraint. One direct consequence by the MET operator could as well be the cancellation of a TAF for the same location if it is considered that there is no way to keep the watch (as an example, due to occasional lack of Td ...).
The WMO manual of code has explicit references about missing groups at least for AUTO METAR and for required elements. The uml (xml) model should be compliant with the WMO manual of Code.
The ICAO expressed requirement to have a constraint on every required element leading to no METAR , if a required element ( ie cardinality not at 0) can never be indicated by "NIL" , should be fully assessed by ICAO.
Link to comment
45TAF COR
- in Type "TAF"
should there be as well a new constraint " if(corrected) previousReportValidPeriod != null" ?
identical remark with the following constraint " if( !amended AND !cancelled ) previousReportValidPeriod == null " >> What about Corrected TAF ?
Link to comment
46TAF Type MeteorologicalAerodromeForecastrecord surfaceWind
in Type "MeteorologicalAerodromeForecastrecord"
if ( ceilingAndVisibilityOK) surfaceWind==NULL ), should "surfaceWind " be replaced by "cloud" ?
Link to comment
47TAF Type MeteorologicalAerodromeForecastrecord prevailingVisibility
in Type "MeteorologicalAerodromeForecastrecord"
in " if ( ceilingAndVisibilityOK) prevailingVisibility ==NULL ), " " should "prevailingVisibility " be replaced by "prevailingHorizontalVisibility" ?
Link to comment
48TAF AerodromeSurfaceWindForecast
if ( ceilingAndVisibilityOK) surfaceWind ==NULL ) is not right & the "AerodromeSurfaceWindForecast" is indicated a 0:1 (link surfaceWind) due to that but it is always required (it should not be 0)
Link to comment
49SIGMET VolcanicAshSIGMET / TropicalCycloneSIGMET / SIGMET Element gml:id
VolcanicAshSIGMET / TropicalCycloneSIGMET / SIGMET Element gml:id :
The uniqueness of the gml:id is not guaranteed if two SIGMET are issued for the same FIR at the same second.
The addition of the SIGMET sequence number in the gml:id should guarantee the uniqueness.
Link to comment
50SIGMET Status
Why is the status attribute inside the tag ?
Link to comments
51SIGMET VolcanicAshSIGMET eruptingVolcano
VolcanicAshSIGMET eruptingVolcano
Is there a nomenclature / list from which the erupting volcano name is chosen (in this case, reference / xlink maybe needed ) ? Or is it free text ?
note :
from ICAO DOC 9766 and in annex 3 Volcanic Ash Advisory template: name of volcano and volcano reference number: Volcano name (if known) and reference number (International Association of Volcanology andChemistry of the Earth’s Interior (IAVCEI))from the VONA template : Name and number (per Smithsonian database at http://www.volcano.si.edu/world/)
Link to comment
52SIGMET humanReadableText
is currently optional. It would be very useful, at least for testing purposes, to have the corresponding humanReadableText always available (until the xml becomes the official format)
Link to comment
53SIGMET analysis : EvolvingMeteorogologicalCondition
How do we know if it is an observation or a forecast ? Observation of Forecast is mandatory information, so it should appear clearly in the xml, not only in the gml_id.
Is there a ruling to generate the gml_id ? What if there are several areas impacted, and observation and forecast ?
At least for volcanic ash SIGMET and Tropical cyclone SIGMET, the SIGMET could contain :
-one observation + one forecast (typical situation, OK with the current modelling)
or -one observation only
or -two forecasts
or -one forecast and a no volcanic ash expected statement (as a next forecast-see last remark)
How do we handle these with the analysis, and forecastPosition analysis ?
Why is intensityChange attribute inside the tag ?
Link to comment
54SIGMET cancellation
In case of a SIGMET cancellation, as the analysis element is not optional, how do we handle a cancellation ?
Do we have to have an analysis element anyway ? An empty one ?
Link to comment
55SIGMET VolcanicAshSIGMET forecastPositionAnalysis
In Annex 3 next amendment (76), the possibility of « No volcanic Ash expected » exists.
How can we handle this with the current proposed forecastPositionAnalysis attributes ( we know we have to keep in mind only Amdt 75...) ?
Link to comment
56TAF AerodromeForecastChangeIndicator
- in "Enumeration" AerodromeForecastChangeIndicator "
following Annex 3 2.3.2 APP 5-7, "TL" and "AT" exist but they are not found in template Table A5-1, and therefore not found in the model.
The text in annex 3 and the Table A5-1 are not fully consistent. What should the model take into account ?
Link to comment
57Relation between "airTemperature" and "dewpointTemperature"
dewpointTemperature must never be higher as airTemperature.
Proposal:
%New schematron rule and UML constraint like:
Schematron rule like:
<sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord6">
<sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord">
<sch:assert test="notiwxxm:airTemperature) < number(iwxxm:dewpointTemperature?">Error: Dewpoint temperature higher then air temperature (forbidden)!
</sch:assert>
</sch:rule>
</sch:pattern>
Link to comment
58Direct using of GML-Types
Dirk and i see conflicts between the direct using of GML-type like "gml:MeasureType" and range and accuracy of values (compliant to aviation):
1. Problem:
E.g. windDirection is given as a whole number (integer) within the range of 1..360. Since AngleType is based on gml:MeasureType, which is a number of type double, there is no restriction of valid range of values nor accuracy. This is also an issue to other elements (e.g. windSpeed cannot have a negative value).
Possible solution may be:
1. Use schematron rules and UML constraints to constrain sub-range compliant to aviation, like (schematron rules as example:
<sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord7">
<sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord">
<sch:assert test="notiwxxm:surfaceWind//iwxxm:windSpeed) < 0)">Error: negative wind speed (forbidden)!
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord8">
<sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord">
<sch:assert test="not(number(iwxxm:qnh) < 0)">Error: negative qnh (forbidden)!
</sch:assert>
</sch:rule>
</sch:pattern>
OR
2. Create a new "aviation-type" based on "gml:LengthType", "gml:SpeedType", ...
=============
2. Problem:
If accuracy required, accuracy could be defined in the new aviation-types by using constraints based on a regular expression (e.g. as xsd pattern like: [\-]?\d{1,2}\.\d{1}) )
=============
3. Problem:
DataTypes like RVR (<iwxxm:meanRVR>), which are not a real discrete sequence of numbers could be better described by an enumeration of possible valid values. Examples from a DWD aviation project with an solutions like that are attached only for clarification ((see our email from 23 Jan; airport_customer_telegram.xsd, e.g. type "st_RVR_value") or DFS/DWD project (see our email from 23 Jan; dfsMetar.xsd, e.g. type "st_runwayVisualRange" </sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord8">
<sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord">
<sch:assert test="not(number(iwxxm:qnh) < 0)">Error: negative qnh (forbidden)!
</sch:assert>
</sch:rule>
</sch:pattern>
OR
2. Create a new "aviation-type" based on "gml:LengthType", "gml:SpeedType", ...
=============
2. Problem:
If accuracy required, accuracy could be defined in the new aviation-types by using constraints based on a regular expression (e.g. as xsd pattern like: [\-]?\d{1,2}\.\d{1}) )
=============
3. Problem:
DataTypes like RVR (<iwxxm:meanRVR>), which are not a real discrete sequence of numbers could be better described by an enumeration of possible valid values. Examples from a DWD aviation project with an solutions like that are attached only for clarification ((see our email from 23 Jan; airport_customer_telegram.xsd, e.g. type "st_RVR_value") or DFS/DWD project (see our email from 23 Jan; dfsMetar.xsd, e.g. type "st_runwayVisualRange"" class="wiki wikinew number">?

=============
4. Problem:
Observation for a mandatory element is not available or not reported (for what reason ever, failure of backup of backup sensor…) and this element is based on gml:MeasureType, it is not possible to encode an empty element nor a nilReason. Aviation-types may include a nilReason feature, including an enumeration of possible reasons.
Link to comment
59Strongly typed vs. Weakly typed
The AvXML format for the OPMET datasets is strongly typed. Environment Canada undertook an initiative to modernize its data exchange format in 2008. Out of this endeavour we initially created strongly typed XML schemas for different data types (eg: observation, forecasts, warnings, etc). But it became apparent shortly thereafter that the maintenance of these dataset specific schemas were needlessly complicated and expensive. Dedicated schema definitions, software bindings and libraries, and documentations needed to be created and managed individually for each dataset. Thus, it was decided to move away from a strongly typed XML approach to a weakly typed one. In the later approach, one .xsd was created as a general purpose container to hold any dataset from any data type, all the while conforming to the dataset’s specification as outlined by its authoritative body (eg: ICAO in the case of METAR, etc). This enabled us to create one set of software libraries to parse and encode XML instances, and one set of documents to supplement these instances. With this approach we were able to rapidly ingest and encode data from many distinct data networks. The weakly typed approach have also enabled us to share meteorological data with our clients and data providers in one uniform/common format, thus enhancing interoperability between data sharing parties. Although it might be too late to factor in these design considerations into the AvXML schema (since AvXML is well beyond the design phase and nearing a stable publication), we are raising this comment as a possible future consideration for other XML related work at WMO (eg: non-aviation datasets). Documentation, schema and samples of Environment Canada's Met-ML (Meteorological Markup Language) instances can be made available on request.
Link to comment
60Only a single SIGMET (per type) per FIR
Item:
SIGMET : Public <<Leaf>> Package UUID:
{E412FEC7-FA90-4b4f-BB89-ECBB773CDCB3}
Statement:
Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time.
Comment/Issue:
This statement is not explicitly found in Annex 3. Table A6-1 indicates the footnote 21 next to the Location which means that element can be repeated as necessary.
Link to comment
61Temperature and Dewpoint - METAR TAC specifications place these after the VIS and cloud goups. The XML schema requires this to be entered at the start of the observation Record segment.
Temperature and Dewpoint - Reg 15.11.3 States that temperatures below 0 (zero) degrees shall be preceded by ‘M’ to indicate a negative temperature. The Schematron expects a whole integer and not a mixed char / int data type.
Wind Speed - The wind speed in UK metars is currently reported in Knots (1 Nautical mile per hour) whereas in the UOM standard speeds of this type are expected in m s-1. The inclusion of Knots as the unit for wind speed causes a failure in validation.
Link to comment
62Item:
SIGMET : Public <<Type>> Class UUID:
{1C3924B3-E438-4ab8-BF89-C5148CAFB866}
Statement:
Non-tropical cyclone and volcanic ash SIGMETs may report either an observation or a forecast. SIGMETs may include both an observation ("OBS") as well as a forecast ("FCST").
Issue/Comment:
"Non-tropical cyclone"…what is that ?
The second statement is misleading as written as it leads someone to think that a SIGMET can have both OBS and FCST simultaneously in a given bulletin.
Link to comment
63Item:
Public Note UUID:{216E7749-2AD2-4bd9-A11F-4E316EA5D6A2}
Statement:
Used for OBS and FCST conditions on all SIGMET reports
Issue/Comment:
This statement should say "Used for OBS or FCST conditions on all SIGMET reports"
Link to comments
64Item:
Public Note UUID: {D5C7EE7D-B7DC-49de-963F-21AB8DACCA95}
Statement:
The sampled feature for SIGMET is always an FIR
Issue/Comment:
Annex 3 allows the use of UIRs and CTAs as well.
https://groups.google.com/a/wmo.int/d/topic/cbs-tt-avxml/1FxjXn2FXNE/discussion
65Item:
TAF : Public <<Leaf>> Package UUID:
{B0C787A8-5F53-4209-B721-28726BACAB9B}
Statement:
A Terminal Aerodrome Forecast (TAF) report is a routine aerodrome forecast intended for distribution beyond an aerodrome. TAF reports include base forecast conditions, and modifications to those conditions throughout the valid period.
Issue/Comment:
This statement should be replaced by the TAF definition found in Annex 3 Chapter 6 section 6.2.1 and 6.2.3.
Link to comment
66Item:
AerodromeAirTemperatureForecast : Public <<DataType>> Class UUID:
{8DF2190B-28F0-40d1-8477-8F2B911FABED}
Statement:
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.
Issue/Comment:
The statement (and the detailed attributes) should indicate that Air temperature is optional and field may thus be missing entirely.
Link to comment
67Item:
AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID:
{B97CF00A-83EA-493b-902C-6B20F827029A}
Statement:
BECOMING
Issue/Comment:
the definition for the temporal change BECMG is not of that found in Annex 3 Appendix 5 section 1.3.4
Link to comment
68Item:
AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID:
{B97CF00A-83EA-493b-902C-6B20F827029A}
Statement:
FROM
Issue/Comment:
Its is not FROM…it is FM
Link to comment
69Item:
AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID:
{B97CF00A-83EA-493b-902C-6B20F827029A}
Statement:
FROM
Issue/Comment:
the definition for the temporal change FM is not of that found in Annex 3 Appendix 5 section 1.3.6
Link to comment
70Item:
TAF : Public <<Type>> Class UUID:
{F5121C64-A503-4d54-8E95-6360540B6C06}
Statement:
A Terminal Aerodrome Forecast (TAF) report is a routine aerodrome forecast intended for distribution beyond an aerodrome. TAF reports include base forecast conditions, and modifications to those conditions throughout the valid period.
Issue/Comment:
This statement should be replaced by the TAF definition found in Annex 3 Chapter 6 section 6.2.1 and 6.2.3.
Link to comment
71Item:
Context Diagram: MeteorologicalAerodromeForecast Class:Type
MeteorologicalAerodromeForecastRecord
Statement:
Constraints: (if ceilingAndVisibilityOK)SurfaceWind ==Null
Issue/Comment:
This statement says that no wind should be forecast when CAVOK is used. That is wrong. See Annex 3 Table A5-1.
Link to comment
72Item:
Context Diagram: Present Weather : Class diagram ID:
{B2229DEF-E7A3-4930-93FC-5B43321C1DA5}
Statement: N/A
Issue/Comment:
Why is this named "Present Weather" since the two classes represented here are Surface Wind.?
Link to comment
73Item:
Context Diagram: MeteorologicalAerodromeObservation Class:Type
MeteorologicalAerodromeObservation
Statement:
Constraints: (if ceilingAndVisibilityOK)SurfaceWind ==Null
Issue/Comment:
This statement says that no wind should be reported when CAVOK is used. That is wrong. See Annex 3 Table A3-2.
Link to comment See also comment 6
74Item:
SIGMET : Public <<Type>> Class UUID:
{1C3924B3-E438-4ab8-BF89-C5148CAFB866}
Statement:
Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time.
Issue/Comment:
This statement is not explicitly found in Annex 3. Table A6-1 indicates the footnote 21 next to the Location which means that element can be repeated as necessary.
Link to comment
75reporting 'no significant change' in a METAR trend forecast: NOSIG instead of NSC
Documentation for enumeration ForecastChangeIndicator (from METCE/Qualifiers package) states:
'Conditions typically reported as NO_SIGNFICANT_CHANGE (NSC) shall be encoded using the "nothingOfOperationalSignificance" nil-reason code.'
The METAR regulation states that the abbreviation is "NOSIG" rather than "NSC".
Link to comments
76clarification of constraint on reporting minimum visibility direction
Class AerodromeHorizontalVisibility (from IWXXM/METAR package) includes the following constraint:
{ if( self.minimumVisibility NOT NULL ) minimumVisibilityDirection NOT NULL }
This constraint needs to be amended; minimum visibility must be reported with a direction, except where the visibility is fluctuating rapidly (Annex 3, App 3, para 4.2.4.4b refers) whereby just the min vis is reported with no indication of direction.
Link to comment
77OGC standards
This is less of a comment but a notice of compliance. Environment Canada also chose the same set of core schemas to achieve XML representation of meteorological data. The OGC's Observation and Measurement (OM) and Geographic Markup Language (GML) schemas are heavily employed in Environment Canada's Met-ML (Meteorological Markup Language) schema. This ensures that when the AvXML needs to be generated for the OPMET datasets by Environment Canada, it will be seamless, since both Met-ML and AvXML are sharing the same core schemas.
Link to comment
78 Purpose of UML Class/Attribute note property
In SESAR AIRM we use to capture the definition of an “ATM concept” inside the note property of a UML class/attribute. We use definitions taken (or slightly adapted) from an authoritative source (e.g. ICAO), so at the end the set of note properties of a model are shaped like sort of Dictionary
By looking into the RC1 I see a different purpose. Classes descriptions do not always define the concept that the class represents, but rather describe the modelling purpose (e.g. “"this class is..."…”), or the usage of that class, or other side remarks (e.g. in the METAR there’s an explanation that the METAR ad SPECI have same nature), or the reference to ICAO doc/page/table itself.
I would clearly separate the definition of a concept from the usage remarks and the modelling aspects. I wonder whether all these additional info might be captured through tagged values.
Link to comment
79AerodromeRunwayState, some findings
1) The nature of AerodromeRunwayState is a bit unclear: it looks like a mix of properties of both a runway and aerodrome (e.g. snowClosure is related to the latter);
2) I'’m surprised that attribute “"runway”" is optional (according to the description, all RWYs could be closed for snow, so multiplicity would be zero then), since “runway” is kind of "primary key" for the info held in this class. If runway is NULL, then how to reference other RWY-related properties, e.g. depositType?
3) Also, there should be some constraint to link snowClosure and runway, as the existence of the latter attribute depends on the value of the former.
Link to comment
80Codelists empty?
I'm missing the context on the modelling activity, but many codelists seem empty (e.g. BreakingAction, RunwayDeposits… and many more...). Is that done by purpose?
Link to comments Code lists are held outside the model
81OCL syntax for constraints
I'm not sure how far this release is intended to comply with OCL.
According to the OMG OCL (2.3.1) specs, the arrow notation should be used to reference a set in a constraint, instead of the dotted notation,
e.g. "self.affectedRunway->size()=0" instead of "self.affectedRunway.size=0”"
The latter would fail the validation… (well, EA’'s OCL validation feature simply does not work, that’'s not a secret).
Also "=" should be used for boolean expressions, rather than "==".
Furthermore, I see different ways applied to evaluate whether an optional attribute is not present. Sometimes the "==NULL”" is used, and sometimes the "size=0". I would recommend making a choice and applying it consistently.
Link to comment
82 Associations to codelist
Typically a class property typed as a enum/codelist is held as a class member rather than as an association role. This sounds more sensible to me, style wise.
However there are some exceptions in which there is an association to a codelist, e.g. MeteorologicalAerodromeObservationRecord.recentWeather. Is there an explanation to that?
I would suggest to choose one pattern and apply it consistently throughout the model.
Link to comment
83COnstraint on availability of cloud amount and base height
I think there should be a constraint linking AerodromeObservedClouds.amountAndHeightUnobservableByAutoSystem to the availability of corresponding attributes (amount, base) in the associated CloudLayer class.
Link to comment
84Constraint on RVR availabilityLink to comment
85Use of underscore in class names
Class Visibility_Aero: is the underscore used by purpose here? Shouldn't it be deleted in this particular case?
Link to comment
86EUROCONTROL Comments on the proposed models
Despite the acknowledged recommendation, comments from several colleagues in the Organisation have been gathered in the attached EXCEL file which contains one sheet per package/schema plus one for general comments on the principles applied on the development of the models.
Note that several findings come from issues encountered when generating code from XSDs for handling a representative set of METARs from all over the world. (Note, spreadsheet is available from the original post).
Link to comment
87Is this complexity really needed ?
Our feedback is of a more general nature. First of all thank you for the energy and dedication your team has in working towards this standardization effort.
Our impression on the result of the work is strongly based on our analysis and tests of the XSD Schemas and with a particular focus on the use of OPMET in downstream, i.e. not as a collector of data to generate TAF METAR or SIGMET but as a distributor/processor of such messages once they have been created.
Most of the remarks we initially had can be summarized with the following:
For the purpose of OPMET it seems an overkill. A huge and complex amount of dependencies for the purpose to represent a quite simple set of information.
This complexity becomes particularly obvious if one has a look at the java bindings: In order to parse a METAR which should result in something simple like this:
METAR YUDO 221630Z 24004MPS 0600 R12/1000U DZ FG SCT010 OVC020 17/16 Q1018 BECMG TL1700
0800 FG BECMG AT1800 9999 NSW
one needs to have more than 6400 classes as dependencies.
Complexity is good if it can not been avoided or if the benefit it brings is big. For the scope METAR TAF and SIGMET we can not see such a benefit besides the fact that there is additional information when compared to the TAC counterparts. This additional information is however generally of poor interest to the Airmen.
The wide use of referenced information (xlink and uom) even if it is often self-explanatory makes it difficult and time-consuming to process the information, we would prefer to have a self-contained message approach.
Schematron:
In principle we found the schematron approach good, but it seems there is the need to improve the used restrictions. For example we did change
<sf:sampledFeature xlink:href="http://icao.int/id/aerodrome/YUDO" xlink:title="Fake Airport"/>
to
<sf:sampledFeature xlink:href="http://icao.int/id/XXXaerodrome/YUDO" xlink:title="Fake Airport"/>
and it still passed validation. The conclusion is that if schematron has to be used then the restrictions should be more restrictive (we are aware that XPATH and XSL are quite weak in this).
Link to comment


Page last modified on Thursday 07 of February, 2013 16:43:48 CET