AIRMET unable to represent ABV in phenomenon "CLD nnn/[ABV][n]nnnM"

blchoy commented 4 years ago

Tiaan Wessels pointed out this issue [cbs-tt-avxml:1101] and in fact it is true. The following is the relevant section of AIRMET Phenonemon in Annex 3:

Note that only ABV has been shown in the template.

While the solution can be as simply as adding a new Boolean attribute to indicated that the top is higher than the indicated value, we may also want to consider using the same representation as in the Level section discussed previously to align the representations and prepare in case a BLW is actually expected.

Views welcomed.

jkorosi commented 4 years ago

There are three kinds of ABV which can be reported in SIGMET:

TOP ABV FLbbb - This case is already defined.

<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"/>

ABV FLaaa - this is related to the base level so it can be constructed in similar principles as TOP ABV, just lowerLimit and minimumLimit should be used instead of upperLimit and maximumLimit. In addition, upperLimit and maximumLimit should be not reported in this case.

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

FLaaa/ABV FLbbb - I believe this case can be reported almost in the same way as in the case of TOP ABV because additional information about base level is also reported.

<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"/>
<aixm:lowerLimit uom="FL">aaa</aixm:upperLimit>
<aixm:lowerLimitReference>STD</aixm:lowerLimitReference>
<aixm:AirspaceVolume>

jkorosi commented 4 years ago

I saw the newest spacewx-A2-4.xml example where ABV FL350 is reported. It is encoded

<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
    <aixm:upperLimit uom="OTHER" xsi:nil="true" nilReason="unknown"/>
    <aixm:lowerLimit uom="FL">350</aixm:lowerLimit>
    <aixm:lowerLimitReference>STD</aixm:lowerLimitReference>
    <aixm:horizontalProjection>
        ...
    </aixm:horizontalProjection>
</aixm:AirspaceVolume>

This makes sense to me. The issue is how to represent FLaaa/ABV FLbbb because upperLimit is already used. But if maximumLimit is used instead of upperLimit then both cases can be represented.

blchoy commented 3 years ago

This makes sense to me. The issue is how to represent FLaaa/ABV FLbbb because upperLimit is already used. But if maximumLimit is used instead of upperLimit then both cases can be represented.

I will represent FLaaa/ABV FLbbb as below:

<aixm:AirspaceVolume>
    <aixm:maximumLimit uom="OTHER" xsi:nil="true" nilReason="unknown"/>
    <aixm:upperLimit uom="FL">bbb</aixm:upperLimit>
    <aixm:lowerLimit uom="FL">aaa</aixm:lowerLimit>
</aixm:AirspaceVolume>

blchoy commented 3 years ago

Looking at the AIRMET and SIGMET templates again, the main difference for element Phenomenon is that in AIRMET some of the phenomena (including SFC WIND, SFC VIS and CLD) have extra descriptions. I am not too sure the necessity to have these descriptions separated from the subsequent Location element but as long as this is the (TAC) format and people will issue messages in this format, I will try to accommodate as far as possible.

It seems to me that the most logical way to move on is to pull out these phenomena descriptions from iwxxm:AIRMETEvolvingCondition and put them back into iwxxm:AIRMET under a new optional element which I would like to call it iwxxm:phenomenonDescription. For example:

<iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/AirWxPhenomena/SFC_WIND/>
<iwxxm:phenomenonDescription>
    <iwxxm:surfaceWindDirection uom="deg">090</iwxxm:surfaceWindDirection>
    <iwxxm:surfaceWindSpeed uom="m/s">20</iwxxm:surfaceWindSpeed>
</iwxxm:phenomenonDescription>

Leaving behind iwxxm:geometry, iwxxm:directionOfMotion, iwxxm:speedOfMotion, iwxxm:intensityChange and iwxxm:approximateLocation in iwxxm:AIRMETEvolvingCondition. This will also make the structure of SIGMET and AIRMET closer.

mgoberfield commented 3 years ago

@blchoy & @jkorosi

For your consideration,

Make surfaceWindDirection element nillable in case no direction is given,
Indicate that surfaceWindSpeed value is a lower bound, either by changing the name (minimumSurfaceWindSpeed?), or adding an additional element/attribute to indicate 'above'.

blchoy commented 3 years ago

@blchoy & @jkorosi

For your consideration,

* Make surfaceWindDirection element nillable in case no direction is given,

* Indicate that surfaceWindSpeed value is a lower bound, either by changing the name (minimumSurfaceWindSpeed?), or adding an additional element/attribute to indicate 'above'.

Our office doesn't issue AIRMET so we are not too familiar with existing practices, especially we can't find any hints on the above in Annex 3:

I trust there must be reasons for your suggestion. Could you elaborate a bit more on the associated situations? I don't want to face the same problem as we have in TCA (#166).

blchoy commented 3 years ago

OK the following is my suggested representations:

