I have been usin this amazing tool to decode SYNOP and metar messages downloaded from ftp://ftp.ncdc.noaa.gov/pub/data/noaa/
It works fine, but I have found stations where messages in BUFr format, for example for station 171160 I get a file with messages like
the file readme.txt in the directory you provided says:
This directory contains ISH/ISD data in directories by year. Please note that ISH and ISD refer to
the same data--Integrated Surface Data, sometimes called Integrated Surface Hourly.
and:
- The data format documentation, required to read and interpret the data:
ish-format-document.pdf
This document describes the data format. It is neither SYNOP nor BUFR. Therefore it cannot be decoded with metaf2xml, sorry.
The readme also points to other files in the directory:
- A java program to convert the ISD data into a space-delimited / abbreviated format:
ishJava.
- Documentation for usage of ishJava:
ishJava_ReadMe.pdf
Kind regards,
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know the files are not "pure" SYNOP/METAR/BURF messages. But with little work I was able to translate them (when SYNOP or METAR), for example:
An original file line is:
"0116161100999992015010100004+45650+013750FM-12+000499999V0200401N012919999999N020000199-00041-01851103171ADDAA106000091MA1999999103121MD1110031+9999REMSYN06416110 12998 00425 11004 21185 30312 40317 51003 60001 555 0////="
just working with regular expressions I converted it in:
The initial part of a message until "REM" is in ISH format, there is no BUFR.
The message type of the original data used to create the ISH data is indicated by positions 42-46 in the Control Data Section of the ISH; "FM-12" = SYNOP, "FM-13" = SHIP, "FM-14" = SYNOP MOBIL, "FM-15" = METAR, "FM-16" = SPECI, "FM-18" = BUOY look promising if you want to use metaf2xml.
The part after "REM" seems to contain the original message: if it was a TAC SYNOP, the remark is "SYN" + 3-digit length + the original SYNOP(*) (as you already found out), if it comes from a BUFR SYNOP it is just "SYN004BUFR"; it looks like they didn't bother to convert the binary BUFR to some ASCII representation. So there's no BUFR, either.
Just have a look at the readme and the PDF provided by them, maybe you find more info there.
(*) "AAXX" and the group "YYGGiw" are missing for FM-12, so the observation day and hour and the unit for wind speeds given in the TAC SYNOP are not known, but most likely they can be derived from the ISH data. Maybe there are similar issues with other message types.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I have been usin this amazing tool to decode SYNOP and metar messages downloaded from ftp://ftp.ncdc.noaa.gov/pub/data/noaa/
It works fine, but I have found stations where messages in BUFr format, for example for station 171160 I get a file with messages like
0147171160999992015010408004+40180+029060FM-12+010099999V0200701N0021199999999005000199+00291+00171101721ADDAY101021AY201021GA1041+012501081GA2999+999999031GE19MSL +99999+99999GF106991041999012501999999MA1999999100471MD1710161+9999MW1101REMSYN004BUFR
Becouse of last charcaters I know there is a BUFr message somewhere, but I don´t know where and I can't use metaf2xml with -T flag.
Maybe you can help me.
Thank you in advance.
Hi,
the file readme.txt in the directory you provided says:
and:
This document describes the data format. It is neither SYNOP nor BUFR. Therefore it cannot be decoded with metaf2xml, sorry.
The readme also points to other files in the directory:
Kind regards,
Thomas
View and moderate all "Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I know the files are not "pure" SYNOP/METAR/BURF messages. But with little work I was able to translate them (when SYNOP or METAR), for example:
An original file line is:
"0116161100999992015010100004+45650+013750FM-12+000499999V0200401N012919999999N020000199-00041-01851103171ADDAA106000091MA1999999103121MD1110031+9999REMSYN06416110 12998 00425 11004 21185 30312 40317 51003 60001 555 0////="
just working with regular expressions I converted it in:
AAXX 01004 16110 12998 00425 11004 21185 30312 40317 51003 60001 555 0////
what I can translate with metaf2xml.pl
I just wondered if you recognise a BUFR message in the orginal line
"0147171160999992015010408004+40180+029060FM-12+010099999V0200701N0021199999999005000199+00291+00171101721ADDAY101021AY201021GA1041+012501081GA2999+999999031GE19MSL +99999+99999GF106991041999012501999999MA1999999100471MD1710161+9999MW1101REMSYN004BUFR"
I'm gonna give that java program a try, anyway.
Thanks
The initial part of a message until "REM" is in ISH format, there is no BUFR.
The message type of the original data used to create the ISH data is indicated by positions 42-46 in the Control Data Section of the ISH; "FM-12" = SYNOP, "FM-13" = SHIP, "FM-14" = SYNOP MOBIL, "FM-15" = METAR, "FM-16" = SPECI, "FM-18" = BUOY look promising if you want to use metaf2xml.
The part after "REM" seems to contain the original message: if it was a TAC SYNOP, the remark is "SYN" + 3-digit length + the original SYNOP(*) (as you already found out), if it comes from a BUFR SYNOP it is just "SYN004BUFR"; it looks like they didn't bother to convert the binary BUFR to some ASCII representation. So there's no BUFR, either.
Just have a look at the readme and the PDF provided by them, maybe you find more info there.
(*) "AAXX" and the group "YYGGiw" are missing for FM-12, so the observation day and hour and the unit for wind speeds given in the TAC SYNOP are not known, but most likely they can be derived from the ISH data. Maybe there are similar issues with other message types.
View and moderate all "Help" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I worked it out using the java script provided by NOAA.
Thank you and congrats for the awesome job done with metaf2xml
Sounds good!
Thanks a lot!