Amendment 78

[marqh]

Amendment 78 ICAO annex 3:

• Space Weather: #50

[dzinkhan]

SIGMET/AIRMET: Location may be described through circle by centerpoint (WI nnKM (or nnNM) OF Nnn[nn] or Snn[nn] Ennn[nn] or Wnnn[nn] , see tables C-21, C-22, _C-24

[braeckel]

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

• New product

VA Advisory/Table A2-1

• Template now makes it possible to issue test/exercise markers on TAC VA Advisories, effective Nov 2019. IWXXM already includes this

TC Advisory/Table A2-2

• The examples is the Annex is different, should be updated in the IWXXM examples
• Modified to allow test/exercise markers. IWXXM already includes this
• Modified to include Mandatory and Conditional markup for all fields (this should be compared with IWXXM to ensure they match)
• Modified to make advisory numbers include year and a slash (at minimum the IWXXM field description should be updated). Example: 2004/13
• "PSN" changed to "OBS PSN" - no IWXXM change
• OBS PSN now has an associated time - no change required, IWXXM already has a phenomenonTime. The example should be updated to reflect the new time
• New "Observed CB Cloud" field - should be added to IWXXM - this can be repeated per Note 3
• TCAs no longer allow "SLW" to indicate moving slowly

AIR/SIGMET

• Now possible to report FIR or UIR or FIR/UIR or CTA - this is already present in IWXXM
• Now possible to report TEST or EXERCISE messages - this is already present in IWXXM
• Added a fourth digit on altitudes, this is already present in IWXXM
• Now possible to report "ENTIRE FIR", "ENTIRE UIR", "ENTIRE CTA", and "ENTIRE FIR/UIR" - this is already possible to represent in IWXXM
• (As Dirk reported above) "WI 30 KM OF N6030 E02550" is now possible to report - this is already possible in IWXXM due to the fact that this can be represented with a CircleByCenterPoint/ ArcByCenterPoint. This should only be used in the case of radioactive clouds, but the IWXXM representation is generic enough that no rules should be needed
• "(or [TOP] ABV [n]nnnnFT)" was added to the Level part of the template, so "ABV 7000FT", "TOP ABV 9000FT" are both possible to report - no IWXXM impact since this is a units change to include "feet"
• TC forecast position is now a separate row in the template. Needs to be considered in the context of the OBS forecast position from IWXXM 2.1.1. Unknown impact - the example seems to be wrong - as it includes an italicized "or" and the "E1600015" has more digits than allowed in the template

[braeckel]

Further detail on the TC position/CB blocks added in Amd 77 and 78 is available in #57

[braeckel]

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.

[braeckel]

Noted issues with the Amd 78 changes (in the Annex itself):

• TC Advisory A2-2 template indicates that direction and speed of movement is a required element, but Example A2-2 no longer includes this section. The text and IWXXM XML from prior Annex 3 Amendments was retained in IWXXM and the schema remains unchanged, this will be passed on as an issue to be fixed in a future Annex amendment to Example A2-2

[blchoy]

My views on the SIGMET/AIRMET template is as follow:

1. We probably overlooked "Observed or forecast phenomenon" which is represented by OBS [AT nnnnZ] or FCST [AT nnnnZ]. In our current representation, that means iwxxm:analysis/iwxxm:SIGMETEvolvingConditionCollection/iwxxm:phenomenonTime can be non-existing.

2. For TC SIGMET, "Location" refers to the CB cloud and it can use all available descriptors under "Location" to describe the location of the CB cloud. The subsequent "Movement or expected movement" should refer to the CB cloud. Having said that, when "WI ??NM OF TC CENTRE" is being used to describe the location of CB cloud, the indicated movement and intensity change should also apply to the TC (centre) as well. We checked the TC SIGMET messages last year and this is a common practice of our Australian colleagues.

Based on the above I suggest the following structure for TC SIGMET:

<iwxxm:analysis>
    <iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">   <-- Mandatory
        <iwxxm:phenomenonTime/>   <-- Optional
        <iwxxm:member>
            <iwxxm:SIGMETEvolvingCondition-TC/>   <-- Mandatory for TC SIGMET.  For TC centre.  Only position is required
            <iwxxm:SIGMETEvolvingCondition/>   <-- Mandatory.  For CB cloud.  IF WI is used it should be linked to the TC position
        </iwxxm:member>
    </iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:SIGMETPositionCollection>   <-- Optional
        <iwxxm:phenomenonTime/>   <-- Mandatory
        <iwxxm:member>
            <iwxxm:SIGMETPosition-TC/>   <-- Optional.  For TC centre.  Only position is required
            <iwxxm:SIGMETPosition/>   <-- Optional.  For CB cloud.  IF WI is used it should be linked to the TC                    
        </iwxxm:member> 
    </iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>

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.

[braeckel]

With regards to your point 1, a missing phenomenonTime is currently represented as seen in:

https://github.com/wmo-im/iwxxm/blob/c3453f1a9ab51521821bf8c1e2057f895bb2c235/3.0.0RC1/examples/airmet-A6-1a-TS.xml#L80

AND

https://github.com/wmo-im/iwxxm/blob/c3453f1a9ab51521821bf8c1e2057f895bb2c235/3.0.0RC1/examples/sigmet-A6-1a-TS.xml#L84

We could make this optional but it is possible to represent today and has been around since IWXXM 2.1 and perhaps earlier.

[braeckel]

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>

[blchoy]

With regards to your point 1, a missing phenomenonTime is currently represented as seen in:...

Thank you. That looks fine.

[blchoy]

It might be appropriate to put both the TC and CB conditions under SIGMETEvolvingCondition and SIGMETPosition instead

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?

[blchoy]

There wouldn't be an easy way to associate the number and order of analysis and forecastPosition contents as is done today.

I am not too sure this is the case for 2 TCs/VAs cases (lets forget CB cloud for the moment):

<iwxxm:analysis>
    <iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            <iwxxm:SIGMETEvolvingCondition/>   <-- TC1
            <iwxxm:SIGMETEvolvingCondition/>   <-- TC2
        </iwxxm:member>
    </iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:SIGMETPositionCollection>
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            <iwxxm:SIGMETPosition/>   <-- TC1 or 2?
        </iwxxm:member> 
    </iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>

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:

<iwxxm:analysis>
    <iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            <iwxxm:SIGMETEvolvingCondition/>   <-- TC1
            <iwxxm:SIGMETEvolvingCondition/>   <-- TC2
        </iwxxm:member>
    </iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:SIGMETPositionCollection>
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            <iwxxm:SIGMETPosition nilReason="missing"/>   <-- TC1
            <iwxxm:SIGMETPosition/>   <-- TC2
        </iwxxm:member> 
    </iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>

Alternatively, do you think cross-referencing the gml:id of a iwxxm:SIGMETEvolvingCondition in iwxxm:SIGMETPosition works?

[braeckel]

I am not too sure this is the case for 2 TCs/VAs cases (lets forget CB cloud for the moment):

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.

[braeckel]

Hi @blchoy, the main options we discussed were implementing specialized TC behavior by:

1. composition - TropicalCycloneSIGMETEvolvingCondition "wraps" a TC position and CB conditions in a SIGMETEvolvingCondition. This makes the TC/CB split of conditions obvious but adds another level of elements for reporting CB. Here is an example
2. inheritance - TropicalCycloneSIGMETEvolvingCondition extends SIGMETEvolvingCondition. TropicalCycloneSIGMETEvolvingCondition information implicitly applies to CB conditions, and a separate element exists for the TC position. Here is an example
3. XSD union - looks similar to the inheritance option in XML but uses xsd:union instead of inheritance (i.e., substitutionGroups) in the XSDs

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.

[blchoy]

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):

