SIGMET/AIRMET: Further comments on representing TOP ABV, TOP BLW, etc. [cbs-tt-avxml:938]

[blchoy]

@jkorosi pointed out that:

• I think there are incorrectly reported levels in SIGMET, AIRMET and ADVISORIES – TOP ABV, SFC/FLnnn, TOP FLnnn.
• I am also not sure how to represent TOP BLW

Currently, we are using aixm:upperLimit, aixm:upperLimit, iwxxm:geometryUpperLimitOperator and iwxxm:geometryLowerLimitOperator for "Level" reporting. A review of the cases, considering using aixm:AirspaceVolume as a bounding box to contain the weather phenomenon being described, and also the use of aixm:maximumLimit and aixm:minimumLimit to indicate the absolute top and bottom boundaries, had kindly been prepared by @jkorosi (simplified from the original text):

1. FLnnn, nnnnM, nnnnFT - e.g. FL300

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="FL">300</aixm:upperLimit>
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:lowerLimit uom="FL">300</aixm:lowerLimit>
   <aixm:lowerLimitReference>STD</aixm:lowerLimitReference>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

2. SFC/FLnnn, SFC/nnnnM, SFC/nnnnFT - e.g. SFC/FL300

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="FL">300</aixm:upperLimit>
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:lowerLimit uom="FL">GND</aixm:lowerLimit>
   <aixm:lowerLimitReference>SFC</aixm:lowerLimitReference>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

3. FLnnn/nnn, nnnn/nnnnM, nnnn/nnnnFT, nnnnM/FLnnn, nnnnFT/FLnnn - e.g.FL300/500

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="FL">500</aixm:upperLimit>
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:lowerLimit uom="FL">300</aixm:lowerLimit>
   <aixm:lowerLimitReference>STD</aixm:lowerLimitReference>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

4. TOP FLnnn - e.g. TOP FL300

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="FL">300</aixm:upperLimit>
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:lowerLimit uom="N/A" xsi:nil="true" nilReason="missing"/>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

5. TOP ABV FLnnn, TOP ABV nnnnFT - e.g. TOP ABV FL300

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="FL">300</aixm:upperLimit>
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:maximumLimit uom="N/A" xsi:nil="true" nilReason="unknown"/>
   <aixm:lowerLimit uom="N/A" xsi:nil="true" nilReason="unknown"/>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

6. TOP BLW FLnnn - e.g. TOP BLW FL300

   <iwxxm:geometry>
   <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
   <aixm:upperLimit uom="N/A" xsi:nil="true" nilReason="unknown" />
   <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
   <aixm:maximumLimit uom="FL">300</aixm:maximumLimit>
   <aixm:lowerLimit uom="N/A" xsi:nil="true" nilReason="unknown"/>
     ...
   </aixm:AirspaceVolume>
   </iwxxm:geometry>

@jkorosi has also proposed the use of aixm:Airspace instead of aixm:AirspaceVolume to better describe ABV and BLW.

This issue was raised to:

1. Review the representation of "Level" in IWXXM
2. Consider the addition of aixm:maximumLimit and aixm:minimumLimit to represent cases like TOP ABV, etc. and whether iwxxm:geometryUpperLimitOperator and iwxxm:geometryLowerLimitOperator are still required in this case
3. Consider the use of aixm:Airspace instead of aixm:AirspaceVolume which may better support current and future (more generalized representation) needs

[blchoy]

This is also related to #25

[porosnie]

In AIXM, the maximumLimit and minimumLimit are used to code values that override in some areas the upper/lower limits of an airspace volume, as explained here: https://ext.eurocontrol.int/aixm_confluence/display/ACGAIP/Vertical+Limits+of+Airspace.

If I understand correctly, in IWXXM they would be used with different meaning. In AIXM, maximum and minimum limits are heights above the surface, while in the examples above they take FL values. I see a risk of confusion for someone who knows their meaning in AIXM and thinking that in iWXXM they mean the same, or vice-versa.

[blchoy]

@porosnie let's study the following cases. In Case A, we may code it as TOP FLaaa:

  <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
    <aixm:upperLimit uom="FL">aaa</aixm:upperLimit>
    <aixm:upperLimitReference>STD</aixm:lowerLimitReference>

or TOP BLW FLaaa, depending on situation:

  <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
    <aixm:upperLimit uom="N/A" xsi:nil="true" nilReason="unknown" />
    <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
    <aixm:maximumLimit uom="FL">aaa</aixm:maximumLimit>

