Potential issue with "TC forecast position" in the SIGMET TAC template

[blchoy]

In an off-topic discussion (cbs-tt-avxml:1145), it was noticed there may be a case where the existing IWXXM SIGMET cannot represent the corresponding TAC message. Take a look at the section of SIGMET TAC template involved:

Note 25 said 'The elements “forecast time” and “forecast position” are not to be used in conjunction with the element “movement or expected movement”'.

Interestingly, Note 25 does not apply to "TC forecast position". In fact, this element specifically requires the forecast position of TC centre to be at the end of the validity period of the SIGMET message. In other words, for a TC SIGMET, one can provide "movement or expected movement", skip "forecast time" and "forecast position" (therefore not mentioning CB cloud forecast), but can still provide the forecast position of TC centre with "TC forecast position" with no ambiguity of the forecast time, without violating the SIGMET TAC template requirements.

I doubt very much this is the original intent and I am not too sure if there are MWOs exploiting this possibility. However if they do and is popular, we may need to adjust IWXXM to accommodate the simultaneous mentioning of movement and forecast for TC SIGMET.

[blchoy]

A quick check of TC SIGMETs from 6 FIRs (VHHK, RKRR, RJJJ, RCAA, NZZO, LPPO) during 1 Jan 2018 to 29 Feb 2020:

Total number of WC SIGMET reports : 4899 Number of reports used "TC CENTRE PSN" : 914 (18.7%) Number of reports used "FCST AT xxxxZ TC CENTRE PSN": 914 (18.7%)

I feel a bit more comfortable now :)

[blchoy]

Looks like I have overlooked the changes in the proposed Amendment 79:

As "TC forecast position" no longer linked to the end time of the valid period, it will definitely need the preceding "FCST AT" and therefore should go away with them if "MOV" is present. Case closed.

[jkorosi]

Hi Choy, all,

I am afraid we cannot close this case yet. I believe that the movement and the intensity are related to the centre of the tropical cyclone.

Why I think so

• In the Table A6-1A, there is missing footnote 21. Therefore they can occur only once in the SIGMET, but there can be more than one CB.

  21. In the case of cumulonimbus clouds associated with a tropical cyclone covering more than one area within the FIR, these elements can be repeated as necessary. Each location and forecast position must be preceded by an observed or forecast time.

• In the TC ADVISORY, the movement group was presented in TC ADVISORY before CB group was added (in the previous amendment). Therefore it has to be related to the position of the centre, which was the only one available location. Also, CB group can be repeated opposite to teh movement group. So if the movment was related to CB then also movement would be repeated. The TC SIGMET warning is usually based on TC ADVISORY.

  Where I see a problem

  My opinion is that the movement and intensity can be reported on CB currently and not on tc centre. Let see the simplified example:

  <iwxxm:issueTime/>
  <iwxxm:issuingAirTrafficServicesUnit/>
  <iwxxm:originatingMeteorologicalWatchOffice/>
  <iwxxm:issuingAirTrafficServicesRegion/>
  <iwxxm:sequenceNumber/>
  <iwxxm:validPeriod/>
  <iwxxm:phenomenon/>
  <iwxxm:analysis>
      <iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection tropicalCycloneId="uuid.c529d539-2fa9-428d-937a-867e50056f16">
          <iwxxm:phenomenonTime/>
          <iwxxm:member>
              <iwxxm:SIGMETEvolvingCondition>
                  <iwxxm:geometry>
                      <aixm:AirspaceVolume>
                          <aixm:upperLimit/>
                          <aixm:upperLimitReference/>
                          <aixm:horizontalProjection/>
                      </aixm:AirspaceVolume>
                  </iwxxm:geometry>
                  <iwxxm:directionOfMotion/>
                  <iwxxm:speedOfMotion/>
              </iwxxm:SIGMETEvolvingCondition>
          </iwxxm:member>
          <iwxxm:tropicalCyclonePosition/>
      </iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection>
  </iwxxm:analysis>
  <iwxxm:tropicalCyclone>
      <metce:TropicalCyclone gml:id="uuid.c529d539-2fa9-428d-937a-867e50056f16">
          <metce:name>Gloria</metce:name>
      </metce:TropicalCyclone>
  </iwxxm:tropicalCyclone>
  </iwxxm:TropicalCycloneSIGMET>

  If we need to report several CBs, where should be movment reported?

  Proposals

