METAR Decoder Question

[Robb Kambic]

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 at unidata.ucar.edu		   WWW: http://www.unidata.ucar.edu/
==============================================================================