YUDD SIGMET 2 VALID 101200/101800 YUSO–
YUDD SHANLON FIR TC GLORIA PSN N2100 W06200 CB OBS AT 1200Z WI 20NM 
OF TC CENTRE TOP FL500 WKN FCST AT 1800Z TC CENTRE N2230 W06330 AND
TC HARRIET PSN N2215 W06100 CB FCST AT 1200Z WI 20NM OF CENTRE TOP 
FL400 WKN FCST AT 1800Z TC CENTRE N2345 W06230=

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:

<iwxxm:analysis>
    <iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            ... TC1 ...
        </iwxxm:member>
    </iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:SIGMETPositionCollection>
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            ... TC1 ...
        </iwxxm:member> 
    </iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>
<iwxxm:analysis>
    <iwxxm:SIGMETEvolvingConditionCollection timeIndicator="OBSERVATION">
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            ... TC2 ...
        </iwxxm:member>
    </iwxxm:SIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:SIGMETPositionCollection>
        <iwxxm:phenomenonTime/>
        <iwxxm:member>
            ... TC2 ...
        </iwxxm:member> 
    </iwxxm:SIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>

It is hard to say the two OBS/FCST (and similarly FCST) sections can collapse into one as the <iwxxm:phenomenonTime> could be different.

Also the reason for having <iwxxm:member> is to allow multiple areas of a phenomenon, but now you will have to mention a TC centre (only one point) and a CB cloud (can have multiple areas).

Finally the TC/Volcano name is at the same level as <iwxxm:analysis> and <iwxxm:forecastPositionAnalysis>.

Seems to me that we need another discussion.

[blchoy]

We also found some SIGMET TAC template issues in Amendment 78:

1. Note 24 mentioned 'The elements “forecast time” and “forecast position” are not to be used in conjunction with the element “movement or expected movement”'. But in Amendment 78 "TC forecast position" was introduced and is not restricted for use by Note 24. Having said that without "forecast time" it is not possible to form a meaningful message.

2. "WI xxKM/NM OF TC CENTRE" can be used in the OBS/FCST section to describe the CB cloud but not in the FCST section. So one will need to use a polygon in the FCST section to describe the same disc mentioned in the OBS/FCST section.

3. The word CB is not present in "TC forecast position" following "TC CENTRE PSN xxxx" which is different from "Phenomenon" where we have "TC xxxx CENTRE PSN xxxx CB". Well this is a clarity issue of SIGMET TAC but do we want to be more explicit in XML?

4. Note 20 mentioned '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.' but "Forecast time" and "TC forecast position" are not included. Looks like a missing indicator for the two items since it is not possible to form a meaningful message without their presence.

[braeckel]

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?

[mgoberfield]

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.

[mgoberfield]

The Honolulu WFO also issues just one TC per TC SIGMET as well.

[braeckel]

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:

• [1..2] analysis
• [0..2] forecastPosition
• [1..2] TC with name
• the analysis and forecastPosition collections must be able to (optionally) have a reference id to indicate which TC they relate to. A Schematron rule will be added to ensure that if more than one analysis exists then the reference id must be set on all analyses and all forecastPositions
• a Schematron rule will be added to ensure that one analysis and at most one forecastPosition may be reported with non-TC SIGMETs. Only TCs can have multiple analyses or forecastPositions

[blchoy]

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.

[blchoy]

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..*].

[blchoy]

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 having a multiplicity of [1..2] to cater for this scenario.

[jkorosi]

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:

2b) In a sector of the FIR defined as being between two lines of latitude, or between two lines of longitude.

and

2c) In a sector of the FIR defined as being between two specified lines, or between two series of up to three connected lines, each with start and endpoints on the FIR boundary.

so according to this there should be always just one polygonal area.