metaf2xml Activity
Parse and decode METAR, TAF, SYNOP, BUOY, AMDAR and write data as XML
Brought to you by:
metaf2xml
Activity for metaf2xml
-
Anonymous posted a comment on ticket #36
Hey Thomas Sorry for the delay in getting back to you. I read your response when you posted it and appreciate the quick and thorough answer. Unfortunately I seem to be running into some permission problems on my machine when I implement your instructions. Then after way too much time I put it aside and forgot to respond to you! I am just now going to look at what I have done to my setup. I have a horrible habit of working in root. That is the problem with being self taught. I will let you know when...
-
metaf2xml committed [708611] on Code
released files for 0.20260320
-
improve POD
-
released files for 0.20260315
-
minor changes
-
metar
-
Hi Phil, happy to hear that this project is useful for you. If you mean the script metaf.pl, then no, it can't process files with messages. But if you already have the messages, you can use metafsrc2raw.pl and metaf2xml.pl, and they support this. If you have files from some internet server, e.g. METAR cycle files from NOAA IWS, or METAR/SYNOP/... files from NOAA NWS, you can process them with metafsrc2raw.pl by giving the file name(s) as argument on the command line. The processed messages are written...
-
metar
-
Anonymous created ticket #36
metar
-
released files for 0.20260228
-
minor changes
-
METAR: allow and warn about missing prevailing visibility
-
cgi: adapt to changed NOAA AWC Data API
-
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
1 >