• The workaround is to report the same movement and intensity on all SIGMETEvolvingCondition elements. Of course, it can be confusing, therefore I think we should fix it in next release. This should be mentioned in TAC-to-XML-Guidance.txt.
• The next release fix should move movement and intensity to

  <iwxxm:TropicalCycloneSIGMET>
  <iwxxm:issueTime/>
  <iwxxm:issuingAirTrafficServicesUnit/>
  <iwxxm:originatingMeteorologicalWatchOffice/>
  <iwxxm:issuingAirTrafficServicesRegion/>
  <iwxxm:sequenceNumber/>
  <iwxxm:validPeriod/>
  <iwxxm:phenomenon/>
  <iwxxm:analysis>
      <iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection tropicalCycloneId="uuid.c529d539-2fa9-428d-937a-867e50056f16">
          <iwxxm:phenomenonTime/>
          <iwxxm:member>
              <iwxxm:SIGMETEvolvingCondition >
                  <iwxxm:geometry>
                      <aixm:AirspaceVolume>
                          <aixm:upperLimit/>
                          <aixm:upperLimitReference/>
                          <aixm:horizontalProjection/>
                      </aixm:AirspaceVolume>
                  </iwxxm:geometry>
              </iwxxm:SIGMETEvolvingCondition>
          </iwxxm:member>
          <iwxxm:tropicalCyclonePosition intensityChange="WEAKEN">
              <iwxxm:directionOfMotion/>
              <iwxxm:speedOfMotion/>
          </iwxxm:tropicalCyclonePosition>
      </iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection>
  </iwxxm:analysis>
  <iwxxm:tropicalCyclone>
      <metce:TropicalCyclone gml:id="uuid.c529d539-2fa9-428d-937a-867e50056f16">
          <metce:name>Gloria</metce:name>
      </metce:TropicalCyclone>
  </iwxxm:tropicalCyclone>
  </iwxxm:TropicalCycloneSIGMET>

  Of course, all of this is based on the assumption that the movement and intensity are related to the TC centre. If they are not, then the footnote 21 has to be added to movement and intensity in the next amendment.

Any comment welcome. Jan

[blchoy]

The following are extracted from the working paper WP-6005 of METP/2 proposing changes to Table A6-1A in Amendment 78:

With reference to Para. 2.2.3, your assumption that the movement and intensity are associated with the centre of the tropical cyclone does not seem to be the original intention. It looks more like to me that Note 21 is missing for the two elements.

[jkorosi]

The paragraph 2.2.3 says that there have to be two groups related to locations in the forecast at the end of the validity in the case of TC SIGMET. One for TC centre and one for CBs. That is like you report two movements, one for TC centre and one for CBs. So it is hard to say if originally was the movement related to TC centre or CBs. And we cannot apply this fact for intensity.

I agree with you that more probable is that note 21 is missing. But then I have a question about the usage of the word “AND”. It was previously used to report two TC cyclones in one SIGMET. Now it should be used to report several CBs. There are to consequences:

• The TAC TC SIGMET can now report only one TC cyclone.
• The note 21 is missing also on “TC forecast position”. Therefore it should be included only once in the TC SIGMET. How should we construct TC SIGNET with more than 2 CBs?

So now I have two questions, which can have an impact also on IWXXM:

1. My original question is “Are movement and intensity related to TC CENTRE or to CBs?” In other words, which of the following SIGMETs is corrects? or
2. What does the TC SIGMET look like, when we use the forecast at the end of the validity? or it should be something like To be honest, it seems to me that there is no way how to create such SIGMET in TAC correctly.

I prepare two tables which include all combination allowed by table A6-1A. and I believe that:

• CB in “TC forecast position” should be used only when CB location follows.
• If CB is not reported in “TC forecast position” then only TC centre should be reported.

Based on this I disqualified options 2, 3, 5, 7, 8, 9, 11 in both tables. The rest of the options seems to me to be valid.

To me, it is not clear how TC SIGMET should be constructed. Both alternatives seem to have pros and cons. The movement and intensity can be now reported only on CBs in the IWXXM 3.0.0. So maybe it is everything alright for IWXXM, but then I see some issues in the following amendment.

All examples are attached here TC SIGMET examples.docx

[blchoy]

The following is extracted from the latest APAC SIGMET Guide which includes changes agreed for Am78:

Comparing TAC with IWXXM: TAC: TC PSN + CB + Movement + Intensity change IWXXM: CB + Movement + Intensity | TC PSN

To me, movement and intensity change can quantify CB or TC and CB in TAC, but only CB in IWXXM.

There are many ways to solve this problem; either make ourselves clear about the TAC, or put TC PSN together with CB in IWXXM to make it as ambiguous as TAC (but at least the representation is closer in nature).

I am re-opening this issue for discussion of broader audience.

[jkorosi]

