wmo-im / iwxxm

XML schema and Schematron for aviation weather data exchange
https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML
48 stars 22 forks source link

Fix conflict between SFC/FL550 and TOP FL550, fix ABV FLnnn, document SIGMET/AIRMET vertical extent encoding for all allowed TAC combinations #25

Closed jkorosi closed 6 years ago

jkorosi commented 7 years ago

FLnnn, nnnnM, nnnnFT This is typical for SIGMETs based on pilot reports, e.g. turbulence at the level in which the airplane was. We suggest to set aixm:lowerLimit and aixm:upperLimit to the same value in effect creating an airspace volume which has zero thickness. If you agree with this suggestion please add comment into TAC-to-XMLGuidance. txt and/or in schema documentation and create an examples TAC/XML SIGMET to demonstrate it.

ABV FLnnn The issue is that geometryUpperLimitOperator can have only value "ABOVE" but "BELOW" is not allowed by Schematron

<sch:pattern id="SIGMET.EMC5">
<sch:rule context="//iwxxm:EvolvingMeteorologicalCondition">
<sch:assert test="(if(exists(iwxxm:geometryLowerLimitOperator)) then
(iwxxm:geometryLowerLimitOperator = 'BELOW') else true())">
SIGMET.EMC5: geometryLowerLimitOperator can either be NULL or BELOW.
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern id="SIGMET.EMC6">
<sch:rule context="//iwxxm:EvolvingMeteorologicalCondition">
<sch:assert test="(if(exists(iwxxm:geometryUpperLimitOperator)) then
(iwxxm:geometryUpperLimitOperator = 'ABOVE') else true())">
SIGMET.EMC6: geometryUpperLimitOperator can either be NULL or ABOVE
</sch:assert>
</sch:rule>
</sch:pattern>

SFC/FL550 We believe the example sigmet-VA-EGGX.xml is incorrect and should be changed like this:

  1. The comment “omitted lower limit implies that the volcanic ash cloud extends to groud/sea surface” should be removed
  2. Instead of omitting lower limit there should be aixm:lowerLimit with value “GND” and uom set to either FT (or maybe FL).
  3. aixm:lowerLimitReference element can be probably omitted in this case The above is probably better in line with AIXM or Digital NOTAM specification. Also Boris Burger commented on Google Group that omitting lower limit would create conflict with representation of “TOP FL550”.

the official VA SIGMET example http://schemas.wmo.int/iwxxm/2.0/examples/sigmet-VAEGGX.

<aixm:AirspaceVolume gml:id="av-va-fcst-position-EGGX-YYYYMM25T22Z"><!--
omitted lower-limit implies that the volcanic ash cloud extends to ground/sea surface
-->
<aixm:upperLimit uom="FL">550</aixm:upperLimit>
<aixm:upperLimitReference>STD</aixm:upperLimitReference>
<!-- shortened -->
</aixm:AirspaceVolume>

xml which actually contains translation of SFC/FL550 suggests that the lowerLimit should be simply omitted in this case, quoting: But I think that is wrong too - because how would we distinguish that from vertical extent TOP FL550?TOP FL550 - The person writing the SIGMET is not saying anything about the lower limit of the vertical extent. In this case it makes sense to omit the aixm:lowerLimit and aixm:lowerLimitReferenceSFC/FL550 - Here the forecaster is writing explicitly SFC, he is not saying "unspecified lower limit" The AIXM element aixm:lowerLimit supports special value GND (see http://www.aixm.aero/sites/aixm.aero/files/imce/AIXM511HTML/AIXM/DataType_ValDistanceVerticalBaseType.html). Wouldn't it be more logical to set the lowerLimit to GND and lowerLimitReference to SFC when SIGMET contains "SFC/FLnnn"? To avoid confusion with the "TOP FLnnn" case? According to the response from Yves Ernotte from Thales Air Systems Recommended encoding for SFC in AIXM is aixm:lowerLimit with value = GND, uom ='FT' and no aixm:lowerLimitReference. Best regards, Yves Ernotte (Thales Air Systems) Later Yves Ernotte commented that he took this suggestion from Digital NOTAM Specification: have taken this from the Digital NOTAM event specification chapter “5.4 Rules for encoding/decoding vertical limits” (http://www.aixm.aero/sites/aixm.aero/files/imce/library/Digital_NOTAM_Spec/digital_notam_event_specification_1.0.doc) Note that this is only a recommendation and that the document writes: The "...Reference" attribute shall be left empty in this situation. However, even if another uom is used or even if the "...Reference" attribute gets a value, they should be ignored by a recipient application because they do not have any meaning in combination with these coded values. So the only mandatory information is aixm:lowerLimit = GND and omitting it means “unknown“ to me which is not what we want.

This stems from cbs-tt-avxml:

braeckel commented 6 years ago

For the FLnnn, nnnnM, nnnnFT case we will document (probably in the TAC to XML Guidance document) that the lowerLimit and upperLimit should be the same in these cases.

For the ABV FLnnn case we agree. In Annex 3 there are SIGMET examples in the template "TOP BLW FL450" and "ABV FL250" which IWXXM should be able to represent. We will remove both of these rules in IWXXM 2.1.1, and look at this again in IWXXM 3 to see if there are any rules that should be enforced that are not present.

For the SFC/FL550 case, the IWXXM needs to represent all three cases:

-the lower limit is unspecified -the lower limit is "SFC" (ground level) -the lower limit is specified ("100FL", for example)

The only case that seems unclear is when the lower limit is unspecified (by the forecaster, for example). In this case the following can be used:

braeckel commented 6 years ago

The final case should be documented in the TAC to XML Guidance as well

blchoy commented 6 years ago

Schematron rules SIGMET.SEC3, SIGMET.SEC4, AIRMET.AEC9 and AIRMET.AEC10 were removed and committed under version 2.1.1RC1.

braeckel commented 6 years ago

Re-opening issue since there are two TAC-to-XML Guidance modifications that still need to be made in addition to the AIR/SIGMET Schematron changes

marqh commented 6 years ago

updates to https://github.com/wmo-im/iwxxm/blob/master/2.1.1RC1/TAC-to-XML-Guidance.txt are still required