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

Re: 19990709: synoptic decoder (fwd)


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

---------- Forwarded message ----------
Date: Fri, 09 Jul 1999 13:42:33 -0600
From: Jim Cowie <address@hidden>
To: Robb Kambic <address@hidden>
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
reports I would completely agree that if you have the time (hhmm) 
then you should group obs to the appropriate hour. But synoptics are a
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
header... I don't know. Anyway... the code change was small, I put the 
undef ($mm) here:

...
        # extract Lat, Lon, elev, stnName
        if( defined( $STATIONS{ "$wmoId" } ) ) {
                ( $Lat, $Lon, $elev, $stnName ) =
                        split( " ", $STATIONS{ "$wmoId" } ) ;
                if( defined( $stnName ) ) {
                        $stnName = padstr( $stnName, $stnName_len ) ; 
                } else {
                        undef( $stnName ) ;
                }
        }
-->     undef( $mm) ;
        # decode Section 1 
...


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     
}

so that it always uses 00 for minutes and does not adjust the hour. 

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