metaf2xml Activity
Parse and decode METAR, TAF, SYNOP, BUOY, AMDAR and write data as XML
Brought to you by:
metaf2xml
Activity for metaf2xml
-
metaf2xml committed [2994c2] on Code
released files for 0.20250308
-
minor changes
-
released files for 0.20250223
-
minor changes
-
released files for 0.20250222
-
minor changes
-
ui-html, ui-html-sum: rename from fullhtml and sum-ui
-
xsl, sum, ui, cgi, install.pl, README: improvements for format=text
-
released files for 0.20250218
-
ui-html, ui-html-sum: rename from fullhtml and sum-ui
-
xsl, sum, ui, cgi, install.pl, README: improvements for format=text
-
released files for 0.20250215
-
ui-html, ui-html-sum: rename from fullhtml and sum-ui
-
xsl, sum, ui, cgi, install.pl, README: improvements for format=text
-
released files for 0.20250213
-
ui-html, ui-html-sum: rename from fullhtml and sum-ui
-
xsl, sum, ui, cgi, install.pl, README: improvements for format=text
-
parser, xsl, dtd: METAR remarks: obscuration can have multiple cloud layers
-
minor changes
-
SYNOP incorrectly marked isCalm
-
released files for 0.20250124
-
parser, xsl, dtd: METAR remarks: obscuration can have multiple cloud layers
-
minor changes
-
released files for 0.20250104
-
minor changes
-
Parrser
-
SYNOP incorrectly marked isCalm
-
Version 2.10 was released.
-
version 2.10 released
-
release 2.10
-
minor changes
-
METAR remarks: remark can have multiple phenomena
-
minor changes
-
parser: METAR: process 'M' (= missing in SAO format)
-
parser, xsl, dtd, lang: process dispatch visual range
-
parser: simplify handling of msgModified and ERROR
-
improve processing in src2raw.pm, metafsrc2raw.pl
-
metaf2xml released /2.10/metaf2xml-2.10.tgz
-
-
-
-
-
-
-
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.
-
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.
-
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...
-
SYNOP incorrectly marked isCalm
-
Anonymous posted a comment on ticket #10
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...
-
SYNOP incorrectly marked isCalm
-
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...
-
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...
-
SYNOP incorrectly marked isCalm
-
Anonymous created ticket #10
SYNOP incorrectly marked isCalm
-
released files for 0.20240224
-
METAR remarks: remark can have multiple phenomenona
-
minor changes
-
parser: METAR: process 'M' (= missing in SAO format)
-
parser, xsl, dtd, lang: process dispatch visual range
-
parser: simplify handling of msgModified and ERROR
-
improve processing in src2raw.pm, metafsrc2raw.pl
-
released files for 0.20231112
-
minor changes
-
version 2.9 released
-
-
-
-
-
-
-
-
adapt to new NOAA AWC Data API
-
release 2.9
-
minor changes
-
Bouy
-
Hi, thanks for reporting this, but this change will not affect metaf2xml. SCN23-85 in the NWS Service Change Notices refers to the "format of the latest observation file and hourly files" of the NDBC, only. This data cannot be used as input for metaf2xml. metaf2xml can process: the 5-digit buoy identifier A1bwnbnbnb in BUOY TAC data (WMO 306, Vol I.1 2019, FM 18-XII), and the 5-digit buoy/platform identifier for 0 01 005 and the 7-digit WMO marine observing platform extended identifier for 0 01 087...
-
Anonymous created ticket #35
Bouy
-
released files for 0.20230702
-
minor changes
-
minor changes
-
Sigmet on METAF
-
RMK FIELD IN METAR
-
RMK metar filed not correctly parsed
-
Graphics demo soure missing
-
Sigmet on METAF
-
Hi Paul, thanks for this suggestion. I had a look at these formats. It seems they consist mostly of abbreviated plain text, so there is not much to be decoded. Also, they include references to coordinates, as route or area, so a graphical representation would be more appropriate than a textual one. And finally, there is a transition going on to retire / replace TAC (Traditional Alphanumeric Code) AIRMET by BUFR, like for SYNOP, see https://www.weather.gov/notification/ and search for "AIRMET". To...
-
Anonymous created ticket #34
Sigmet on METAF
-
Anonymous posted a comment on ticket #33
Tks Thomas it is clear. I would like to know if could possible to add at metar2xml a parser for SIGMET and AIRMET warnings? They are very useful https://www.aviationweather.gov/help/webservice?page=isigmetjson Tks Paul
-
RMK FIELD IN METAR
-
Hi Paul, thanks for reporting. This report has several issues. The format for the wind is incorrect, "RMK" is missing before the remarks (these 2 are handled by the parser), and the shower in the vicinity is not reported in the main part of the METAR, and it is not reported with the standard abbreviation VCSH. I'd say this last issue is one step too far away from the WMO standard, and very likely unique, so I won't implement another regex for this single occurrence. There are simply too many possibilities...
-
Anonymous created ticket #33
RMK FIELD IN METAR
-
RMK metar filed not correctly parsed
-
Version 2.8 was released.
-
Parrser
-
Version 2.8 was released.
-
version 2.8 released
-
release 2.8
-
xsl, lang: improve display of value ranges
-
minor changes
-
use separate remark for associated/embedded cloud types
1 >