Hi all,

I attended a teleconference organized by Mr Raul Romero, where the structure of TC SIGMET was discussed. The conclusion is that the movement and intensity of TC SIGMET are definitely related to TC Centre and not to CB Clouds. This is not possible to specify in the current implementation.

Also, only one TC Cyclone can be defined in TAC SIGMET, not two as it was in the previous amendment. I don't know if we still want to combine several SIGMET in this way, instead of issuing two separated SIGMET which can be joined by collective. This can be confusing when two different mechanism will be allowed to produce. It also increased the complexity of implementation. And I am not sure if anyone will use this option at all.

What I also realize is, that there is no way how to make a connection between observation and forecast of CB clouds. The similar mechanism (where two TC cyclones are reported in one SIGMET) as Choy implemented for binding of \<iwxxm:TropicalCycloneSIGMETPositionCollection/> and \<iwxxm:TropicalCycloneSIGMETPositionCollection/> to \<iwxxm:tropicalCyclone/> by tropicalCycloneId attribute should be implemented for \<iwxxm:member> too. So we can bing each observation to each forecast. In the TAC is this achieved by joining of OBS+FCST pair by word AND. The same should be done for Volcanic Ash, maybe also for all kind of SIGMET, so it will be possible to use this phenomena definitions for other purposes in the futures, e.g. in some derived products.

[blchoy]

This is an example of a TC SIGMET using AND to describe the second CB associated with the cyclone. Note that this and following examples comes from the yet to be published SIGMET Guide so USE WITH CARE:

So the outline of the message is something like:

1. OBS/FCST + time1 + TC static properties + TC dynamic properties@time1 + CB1 properties@time1 + intensity change@time1
2. FCST + time2 + TC dynamic properties@time2 + CB1 properties@time2
3. AND
4. OBS/FCST + time1 + CB2 properties@time1
5. FCST + time2 + CB2 properties@time2

Example of VA SIGMET with multiple ash clouds:

And the message outline is very similar to that of a TC SIGMET:

1. OBS/FCST + time1 + Volcano static properties + VA1 properties@time1 + intensity change@time1
2. FCST + time2 + VA1 properties@time2
3. AND
4. OBS/FCST + time1 + VA2 properties@time1
5. FCST + time2 + VA2 properties@time2

For other phenomena:

It is basically (1) and (2) only:

1. OBS/FCST + time1 + phenomenon + phenomenon properties@time1 + intensity change@time1
2. FCST + time2 + phenomenon properties@time2

The revised SIGMET Guide specifically mentioned that for concave FIR one may need to issue two separate SIGMETs for a single phenomenon affecting two different parts of the FIR:

We now have a much clearer picture of what and how things should be represented in a SIGMET/AIRMET.

[blchoy]

@jkorosi wrote:

I attended a teleconference organized by Mr Raul Romero, where the structure of TC SIGMET was discussed. The conclusion is that the movement and intensity of TC SIGMET are definitely related to TC Centre and not to CB Clouds. This is not possible to specify in the current implementation.

A minimal change is to allow the provision of iwxxm:directionOfMotion, iwxxm:speedOfMotion and @intensityChange under iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection and suppress the occurrence of them under iwxxm:SIGMETEvolvingCondition with a schematron rule. The following is a revised class diagram on such changes:

What I also realize is, that there is no way how to make a connection between observation and forecast of CB clouds. The similar mechanism (where two TC cyclones are reported in one SIGMET) as Choy implemented for binding of and to by tropicalCycloneId attribute should be implemented for too. So we can bing each observation to each forecast. In the TAC is this achieved by joining of OBS+FCST pair by word AND. The same should be done for Volcanic Ash, maybe also for all kind of SIGMET, so it will be possible to use this phenomena definitions for other purposes in the futures, e.g. in some derived products.

Fortunately there is no requirement to link up observe and forecast CBs right now. We will provide this capability in the new WxObject feature.

[blchoy]

Further to the discussion with @jkorosi on the desire to maintain relationship between the OBS/FCST and FCST CB or VA clouds, in particular when there are multiple clouds being included with the conjunction AND. That is:

OBS/FCST + FCST AND OBS/FCST + FCST AND OBS/FCST +FCST

I suspect a better way is not to repeat iwxxm:SIGMETEvolvoingCondition and iwxxm:SIGMETPosition (and hence the need to have a link to link up the two for multiple clouds) but a new iwxxm:analysisAndForecastAnalysis within iwxxm:VolcanicAshSIGMET or iwxxm:TropicalCycloneSIGMET as below:

This should faithfully emulate the structure of the TAC message.

