#10 SYNOP incorrectly marked isCalm

[Anonymous]

XML contains isCalm irrespective of the wind speed if the cloud & wind SYNOP group has a wind direction of 0 degrees.

In this example 0030 is 30KT direction 0 degrees:

echo 'AAXX 26144 03230 27486 20030' | ./metaf2xml-2.9/metaf2xml.pl -o-

But incorrectly returns:

 <sfcWind s="0030">
     <wind>
         <isCalm/>
     </wind>
</sfcWind>

Were as 0130 is also 30KT direction 10 degrees:

echo 'AAXX 26144 03230 27486 20130' | ./metaf2xml-2.9/metaf2xml.pl -o-

And correctly returns:

<sfcWind s="0130">
    <measurePeriod v="10" u="MIN"/>
    <wind>
         <dir v="10" rp="4" rn="5"/>
         <speed v="30" u="KT"/>
    </wind>
</sfcWind>

[metaf2xml]

Hi,

metaf2xml uses the WMO Manuals to decode SYNOP messages.
The group Nddff is described in WMO 306, Vol I.1 2019, FM 12–XIV Ext. SYNOP. The description of ddff in Section 12.2.2.3 does not mention the special meaning of dd being encoded as 00. But Section B says dd is the "True direction, in tens of degrees, from which wind is blowing (or will blow). (Code table 0877; ...) (FM 12, ...".
Code table 0877 decodes 00 as "Calm", while wind from the North (355° - 4°) should be encoded as 36.

Assuming that the quoted SYNOP message is from November this year, Ogimet reports ddff as 0002.

metaf2xml ignores the value for the wind speed(s) if the wind is specified as "Calm" because they were designed to be mutually exclusive. The wind speed for "Calm" (Beaufort scale 0) is defined as less than 1 kt. A wind speed of 2 kt would actually be Beaufort force 1 (Light air, 1 - 3 kt).

However, you could still access the value via the attribute s of the (grand-) parent node <sfcWind>.

Kind regards
Thomas

[Anonymous]

I take your point with regard to table 0877 stating that a wind direction of 00 is Calm. Although it seems counterintuitive that a direction value should be used in this way. I suspect the intention was that any wind speeds of 0 should be given an direction of 00

It certainly doesn't appear that the SYNOPs are encoded with a strict adherence to 0877 as many reports on Ogimet have significant wind speeds from a direction of 00 degrees.

For example, the current SYNOP for Charterhall (03158) indicates a windspeed 12KT with a wind direction of 00 which decodes as Calm. However, the Metoffice report this stations as a 12KT Northerly (see attached image)

AAXX 02114 03158 27449 80012 10054 20035 39992 40130 51038 761// 88/// 333 55300 20125 60005 88/14 91022 90710 91122

Ogimet

I understand that I could use the s atribute of <sfcwind></sfcwind> but I suspect this will be causing many users of Ogimet SYNOP data to incorrectly report Calm conditions.

Given this, it might be worthwhile to consider adjusting the decoding logic to account for non-zero wind speeds when interpreting a direction code of "00." This could help distinguish between actual calm conditions and instances where the wind direction is due north with a significant wind speed.

I appreciate your consideration of this matter and look forward to any insights you might have.

[metaf2xml]

Hi,

to me, it looks like the error is in the encoding: 00 is used instead of 36 for winds from the North.

Here are the values I could find for 03158 for 2024-12-03 11:00:

• the BUFR (provided by Ogimet): ISNN02 EGRR Subset 18 : Wind direction: 0, Wind speed: 1,4 m/s

• translated to TAC by KWBC (provided by NWS): SNUK04 KWBC: 3603

  ####018003666####
  SNUK04 KWBC 031100
  AAXX 03114
  ...
  03158 25680 83603 10009 21002 30081 40223 50000 88/// 333 55300
  20183 60005 88/40 91004 90710 91107=

• translated to TAC by bufr2synop: Ogimet: 0003

  AAXX 03114
  03158 25680 80003 10009 21002 30081 40223 50000 88/// 333 55300
  20183 60005 88/40 91004 90710 91107==

Various Ogimet news say that reports translated with bufr2synop have == at the end of reports instead of a single =, so the Ogimet TAC was translated from BUFR. Maybe bufr2synop should translate the BUFR wind direction 0 to 36.

I think the translated TAC messages shouldn't be used anymore, anyway. Not all information in the BUFR can be translated to TAC, and the translation can contain bugs.

Kind regards
Thomas

[metaf2xml]

BTW I strongly assume that the wind direction in BUFR also was wrongly encoded by the publisher EGRR. The manual says that direction=0 should be used for "Calm" (speed=0) or "Light and variable" conditions (speed>0), otherwise the direction from exactly North should be encoded as 360. But e.g. in ISNN02_EGRR_021100 Section 18, the direction is 0 with a speed of 6.1 m/s, which is a "Moderate breeze" in the Beaufort scale.

[metaf2xml]

I found correct examples for TAC and BUFR with direction=0 and speed>0 from the time when both were still published in parallel, e.g. in the demo data for 08583 at 2019-08-10 06:00 published by GVAC:
TAC (SMCV01): ddff: 9901
BUFR (ISME01): direction, speed: 011001:0 011002:0.5

In the next release of metaf2xml, the direction will be <dirVariable/> for TAC and BUFR with direction=0 and speed>0; this is according to the manual for BUFR, and an extension for TAC.

[metaf2xml]

Version 2.10 was released.