Re: METAR Decoder Question

• To: Alan Steremberg <alans@xxxxxxxxxxxxxxxxxxxxxxxxxx>
• Subject: Re: METAR Decoder Question
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Thu, 12 Mar 1998 10:37:14 -0700 (MST)

On Wed, 11 Mar 1998, Alan Steremberg wrote:

Hi,

We have been using the decoders package since June and it has been working really well for us, much better than the way we were doing it before.

I have seen bogus METARS come over the wire that the metar converter just discards (without any messages) that seem to make their way onto the weather.nws.noaa.gov site.

One example is:

^M^M
^C^A^M^M
226 ^M^M
SAUK31 KWBC 111820 RRA^M^M
METAR^M^M
EGAA 33008KT 9999 FEW015CB SCT100 05/02 Q1025 NOSIG=^M^M
EGBB 32006KT 9999 SCT035 SCT050 04/02 Q1021=^M^M
EGCC 31006KT 260V350 9999 FEW025 06/02 Q1021 NOSIG=^M^M
EGGW 34007KT CAVOK 05/01 Q1019=^M^M
EGHH 34007KT 290V030 9999 FEW045 SCT280 06/M02 Q1022=^M^M
EGKK 35008KT 9999 FEW045 SCT200 07/M03 Q1020 NOSIG=^M^M
EGLL 33007KT 300V360 9999 FEW045 07/M01 Q1020 NOSIG=^M^M

For some reason they are missing the date and time.

The metar spec I have been using says:
---
http://www.nws.noaa.gov/oso/oso1/oso12/fmh1/fmh1ch12.htm
12.5 Coding Missing Data in METAR/SPECI

When an element does not occur, or cannot be observed, the corresponding

group and preceding space are omitted from that particular report.

---

So I guess this is valid? We could check to see if the first element ends in a Z and decide whether or not it is a date. Of course, what date do you give it?

Alan,

Exactly, what date to give it. The previous bulletin might have a
different day/hour and the bulletin time could be different also.  I
checked the WMO no. 306 manual on codes.  15.3.1 states the format of the
time and 15.3.2 states that this field will always be included.  I would
inform the NWS about this, they are expected to screen for bad reports.

Thanks for the other information, I will modify the metar2nc code
accordingly. If you get more info on the temp bug, please send it along.

Thanks,
Robb...

        # get date hour minute
        next unless( s#^(\d{4,6})Z\s+## );

----

The other problem I fixed already (not correctly?) is that some stations in Europe don't seem to report Runway visual range in FT, they choose another unit!

(7) Runway Visual Range - RDRDR/VRVRVRVRFT or
         RDRDR/VNVNVNVNVVXVXVXVXFT

97061221_sao.wmo:RJFK 2100Z 02005KT 0100 R34/0100N FG VV003 15/15 Q1015 RMK A2998 FCST

97061221_sao.wmo:RJSK 2100Z 12002KT 0200 R28/0300N FG VV001 13/13 Q1015 RMK
97061212_sao.wmo:EGJA 1150Z 23008KT 0150 R26/0350 FG DZ OVC000 14/// Q1008

97061212_sao.wmo:RJSM 121207Z 14004KT 0900 R10/1400D -DZ FG SCT000 OVC001 11/11 Q1013 97061212_sao.wmo:RJSM 1200Z 13005KT 1200 R10/P1800N -DZ BR SCT000 BKN001 OVC002 11/11 # AJS -- allow for misformed files without the FT # this fixes a temperature bug, we hope..

            if( s#R(\d{2})(R|L|C)?/\d*\s*## ){
#print "got it!\n";
            }
            else
            {
                last;
            }
        }

I think there might be one more bug that is causing the temperature to read incorrectly sometimes. Haven't tried to track it down yet.

Thanks,
Alan

==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================

• Follow-Ups:
  • Re: METAR Decoder Question
    • From: Alan Steremberg