[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20031121: gempak metar decoding

Art,

The thing I see here is that there are 2 COR reports. The second COR is
a shortened report. In general, the second report wouldn't write 
over the previous report, however, looking at the code, a COR correction
will over-write the complete bulletin in the decoded storage. This
is generally done since you can't assume that if the correction omits
a part of the previous report, that the previous data was correct.

Each unique bulletin is saved in the text portion, but the decoded values
will only have the last correction. This is a general problem with the
shortened reports.

Steve Chiswell




>From: "Arthur A. Person" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200311211837.hALIbJEH017398

>Hi...
>
>We've seen some cases where precipitation amount is not decoded (or, at 
>least not filed for an observation hour) by the gempak decoder.  This 
>would be using the "7" group.  An example is KATL for 12Z Nov 19, 2003.  
>We're theorizing it has something to do with "short" observations vs. 
>"long" observations (ones with remarks):
>
>FLATMETAR> atl 12z.19
>KATL 191153Z 21004KT 10SM FEW060 15/15 A2969 RMK AO2 SLP048 60106 70154 
>T01500150 10189
> 20150 51016 $=
>KATL 191153Z COR 21004KT 10SM FEW060 15/15 A2969 RMK AO2 SLP048 60106 
>70194 T01500150
> 10189 20150 51016 $=
>KATL 191153Z COR 21004KT 10SM FEW060 15/15 A2969=
>KATL 191153Z 21004KT 10SM FEW060 15/15 A2969=
>
>In the above case, KATL reported "70194" for precip but it did not show up
>in the decoded gempak data.
>
>Any ideas on what might be causing such?
>
>                                   Thanks.
>
>                                     Art.
>-- 
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>