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
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
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
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...
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...
Sigmet on METAF
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...
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