wmo-im / iwxxm

XML schema and Schematron for aviation weather data exchange
https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML
48 stars 22 forks source link

Add support for Amd 77 TC SIGMET center positions and CB positions #57

Closed braeckel closed 6 years ago

braeckel commented 6 years ago

In SIGMET in Amd 77 two important pieces were added for TC SIGMETs that do not appear to representable in IWXXM 2.1: the position of TC CENTREs outside of an OBS or FCST section and reporting CB positions instead of TC positions. The differences in Amd 77 may be viewed on p40-48 (PDF pages 62-70) of this document.

See the screen shot of the TC SIGMET example below. The important implications of this example to IWXXM 2 are that there is a reported TC CENTRE position (without time information), an OBS 16Z CB position, then a 22Z FCST TC CENTRE position. Note that the information carried in these three positions alternate from TC CENTRE to CB position and back to TC CENTRE.

screen shot 2017-11-09 at 11 05 33 am

There are several changes that may be required:

blchoy commented 6 years ago

I talked to our SIGMET experts during the comment phase of Amendment 78 which further include the ability to describe TC and CB separately in the FCST section. The concept behind the respective changes in Amendments 77 and 78 is to allow the originator to describe the associated CB, in addition to the TC itself, which could have a significant distance from each other. I agree with Aaron that the representation of CB in IWXXM 2.1 is implicit (from the description of TC) and if that is going to become explicit we will need another section solely for CB in both the OBS and FCST. In any case this should definitely be a breaking change.

braeckel commented 6 years ago

I'm not sure we need an entirely new section for CB, it might be as simple as adding new information onto SIGMET. The TAC table did not change significantly and I think the IWXXM structure can be re-used to the same degree as the TAC structure.

It may be possible to address the CB case by adding an optional flag or element on the existing SIGMET conditions which indicate the locations of CB or TC Centres. The challenge would be in adding this without adding any overhead or confusion around the existing SIGMET conditions, which means it might have to be an extension on TropicalCycloneSIGMET (not ideal because it would have to reference multiple analysis and forecastPosition groups) or a new extended version of SIGMETEvolvingConditions. A new Schematron rule would then need to be be introduced to mandate the use of the "TCSIGMETEvolvingConditions" instead of the base type.

The other alternative would be to add a new phenomena element to SIGMETEvolvingCondition and AIRMETEvolvingCondition to allow explicit indications of the phenomena being described by each. In most existing AIR/SIGMET cases this would add an extra element without any new benefit, and unless this was made optional it would not be backwards-compatible with 2.1.0.

sforeman commented 6 years ago

@braeckel @marqh

I have talked with Greg about Amd 77, and the example should be parsed as:

{Admin} YUCC SIGMET 3 VALID 261600/252200 YUDO - YUCC AMSWELL FIR

{TC identifier} TC GLORIA

{OBS} PSN N27606 W07306 AT 1600Z CB WI 205NM OF TC CENTRE TOP FL500

{Expected changes}

NC

{Forecast} FCST AT 2200Z

TC CENTRE PSN N2740 W07345

The CB information is only in the OBS (if present at all).

Is this what iwxxm does?

braeckel commented 6 years ago

As Choy has noted elsewhere, Amd 78 may allow CB reporting on FCST condition in addition to the current OBS conditions.

For the first item regarding a new tropicalCycloneCentrePosition, this element must be mandatory according to the template and would therefore break backwards compatibility. This change cannot be implemented in the 2.1.1 bugfix release for this reason. This is a new information element that should be part of a (future) major or minor IWXXM release where backwards-compatibility may be broken. This issue should almost certainly be moved to a different milestone.

For the second item regarding CB and TC CENTRE locations there are two technical approaches that have been considered. Both approaches have drawbacks but at the moment option 1 seems the most reasonable:

  1. Specialize SIGMETEvolvingConditionCollection to TropicalCycloneSIGMETEvolvingConditionCollection to include a new mandatory phenomenon element that can be used to indicate CB or TC CENTRE and add Schematron rules to ensure TropicalCycloneSIGMETs always have these as result types. This unfortunately creates a new type to carry only one piece of information. Because this is specifically aimed at TC SIGMETs this might be either a standalone enumerated type or could be a WMO Code List. This would later have to be replicated in a future IWXXM version for forecastPositions as well, assuming the FCST CB TAC ends up being part of Amd 78
  2. Add an optional "phenomena" element onto SIGMETEvolvingConditionCollection that can be used for TC SIGMETs. This has the disadvantage of potentially being confusing for non-TC SIGMETs which have no existing use for this element. Given that it is put on all SIGMETs the phenomena reference should probably be to a WMO code list
blchoy commented 6 years ago

The following is the draft Amendment 78 which proposes the introduction of a new section "TC forecast position" within FCST:

image

This seems to complete the loop; now a TC SIGMET can be visualized as a specialized WS SIGMET of CB with mandatory TC positional elements in both the phenomenon and forecast parts.

Personally I support (1) in Aaron's comment above but I am not in favour of mentioning TC CENTRE in the main part of TropicalCycloneSIGMETEvolvingConditionCollection, as we only need a point to describe a TC CENTRE but CB needs the facilities for sophisticated descriptions. And I think this is also the intention of related changes in Amendment 77 and the proposed Amendment 78?

A wild thought (see http://schemas.wmo.int/iwxxm/2.1.0/html/index.htm?goto=3:77): Can we use a SIGMETEvolvingCondition to describe CB and another to describe TC CENTRE? I understand this may introduce ambiguity between the OBS and FCST parts but we have already assumed the TC position and CB description are ordered duplets in each part as in our previous discussion on multiple TCs/VA clouds in a single TC/VA SIGMET message? The benefits of this is that we only need to relax the multiplicity of SIGMETEvolvingCondition from 1..2 to 1..4 and introduce schematron rules to confine the permultations for different SIGMET types. And this is backward compatible too. Of course we could as Aaron suggested add optional elements to describe whether the SIGMETEvolvingCondition block is describing a TC or CB too.

marqh commented 6 years ago

is detail of this required within the documentation for #26

braeckel commented 6 years ago

@sforeman mentioned in the TT-AvXML telecon today that the interpretation should be that the initial TC CENTRE PSN is part of the observed conditions, and that therefore the interpretation of this example should be OBS (TC CENTRE and CB) and FCST (TC CENTRE). There may be additional changes in Amd 78 to clarify this block given the confusion around proper interpretation.

It was also agreed that this fix belongs more directly in a IWXXM 2.2 release rather than IWXXM 3, but the need for IWXXM 2.2 is not yet agreed within the broader TT-AvXML group so this will be moved into 3.0RC1 for now.

blchoy commented 6 years ago

The need to describe two phenomenon (viz TC position and CB) separately within an OBS and FCST section actually violates the existing SIGMET data model. In fact, one can still use a TC SIGMET + WS SIGMET (for thunderstorm) to describe the same situation. I can imagine the latter presentation is less preferable in story telling but if the concept is adopted, it will immediately trigger other possible combinations (may be volcanic ash and thunderstorms for a violently erupting volcano?). I think we need to clear up the concept with relevant ICAO groups (like WG-MIE and WG-MRI) and delaying it to IWXXM 3 is a good choice.

braeckel commented 6 years ago

This is being closed - it is already part of issue #49