ET-DATA : update the naming convention for unifying the extension

[antoinemerle]

Introduction

The idea of this proposal is to have a consolidate rules for the extension and WMO convention

At the moment in EUM we follow the recommendation made by WMO

on the "Manual on the Global Telecommunication System Annex III to the WMO Technical Regulations "
2015 edition - Updated in 2020 - WMO-No. 386
Table 5. Accepted type values in
ATTACHMENT II-15
pp140

Amendment details

The idea is to update the WIGOS documentation in order that WMO push for a mangement of the file naming convention.

NOAA has its own naming convention (as well as eumetsat) and by default when converting into BUFR or GRIB we were following the WMO naming convention

e.g : W_XX-EUMETSAT-Darmstadt,SURFACE+SATELLITE,S1A+OCN_C_EUMS_20260504044311_WV2_VV.bin

I think it would be interesting to update this and also precise if we should switch to new extension

• .bufr or .bin or .BUFR or .buf
• .grib or .grib2 or .GRIB2 or .bin

I was trying to look what we have and it seems all institutions does not follow that rule.
I would be happy if WMO come up with an official manual for the naming convention for WIS2.0

Requestor(s)

EUMETSAT

Stakeholder(s)

anyone in the worl

Expected impact of change

None

Consultations

No response

Data exchange plans

No response

Comments

No response

[jbathegit]

I'm curious whether ET-Data is the right group to consider this proposal. I do remember some past WMO cycles where predecessors of the ET-Data team were given oversight responsibility for GTS regulations and the 386 manual, but I'm not sure if that's still the case in the new WIS2.0 era under WIGOS?

If so, and if such guidance doesn't already exist under WIS2.0, then I think this is worth considering. In any case, for GRIB I would strongly suggest just using .grib as the filename extension rather than .grib2 or .GRIB2. The 2 is simply the edition number, and I don't think that needs to be in the filename extension since any GRIB decoder worth the name will easily be able to determine that in the first few bytes of the actual message. And it's not like edition numbers have been used in any of the other previous extensions either (e.g. we just have .htm rather than .htm3, htm4, htm5, etc.)

Or, if the consensus of the group is to now include an edition number in the filename extension, then for consistency .bufr should be correspondingly changed to .bufr4 or .BUFR4, given that 4 is the current edition of BUFR.