Recent changes to bugs

#10 SYNOP incorrectly marked isCalm

metaf2xml — Mon, 10 Feb 2025 18:52:59 -0000

discussion: enabled --> disabled

#9 Parrser

metaf2xml — Wed, 01 Jan 2025 12:58:38 -0000

discussion: enabled --> disabled

#10 SYNOP incorrectly marked isCalm

metaf2xml — Wed, 01 Jan 2025 12:58:06 -0000

status: accepted --> closed-fixed

#10 SYNOP incorrectly marked isCalm

metaf2xml — Wed, 01 Jan 2025 12:57:49 -0000

Version 2.10 was released.

#10 SYNOP incorrectly marked isCalm

metaf2xml — Sun, 29 Dec 2024 13:06:13 -0000

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.

#10 SYNOP incorrectly marked isCalm

metaf2xml — Sun, 15 Dec 2024 19:58:25 -0000

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.

#10 SYNOP incorrectly marked isCalm

metaf2xml — Wed, 04 Dec 2024 11:05:39 -0000

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

#10 SYNOP incorrectly marked isCalm

metaf2xml — Wed, 04 Dec 2024 09:26:02 -0000

status: pending --> accepted

#10 SYNOP incorrectly marked isCalm

metaf2xml — Thu, 28 Nov 2024 11:00:30 -0000

status: accepted --> pending

#10 SYNOP incorrectly marked isCalm

metaf2xml — Thu, 28 Nov 2024 10:58:11 -0000

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