Views please?

[moryakovdv]

+1 for collection element. But I would suggest name it with suffix 'Collection' for clarity. Something like AnalysisCollection. BTW, the structure of the parent SIGMET should be changed in this case. E.g. analisys and forecastPositionAnalysis go away and AnalysisCollection substitutes them, right?

[blchoy]

BTW, the structure of the parent SIGMET should be changed in this case. E.g. analisys and forecastPositionAnalysis go away and AnalysisCollection substitutes them, right?

I agree, as it makes things more elegant. However, this will also affect WS SIGMET producers and consumers. I would like to see others' comment on this too.

[jkorosi]

I am not sure if I understand the proposed change. If you want to merge analysis and forecastPositionAnalysis (what is also writing @moryakovdv), this should be done in the SIGMET parent class. But this is not backward compatible change. On the other hand, I agree that the change in the data model is the right way we should go. The related issue is also the repetition of observation time in VA and TC SIGMET. Now it can be defined only on collection, but from AMD 79 it has to be defined on SIGMETEvolvingCondition.

We should move from to it's child , or even to . This should be fine for all kind of SIGMET, because there is always only one for WS SIGMET.

I like the idea to join the and elements. There is also a significant difference between in structure of WS, TC and VA SIGMET.

1. WS SIGMET There is always only one and there can be 0 or 1 . Therefor it does not matter where the is define. The same principle is valid also for timeIndicator attribute of . And also for intensityChange and approximateLocation attributes on . And also on and child elements of .
2. VA SIGMET The primary penomena are VA clouds. So we need to define multiple primary penomena. It implies that has to be defined on or . This is the only one needed change. All previously mentioned atributes timeIndicator, intensityChange and approximateLocation are defined on right places. Also the and are defined on rigt places. The related volcano is "only" additional informartion, not so important in fact.
3. TC SIGMET The primary phenomenon is TC CENTRE. We can define multiple secondary/auxiliary phenomena - CB clouds. The movement, intensity is related to TC centre. The observation time is related to CB clouds. From AMD 79 there can be defined only one TC CENTRE in TC SIGMET. I think the position in should be the TC CENTRE location instead of CB cloud position. This should solve the movement and intensity issue. The last issue is the observation time, which is from AMD 79 related to CB clouds. Interestingly, there is no observation time INFORMATION for TC CENTRE in analysis nor the forecast at the end of the validity. I believe this is not correct in TAC definition, and nobody realized it during AMD 79 approval. The possible solution is to left observation time as is in IWXXM specification. In addition, we should introduce a new CB related element in TC SIGMET data model.

Now back to the original intention of this task. We want to introduce the ability to define the relation between OBS1 + FCTS1, OBS2 + FCST2,... If we introduce the changes proposed above, it implies significant changes in the data model. Also, the logical interpretation will be different. Therefore I like the idea to join and element. The advantage is that TAC cannot represent the cases where one VA cloud splits into two clouds. Or two clouds are joined in the forecast, but there left other clouds, so NO VA EXPECTED cannot be reported. In these cases is the recommendation to issue two separated SIGMET warning. We have an opportunity to define IWXXM data model, which will be not restricted by TAC abilities.

[jkorosi]

Maybe we should resurrect the idea of the SIGMET Base class and define three separated modules, one for each kind of SIGMET. The base SIGMET class can be even SIGMET/AIRMET base class, and defines the first and second lines of SIGMET/AIRMET, except the phenomenon. The rest should be specified in derived classes. I know that it is beyond the original intention of this task, but it seems to me like a step in the right way.

[moryakovdv]

Maybe we should resurrect the idea of the SIGMET Base class and define three separated modules, one for each kind of SIGMET. The base SIGMET class can be even SIGMET/AIRMET base class, and defines the first and second lines of SIGMET/AIRMET, except the phenomenon. The rest should be specified in derived classes. I know that it is beyond the original intention of this task, but it seems to me like a step in the right way.

Agree. Both of the above solutions meet OOP methodology but applying them will break backward compatibility completely. Is there a milestone for such changes? Or we are talking about (far) future releases?

[blchoy]

I think I have come up with a solution taking into comments from @jkorosi and @moryakovdv.

The only changes we need to have are the following:

The important point is the revised schematron rules which mandates the use of SIGMETEvolvingCondition and SIGMETPosition in supplementaryAnalysisCollection. In this way we can emulate the TAC representation after AND.

(Sorry I forgot to change the corresponding constraints in the SIGMET class, but I am sure you know what I mean ;) )

Comments?

[blchoy]

This should also be cleared with the completion of FT2021-2RC2.