Review use cases involved in the exchange of TAC to identify required features from WMO AHL, etc. to be implemented in IWXXM Report class

[blchoy]

It may not be obvious from the UML diagrams that all IWXXM reports are an extension of the Report class: http://schemas.wmo.int/iwxxm/2.1.0/html/index.htm

It is known that metadata is required to support operations including message exchange, prioritization and cancellation/renewal (see #15, #46 and #47); such information is extracted from the WMO AHL of the associated bulletins (e.g. SIGMET) and type of report (e.g. SPECI and SIGMET) etc. It may be worthwhile to take a look at relevant use cases and include relevant metadata in the Report class so as to have IWXXM messages segregate better from COLLECT for future transport mechanisms like WFS.

Having said that, whether the Report class is also suitable for transporting retrieval of parts of the information contained in an IWXXM message (e.g. QNH in METAR) in contrast to the full observation in future SWIM environment will have to be considered separately.

[blchoy]

Section 2.2 of AIXM Feature Identification Reference 1.0 (http://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_feature_identification_and_reference-1.0.pdf) indicated that "authoritative source" is actually the "primary originator" who generate the feature (and hence the associated gml:id as mentioned in the paragraph). Compare with Section 2.3.2 of WMO No. 386, it is equivalent to CCCC in the WMO Abbreviated Header Line (AHL) of the associated bulletin.

[blchoy]

Neil Halsey also mentioned that "The only thing that I would add in the context of an authoritative source is the notion of “authoritative” in the sense of the official source from the State. There may be several forecasts for a particular aerodrome that are accessible via SWIM in the future if a State allows such a thing (the US does) but only one of those would be the one provided on behalf of that State. This would be the State designated authoritative source, any other would be clearly identified as such."

[sforeman]

I think Neil was looking ahead to when SWIM is implemented more fully and has moved beyond what is currently exchanged using AMHS, and is referring to the issue that is common nowadays in public weather forecasts. It would be wise to include a reference in the report to whether it has been issued by the State, or whether it is a forecast issued without that authority. There is already an "International register of alerting authorities" (http://alerting.weather.org) through which any State can announce which its authorized bodies are. Using the OID from that register would provide a means of validating a claim that the issuing body had the required authority.

[blchoy]

It is easy to add attributes, but we need to examine the use case(s) carefully to make sure that they meet the need of the users at the end of the day. If one recall, we had quite a discussion on the introduction of the (operational) status and translation indicators among the members of WG-MIE.

The reason for asking is that ICAO shut the door for provisional TAFs some time ago, saying that there should only be one official TAF for each aerodrome and with the advent of modern communication network there will be no need for provisional TAFs. It seems to me that the attribute helps national centres to discriminate which TAF is official within the State but in the international environment where only the official TAFs could exist, all of the TAFs shall carry the authoritative badge and the value of the attribute will diminish.

The above just came out from my head. I am happy to explore the real use case involved in Neil's request which could be what Steve had mentioned the forward looking scenario in the previous post.

[braeckel]

This is a broader issue that is related to issue #47

[moryakovdv]

Dear all. Happy New Year!

If I understand Choy's comments correctly we should agree that there is the only one authoritative source for TAF. My collegues from Russia confirm it. But, does it mean that other features and products (TAAC, VAAC etc.) behave as well? If so, IMO, there is no reason to label every measurement or observation included in IWXXM message. In any case (further, in SWIM environment) we will be able to tag each piece of data with label of the parent message it came from. I think it was Neil's main idea.

[moryakovdv]

Comrades, I sent a link to shared SN to yours emails. Could you please find a minute to review it? Thanks in advance.

[braeckel]

This issue is being closed - authoritative source discussions are proceeding in MIE and have so far strongly suggested that metadata on authoritative sources should not be part of the IWXXM messages. On the broader report topic it appears that the existing issues cover all of the problems that we are currently aware of