Closed blchoy closed 3 years ago
There are three kinds of ABV which can be reported in SIGMET:
<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: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>
<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>
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.
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>
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.
@blchoy & @jkorosi
For your consideration,
@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).
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>
@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.
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.
Supporting the comments from @mgoberfield about Alaska and Hawaii AIRMETS. When those MWOs report "STG SFC WND:"
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>
This was fixed in IWXXM 2021-2RC1.
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.