For Case B, FLbbb is probably the best estimate one can make, but he/she cannot be sure if there is anything higher up, hence one may code it as TOP ABV FLbbb:

  <aixm:AirspaceVolume gml:id="uuid.8ed71782-7c63-4ca5-9ed6-a31b788f64af">
    <aixm:upperLimit uom="FL">bbb</aixm:upperLimit>
    <aixm:upperLimitReference>STD</aixm:lowerLimitReference>
    <aixm:maximumLimit uom="N/A" xsi:nil="true" nilReason="unknown"/>

It seems to me the above look pretty close to your example in https://ext.eurocontrol.int/aixm_confluence/display/ACGAIP/Vertical+Limits+of+Airspace. Correct me if I am wrong.

[blchoy]

To summarize, if we adopted the above as the general way of representing the 3D extend of a phenomenon, the following elements will no longer be necessary:

SIGMET/AIRMET: geometryLowerLimitOperator, geometryUpperLimitOperator VAA: windLowerLimit, windLowerLimitReference, windUpperLimit, windUpperLimitReference SWA: locationLowerLimitOperator

[blchoy]

Please also take a look at Patrick Simon's comment in cbs-tt-avxml:940.

[blchoy]

In the telecon on 24 Aug 2018, while it had been decided to have further conversations with @porosnie on whether AirSpaceVolume is an appropriate feature to be used to describe a bounding box for weather phenomenon, there is also a need to collect real life cases how people are describing different phenomena before we could arrived at a conclusion. Thanks @mgoberfield and Patrick Simon we already have some. More are welcome!

[porosnie]

I agree that maximumLimit is very close to what you need in IWXXM for coding the overshooting situation shown in the diagram. My only worry is that the AIXM definition of the maximumLimit says that it "overrides the upper limit, in those parts of the airspace where the upper limit is situated below the maximum limit".

In the AIXM example (https://ext.eurocontrol.int/aixm_confluence/display/ACGAIP/Vertical+Limits+of+Airspace), the maximumLimit has a different uom and reference (2000 FT above surface). This links it to the shape of the ground and allows to precisely identify the areas where the maximumLimit overrides the upperLimit.

If both the upperLimit and the maximumLimit use the same uom and reference (such as FL and STD in your example), then the maximumLimit practically overrides the upperLimit everywhere (or nowhere, depending on the actual values). The risk is that developers of AIXM code rely on the AIXM coding guidelines for interpreting the maximumLimit and might interpret it wrongly when applying the same code to the IWXXM use case. However, this is probably a low risk since the use of the maximumLimit in IWXXM will be explain in the IWXXM coding rules and the code developers will take those rules into account.

Another comment concerning your examples is that uom="N/A" is not allowed by the AIXM schema. This is the reason why uom is an optional attribute, so that it can be left empty when not necessary. The case B could be coded as follows:

bbb STD

[blchoy]

Thanks @porosnie for his analysis.

@braeckel the next question is whether we consider AirspaceVolume alone is adequate to describe the extend of the weather phenomenon and make changes to IWXXM as mentioned in my previous post:

To summarize, if we adopted the above as the general way of representing the 3D extend of a phenomenon, the following elements will no longer be necessary:

SIGMET/AIRMET: geometryLowerLimitOperator, geometryUpperLimitOperator VAA: windLowerLimit, windLowerLimitReference, windUpperLimit, windUpperLimitReference SWA: locationLowerLimitOperator

[braeckel]

The proposed approach will work as long as we fully document each of the cases for producers and consumers. Choy and I checked each of the AIR/SIGMET cases and it appears to work for all of them. The disadvantage of utilizing AirspaceVolume is that it is not as easy to map the TAC definitions to the AIXM upper/lower/max/min limits, but this can be resolved with documentation. Therefore one task would be to update the TAC to XML Guidance to include all of the TAC cases.

The AIXM_WX profile will need to be updated as it does not currently include maximumLimit and minimumLimit elements, and the IWXXM schema would need to be changed to include the newer version of this profile. We would need to remove the upperLimitOperator, lowerLimitOperator and related elements and update the examples accordingly. It is probably worthwhile to include the AIXM_WX profile schemas in the IWXXM release going forward.

[mgoberfield]

Please also examine the changes that will occur to the VAA product with this approach, specifically the 'VA NOT IDENTIFIABLE FM SATELLITE DATA' case.

[blchoy]

This is fixed in 3.0.0RC2.