Amendment 78 #49
Comments
|
SIGMET/AIRMET: |
|
Please review and improve upon what I have below, this comes from the draft distributed on Jan 23. I've tried to be exhaustive and cover every change to be sure everything is included. Here is the State Letter that was issued (not final). Space Weather
VA Advisory/Table A2-1
TC Advisory/Table A2-2
AIR/SIGMET
|
|
Further detail on the TC position/CB blocks added in Amd 77 and 78 is available in #57 |
|
Choy and Dirk will look up current practices on SIGMET TC CB conditions in different regions and try to determine which IWXXM changes will be required. The template is not very clear. |
|
Noted issues with the Amd 78 changes (in the Annex itself):
|
|
My views on the SIGMET/AIRMET template is as follow:
Based on the above I suggest the following structure for TC SIGMET: I have to say that while this structure faithfully reproduces its TAC counterpart, it also inherits the fuzziness of movement and intensity change when the CB cloud is not coupled with the TC centre through "WI" (CB cloud and TC (centre) can move in different directions and have different intensity changes). This is definitely a TAC deficiency from my point of view, but the question is whether we would like to also include movement and intensity change right now in iwxxm:SIGMETEvolvingCondition-TC which may also confuse software developers? Views most welcomed. |
|
With regards to your point 1, a missing phenomenonTime is currently represented as seen in: AND We could make this optional but it is possible to represent today and has been around since IWXXM 2.1 and perhaps earlier. |
|
An issue with having two different types of SIGMETEvolvingCondition (both TC and CB) is that these currently have an associated order and relationship between the analysis conditions and the forecastPositionAnalysis conditions - for example see sigmet-multi-location.xml. In other words there is a 1-to-1 match between the # of SIGMETEvolvingConditions, # of SIGMETPositions, and the # of conceptual geographic areas of impact. This relationship would become more complex if we introduce two different types of these (CB and TC). For example, if the analysis and forecast position sections have a difference in whether they report TC/CB conditions (analysis has CB but forecast position does not) this would break the cases where multiple areas of impact are reported because there might be two conditions in the analysis and only one in the forecast position. There wouldn't be an easy way to associate the number and order of analysis and forecastPosition contents as is done today. It might be appropriate to put both the TC and CB conditions under SIGMETEvolvingCondition and SIGMETPosition instead. This would look like the following: <iwxxm:analysis>
<iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">
<iwxxm:phenomenonTime/>
<iwxxm:member>
<iwxxm:SIGMETEvolvingCondition> <!-- can be repeated - once for each area of occurrence in this SIGMET -->
<iwxxm:TCConditions/> <!-- element names to be decided later... -->
<iwxxm:CBConditions/>
</iwxxm:SIGMETEvolvingCondition>
</iwxxm:member>
</iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
<iwxxm:SIGMETPositionCollection>
<iwxxm:phenomenonTime/>
<iwxxm:member>
<iwxxm:SIGMETPosition> <!-- can be repeated - once for each area of occurrence in this SIGMET. Should match the number of SIGMETEvolvingConditions above -->
<iwxxm:TCConditions/>
<iwxxm:CBConditions/>
</iwxxm:member>
</iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis> |
Thank you. That looks fine. |
I thought the sharable blocks among different types of weather phenomenon are iwxxm:SIGMETEvolvingCondition and iwxxm:SIGMETPosition? Oh by the way, are we going to generalize iwxxm:SIGMETEvolvingCondition and iwxxm:SIGMETPosition by making them into one as mentioned in #84? |
I am not too sure this is the case for 2 TCs/VAs cases (lets forget CB cloud for the moment): Unless you mandate with the use of schematron when it is a TC or VA SIGMET the number of iwxxm:SIGMETPosition must be the same as the number of iwxxm:SIGMETEvolvingCondition: Alternatively, do you think cross-referencing the gml:id of a iwxxm:SIGMETEvolvingCondition in iwxxm:SIGMETPosition works? |
You are correct - here is the conclusion from our work on this last year. My takeaway now is that there is an association suggested in the SIGMET guides between the two sets of contents, but from a meteorological perspective it can vary and it was decided that rules enforcing a strict relationship were not appropriate. This seems somewhat contradictory. Looking over this with fresh eyes I like the idea of having an optional reference (not sure what to call it - 'earlierConditionId' isn't ideal) from a SIGMETPosition to an earlier SIGMET phenomenon to make the relationships explicit. It probably makes sense to go one direction only - from a later set of conditions to an earlier set of conditions. Adding this would make it possible to explicitly indicate which conditions are newer developments of which other conditions, as opposed to the implicit relationships we have now and with the TAC codes. On the broader point I still favor having a single SIGMETPosition and SIGMETEvolvingCondition that has both CB and TC information - this unifies all of the reported conditions in a single place regardless of whether it is a VA SIGMET, TS SIGMET, or TC SIGMET. This is hard to discuss effectively in text form, let's try to set up a phone discussion. |
|
Hi @blchoy, the main options we discussed were implementing specialized TC behavior by:
For simplicity I've discussed only SIGMETEvolvingCondition but it would also apply to SIGMETPosition, as seen in the examples. We concluded preferring option 1, I am sharing these examples for review and will embark on the XSD changes shortly. |
|
We have an internal discussion today and I noticed that our discussion on 2 TC/VA so far was probably inadequate. So far we have implemented the possibility of having multiple areas of a phenomenon (This is our example). The 2 TC/VA requirement is different. The following is the example taken from the Asia/Pacific SIGMET Guide (in accordance to Amendment 77 but is good enough for following discussions): So it is basically concatenation of 2 phenomena of the same type (TC or VA), each of them has its own OBS/FCST and FCST sections. This is equivalent to: It is hard to say the two OBS/FCST (and similarly FCST) sections can collapse into one as the Also the reason for having Finally the TC/Volcano name is at the same level as Seems to me that we need another discussion. |
|
We also found some SIGMET TAC template issues in Amendment 78:
|
|
Results of discussion today are that the double TC SIGMETs (with two TCs) are being discouraged but are currently allowed and have been allowed for some time in Annex 3. Therefore we should support the case of two TCs. We would also like to determine whether the double TC SIGMET (Gloria and Harriet) situation is being used outside of AsiaPac. @mgoberfield @marqh - do you know whether these types of SIGMETs are being issued by either the Americas or the UK? |
|
I contacted a SME at AWC on this scenario (Atlantic). Their policy is a TC SIGMET shall only contain one tropical cyclone. If there are multiple tropical cyclones in their area of responsibility, each storm gets a separate series and number. A TC SIGMET can span multiple FIRs as circumstances require. I will contact WFO Honolulu (Pacific) to see if they have the same policy. I hope this is helpful to the discussion. The SME suggested that examples will be provided at a later time. If such examples would contribute to the discussion, please let me know and I will pass them on. |
|
The Honolulu WFO also issues just one TC per TC SIGMET as well. |
|
From Choy and my discussion today - due to the possibility of dual TC representations in the Annex we need to support this case, but given that AsiaPac and North America do not use these it suggests that we should not do anything that changes the fundamental structure of SIGMET. TCs are only one type of SIGMET and we need to be ensure that making dual TC cases possible does not make the other 99.9% of SIGMETs more complex. VA SIGMETs do not have as much complexity, they do not allow two different volcanoes to be reported in the same SIGMET but do allow two VA clouds from the same volcano. We will put a dual TC example in the IWXXM translation repository for reference. To handle dual TC cases we need:
|
|
An alternative description of the 2 TC case by reorganizing the analysis and forecastPositionAnalysis parts of a TC and its CB can be found here. This preserves most of the structure of iwxxm:analysis and iwxxm:forecastPositionAnalysis across different types of SIGMET yet allowing the decoding software to link up a TC position and its CB location(s). [In a separation discussion, it is apparent that "Movement or expected movement" and "Changes in intensity" which are specified after the CB descriptions could also be interpreted as describing the TC centre, even though "WI ??NM OF TC CENTRE" is not being used to describe the associated CB. To improve clarity of the corresponding IWXXM messages, provisions of optional "Movement or expected movement" and "Changes in intensity" descriptions for the TC centre may be beneficial. So one may want to leave this items out if he/she would like to have strict adherence to the corresponding TAC, but could also elect to provide this information for the TC centre as necessary.] A 2 VA cloud example based on the same idea is also available here. |
|
There is another issue which we need to be fixed: Note 20 of the SIGMET template mentioned that "In the case of volcanic ash cloud or cumulonimbus clouds associated with a tropical cyclone covering more than one area within the FIR, these elements can be repeated, as necessary". Template fields like Location, Level, Movement or expected movement, Changes in intensity in the OBS/FCST section and Forecast position in the FCST section are under Note 20. Fortunately they are already under iwxxm:member and is already allowed to be repeated. What we need to do is to make sure that the multiplicity of iwxxm:member under both iwxxm:SIGMETEvolvingConditionCollection and iwxxm:SIGMETPositionCollection is [1..*]. |
|
A probably last item to consider for SIGMET in general is the use of "N OF Nnn[nn] or N OF Snn[nn] AND S OF Nnn[nn] or S OF Snn[nn]" in Location in the OBS/FCST section. While all the examples shown are talking about a single area bounded by lines described with this notation (e.g. S OF N10 AND N OF N05), the current provisions could also allow disjointed areas like "N OF N10 AND S OF N05". Seems to me that we probably need to make iwxxm:geometry having a multiplicity of [1..2] to cater for this scenario. |
|
I am not sure what is the practice outside of Europe but EUR Documents:014 - EUR SIGMET and AIRMET Guide describes locations in section 3.4.3.1.4 Location of the phenomenon in following way:
and
so according to this there should be always just one polygonal area. |
Amendment 78 ICAO annex 3:
The text was updated successfully, but these errors were encountered: