wmo-im
Create homepage of abbreviated headings for ICAO
Details
At the 78th session of the WMO Executive Council (EC-78) a resolution (Resolution 16) had been made that "the Manual on the Global Telecommunication System (WMO-No.386) will no longer be updated from 31 December 2024. "
To ensure the exchange of aviation data over ICAO AFS is not affected by the freezing and subsequent deprecation of WMO-No.386 and WMO-No.9 Vol. C1, a decision has been made by WMO to continue maintain those AHs being used for exchange of aviation data online (this web page).
Requestor
Anna Milan (WMO), @amilan17
And draft 2 which has included comments from Greg and presented at the ICAO WG-MIE meeting on 13 May 2025:
Will the AHL page also formally endorse use of the "_freeformat" field, which our translator uses to create unique timestamped abbreviated headings from TAC SIGMETs with duplicate headings? Without it, we would have many clashing filenames. For example, the 3 TAC SIGMETs below would all be translated into files with the same abbreviated heading, if we did not add a unique _freeformat extension, as defined in the deprecated WMO 386:
168 ^M^M
WSBZ01 SBBR 010000^M^M
SBAZ SIGMET 35 VALID 282030/010030 SBAZ - SBAZ AMAZONICA FIR EMBD TS FCST WI S0701 W07350 - S0840 W07159 - S0932 W07300 - S1000 W07
210 - S1001 W07116 - S0928 W07035 - S1104 W07038 - S1107 W06840 - S0955 W06631 - S0954 W06617 - S0735 W06537 - S0619 W06852 - S0628
W07121 - S0547 W07304 - S0701 W07350 TOP FL430 STNR NC=^M^M
^M^M
^C^A^M^M
169 ^M^M
WSBZ01 SBBR 010000^M^M
SBCW SIGMET 1 VALID 010010/010030 SBCW - SBCW CURITIBA FIR EMBD TS FCST WI S2837 W05133 - S2750 W05041 - S2620 W05205 - S2558 W0533
4 - S2655 W05346 - S2721 W05240 - S2837 W05133 TOP FL410 STNR NC=^M^M
^M^M
^C^A^M^M
170 ^M^M
WSBZ01 SBBR 010000^M^M
SBAO SIGMET 15 VALID 282030/010030 SBAO - SBAO ATLANTICO FIR SEV TURB FCST WI S3253 W03954 - S3337 W02913 - S3522 W02202 - S3450 W0
1547 - S3444 W01506 - S3217 W02016 - S3011 W02924 - S2902 W03801 - S3253 W03954 FL290/320 STNR NC=^M^M
Hi @ArnaudDumont:
We are suggesting the following file name convention:
A_T1T2A1A2iiCCCCYYGGgg_C_CCCC_yyyyMMddhhmmss.xml[.compression]
which has the date and time of creation of the file by the originator (yyyyMMddhhmmss). Don't you think it is already adequate (creation time down to one second) for making "unique timestamp" for each message?
Apologies for the late reply; I've been on holiday.
Our TAC->IWXXM converter processes messages quickly, so if the messages are in the same input batch, we will often have duplicates produced in the same second. Sometimes, they are even produced in the same millisecond. For example:
-rw-r--r-- 1 dumont rap 6086 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_112796.xml -rw-r--r-- 1 dumont rap 6194 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_113593.xml -rw-r--r-- 1 dumont rap 6086 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_114373.xml -rw-r--r-- 1 dumont rap 6081 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_115140.xml -rw-r--r-- 1 dumont rap 6860 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_115951.xml -rw-r--r-- 1 dumont rap 6084 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_116835.xml -rw-r--r-- 1 dumont rap 6489 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_148871.xml -rw-r--r-- 1 dumont rap 6237 Dec 25 2024 A_LSBZ23SBGL042325_C_SBAZ_20241226034319_149637.xml
In these cases, we would require microseconds of the conversion time in the filenames to disambiguate the duplicates (as shown). I would therefore suggest the following file name convention, which uses the optional "_freeformat" WMO Header extension for the microseconds:
A_T1T2A1A2iiCCCCYYGGgg_C_CCCC_yyyyMMddhhmmss[_ffffff].xml[.compression]
Whether to make this optional or required is to be determined. I don't like to complicate the filenames, but consistency may be more important.
The original file name convention as indicated on P.138 of WMO No.386 is indeed:
where:
It is natural to also include this freeformat part into our guidance. However, as mentioned in the description, the originating countries should strive to make their freeformat descriptions available to others which, from my perspective, is hard to reach the end users. It would be more useful to define it straight in the guidance.
In your examples, the freeformat part is used to ensure uniqueness of the file, and 6 alphanumeric characters of whatever values should do the job (and in your use case you chose them to be micro seconds of creation time). Do you think that "a freeformat part with 6 alphanumeric characters of whatever values a suitable guidance?
I agree that it is better to describe the freeformat section in the guidance, rather than to let each state determine their own. "A freeformat part with 6 alphanumeric characters of whatever values" would be perfectly suitable. This would retain the ability to use a different differentiator than milliseconds and/or preserve the ability to use this field for other informational purposes.
I would hope that the need to use the "_freeformat" field to disambiguate files would go away once states produce correct (unique) sequence numbers in their "T₁T₂A₁A₂ii CCCC YYGGgg" abbreviated headers. If so, would the guidance allow the "_freeformat" field to be omitted, or would it always be required? It seems preferable not to require it, if that doesn't complicate the guidance and processing.
My personal view is to have "_ffffff" optional, as it is quite often that "hhmmss" alone is good enough to ensure uniqueness.
If you have no further suggestions I will be putting this into the guidance document right the way.
There you go: https://github.com/wmo-im/iwxxm/blob/AHL-page/documentation/webpages/AHL.asciidoc
@blchoy and I reviewed the page and determined that we can post it to the wmo community website as soon as possible.
feature branch has been merged into master branch https://github.com/wmo-im/iwxxm/pull/360
to be posted at https://community.wmo.int/en/activity-areas/wis/iwxxm/ahl-icao-data
@blchoy please review the new webpage and close this issue if all is ok. Then we should send an announcement on the email list.