update TAC to XML guidance for RC4

[marqh]

https://github.com/wmo-im/iwxxm/blob/master/IWXXM/TAC-to-XML-Guidance.txt

for example:

• missing RVR

• 169

[blchoy]

The following are issues brought up after the publishing of 3.0.0RC3:

1. Maximum and minimum temperature forecasts in TAF, if present, should be provided in pairs (#165)
2. There are cases where iwxxm:TropicalCycloneAdvisory cannot adequately describe the situation (#166)
3. The number of RVR reports which can be included in METAR is limited, and ditto other elements in METAR/SPECI, TAF, VA and TC SIGMET (#168).
4. Guidance on STNR in AIRMET and SIGMET is inconsistent with TAC template (#169)

(1), (2) and (3) involve a change of the corresponding TAC template or selected de-synchronization of IWXXM with the TAC template. Having said that, we may still want to give some guidance for (1) to get around of the issues temporarily.

The following are proposed addition to TAC-to-XML-Guidance.txt:

==========================
TAF
==========================
...
Maximum and minimum temperature forecasts - TXnn/nnnnZ TNnn/nnnnZ
  As indicated in Annex 3 these shall be given in pairs.  If more than one pair of 
temperatures are provided and only one maximum or minimum is anticipated one may 
consider repeating this in both groups.

Comments and also suggestions to (2) are most welcomed

[mgoberfield]

Choy,

While I agree that these are issues that need resolution, I was more focused on resolving the ambiguity of certain situations, namely, missing RVR in METARs/SPECIs when Annex 3 demands RVR be reported, and how stationary phenomenon is depicted in AIRMET/SIGMET products.

For (2), may I suggest the following: if any mandatory item(s) in the iwxxm:TropicalCycloneForecastCondition element is (are) not provided, then the parent element 'iwxxm:forecast' nilReason shall be set to 'http://codes.wmo.int/common/nil/nothingOfOperationalSignificance'.

[blchoy]

For (2), may I suggest the following: if any mandatory item(s) in the iwxxm:TropicalCycloneForecastCondition element is (are) not provided, then the parent element 'iwxxm:forecast' nilReason shall be set to 'http://codes.wmo.int/common/nil/nothingOfOperationalSignificance'.

I am not too sure whether you can have something in TAC but nil in IWXXM. How often does this happen?

[mgoberfield]

That is what the MIE paper is about, yes? Tokyo and Miami sometimes issue TCAs which cannot be implemented in IWXXM because Annex 3 does not address the weakening or dissipation of TCs. I don't know how often this occurs (but obviously every TC dissipates). IIRC, there is a proposal for increased forecast length of TCAs, so this issue (TC dissipation) will occur more frequently in the product. Regardless of the TAC form, I think MIE needs to look at this and provide a solution.

[blchoy]

I am thinking this the other way round. The regulations are there for us to comply with, and if we believe they are inappropriate we should change them instead of doing what we want. Based on the two examples you provided in #166, I have the following suggestions:

1. For a weakening TC with forecast strength below warning level - It will be safer to give both the location and expected strength. It is a forecast and the TCACs should be able to give the intensity a value (in fact they are mentioning TROPICAL DEPRESSION in the example which means they had the intensity in mind).
2. For a TC forecast to dissipate at a forecast time and beyond - Then the intensity of the system will be way below the warning strength and would be safe not to mention the forecast location and intensity completely. For TAC the forecast time involved and those beyond are still provided with the location and strength stuffed with solidi. In IWXXM, I agree with you that if a tropical cyclone is forecast to dissipate at the first forecast instance iwxxm:forecast element shall be nil with nilReason set to 'http://codes.wmo.int/common/nil/nothingOfOperationalSignificance'. If the tropical cyclone is expected to dissipate after the first forecast instance, the rest of the iwxxm:forecast elements should be omitted..

If this is something sensible then our action will be (i) to include in the guidance making iwxxm:forecast nil for dissipated TC forecasts, (ii) at MIE/6 urge TCACs to observe and conform to the TAC templates (which should automatically comply with IWXXM) in preparing TCAs, and (iii) seek their views with regard to the updating of the TAC templates as necessary.

[mgoberfield]

I concur with your points.

[blchoy]

The above was implemented in 3.0.0RC4.