Case I: SFC WIND

<iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/AirWxPhenomena/SFC_WIND"/>
<iwxxm:phenomenonDescription>
    <iwxxm:windDirection uom="deg">240</iwxxm:windDirection>
    <iwxxm:windSpeed uom="m/s">20</iwxxm:windSpeed>
    <iwxxm:analysis>...</iwxxm:analysis>
</iwxxm:phenomenonDescription>

Case II: SFC VIS

<iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/AirWxPhenomena/SFC_VIS"/>
<iwxxm:phenomenonDescription>
    <iwxxm:visibility uom="m">800</iwxxm:windDirection>
    <iwxxm:visibilityCause xlink:href="http://codes.wmo.int/49-2/WeatherCausingVisibilityReduction/FG"/>
    <iwxxm:analysis>...</iwxxm:analysis>
</iwxxm:phenomenonDescription>

Case III: CLD FLaaa/ABV FLbbb

<iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/AirWxPhenomena/BKN_CLD"/>
<iwxxm:phenomenonDescription>
    <iwxxm:base uom="FL">aaa</iwxxm:base>
    <iwxxm:baseReference>STD</iwxxm:baseReference>
    <iwxxm:top uom="FL">bbb</iwxxm:top>
    <iwxxm:topMaximum uom="OTHER" xsi:nil="true" nilReason="UNKNOWN"/>
    <iwxxm:topReference>STD</iwxxm:topReference>
    <iwxxm:analysis>...</iwxxm:analysis>
</iwxxm:phenomenonDescription>

Case IV: All other phenomena (e.g. isolated thunderstorms)

<iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/AirWxPhenomena/ISOL_TS"/>
<iwxxm:phenomenonDescription>
    <iwxxm:analysis>...</iwxxm:analysis>
</iwxxm:phenomenonDescription>

In all cases, the iwxxm:analysis part will reduce to:

<iwxxm:analysis>
    <iwxxm:AIRMETEvolvingConditionCollection ...>
    <iwxxm:phenomenonTime .../>
        <iwxxm:member>
            <iwxxm:AIRMETEvolvingCondition intensityChange="..." approximateLocation="...">
                <iwxxm:geometry .../>
                <iwxxm:directionOfMotion .../>
                <iwxxm:speedOfMotion .../>
            </iwxxm:AIRMETEvolvingCondition>
        </iwxxm:member>
    </iwxxm:AIRMETEvolvingConditionCollection>
</iwxxm:analysis>

mgoberfield commented 3 years ago

@blchoy the reason for my request to allow surface wind windDirection to be nill'd is that for the state of Alaska the regions affected are often quite large with complicated, often mountainous, terrain. While forecasters can, with reasonable confidence, state that surface wind speeds will be above a certain value, they are less confident of a specific value for surface wind direction which can be 'far off the mark' in complex terrain. For that reason, the forecasters often do not include wind direction in their AIRMETs. Other opinions/views welcomed.

My second bullet was a suggestion to make it clear that the value of the wind speed is a lower bound. The snippet of Annex 3 says that but it is not in the XML. (I do not feel strongly about this item, so if you don't want to change phenomenonDescription/windSpeed, that's fine.) Other opinions/views welcomed.

blchoy commented 3 years ago

It is fair enough for making windDirection nillable base on your use case. In contrast to intentionally not providing information which is non-sense or not possible for doing so, I will be cautious in giving information in a slightly different meaning than the SARPs. However if this is a genuine idea (may be also described in other ICAO documents?), I will incline to make the element name more verbose as there are a number of "windSpeed" in IWXXM; if they carry different concepts it is better to discriminate them.

ArnaudDumont commented 3 years ago

Supporting the comments from @mgoberfield about Alaska and Hawaii AIRMETS. When those MWOs report "STG SFC WND:"

they always specify a wind speed, either as "GREATER THAN 30 KT EXP" or occasionally in Hawaii as a range "20 TO 35 KTS EXP."
they rarely specify a wind direction (for reasons given earlier), but when they do, it can be a single direction such as "FM SW" or a range "W TO NW"
Alaska nearly always provides intensity change indicator (INTSF, WKN, or NC) whereas Hawaii never does.

blchoy commented 3 years ago

At the discussion of a TT-AvData meeting, the team agreed to take the least disruptive approach to implement the missing ABV representation for BRK CLD. To achieve this an optional element iwxxm:cloudTopAbove with type boolean will be added to indicate whether the cloud top is above the mentioned height. That is:

<iwxxm:cloudTop .../>
<iwxxm:cloudTopReference .../>
<iwxxm:cloudTopAbove>True</iwxxm:cloudTopAbove>

blchoy commented 3 years ago

This was fixed in IWXXM 2021-2RC1.

wmo-im / iwxxm

AIRMET unable to represent ABV in phenomenon "CLD nnn/[ABV][n]nnnM" #206