Re: 19990709: synoptic decoder (fwd)

• To: bit-bucket <bit-bucket@xxxxxxxxxxxxxxxx>
• Subject: Re: 19990709: synoptic decoder (fwd)
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Wed, 14 Jul 1999 14:48:04 -0600 (MDT)

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

---------- Forwarded message ----------
Date: Fri, 09 Jul 1999 13:42:33 -0600
From: Jim Cowie <cowie@xxxxxxxxxxxx>
To: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
Subject: Re: 19990709: synoptic decoder

Robb Kambic wrote:

Jim,

I understand where you are coming from with this idea but it puts the
burden on the user to check if the report is in the correct file. Also,
reports after 44 minutes should be put into the next hour. My feeling is
to ignore data that doesn't fall into correct categories because it is
worst to use wrong data verses ommitting the data. There are many Mexican
metar reports that are wrong that caused this thinking.

I agree this time thing is a difficult issue to deal with. For hourly

different animal for a couple reasons. First, they are generally not
hourly they are typically 3 or 6-hourly so the time is much less
granular,
and second, most (many?) come in without any indication of time (hhmm),
so you really have no idea when the ob was taken anyway and you're left
with grouping them to the synoptic time in the bulletin. In our case,
we're decoding only the 6-hourly synoptic reports (SM*) and with that
scale of time granularity, I feel fine using the bulletin time for the
obs. I'd still feel fine doing that if we used the intermediate (3-hr;
SI*) reports because the time granularity is still large. But when you
slip down into the non-standard synoptic's (SN*) then it can get down
to hourly, and you'd want to round to the closest hour. I'm not sure
how you would do all this in one decoder... maybe look at the WMO

...
        # extract Lat, Lon, elev, stnName
        if( defined( $STATIONS{ "$wmoId" } ) ) {
                ( $Lat, $Lon, $elev, $stnName )
                        split( " ", $STATIONS{ "$wmoId" } ) ;
                if( defined( $stnName ) ) {

                        undef( $stnName ) ;
                }
        }
-->  undef( $mm) ;

and for the time thing, I just commented out the setting of the $min
field
where it uses $mm in theTime() for "nominal" and "filedate":


if( $when eq "obs" ) {
        $min = $mm ;
} elsif( $when eq "pos" ) {
        $min = $Pmm ;
        $hour = $Phh ;
        $mday = $Pdd ;
        $mon = $PMM ;
        $year = $Pyy ;
#} elsif( $when eq "nominal" || $when eq "filedate" ) {
#       if( $mm > 14 && $mm < 45 ) {
#               $min = $mm ;
#       } elsif( $mm > 44 ) {
#               $min = 60 ;
#       } # min = 0     
}

PS. there was also a command line argument order problem when you
used both datadir and yymm. I think if you used both it was pulling them
out in the opposite order than what the usage message said. Maybe that
was in the metar decoder...

-jim