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

Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong (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: 25 Sep 2003 10:09:29 -0500
From: David Larson <address@hidden>
To: Robb Kambic <address@hidden>
Subject: Re: 20030912: perl metar decoder -- parsing visibility / altimeter
    wrong

My mistake, terribly sorry, thanks for taking the time to check this
out.

I went back to the original/prestine 2.4.4 release code and the results
came out correctly for me as well.  I'll do a diff and see what I
botched to cause this ...

Dave

On Wed, 2003-09-24 at 15:34, Robb Kambic wrote:

> David,
>
> I used your example and the results came out correctly, not seeing the
> error you mentioned. I also checked the NetCDF file for the values, they
> were correct also. I'm wondering if it could be the version of perl, my
> version: This is perl, v5.6.0 built for sun4-solaris  The test was also
> done on a Solaris machine. Maybe if you give more detailed
> environment/usage I could reproduce the error.
>
> RObb...
>
> ie.
>
> I did change the Ztime but that shouldn't make a difference.
>
> report = GCLA 312245Z 03014KT 350V070 CAVOK 25/19 Q1016 NOSIG
>
> rep_type = METAR
> stn_name = GCLA
> wmo_id = 60005
> lat = 28.62
> lon = -17.75
> elev = 31
> ob_hour = 22
> ob_min = 45
> ob_day = 31
> time_obs = 1065048300
> time_nominal = 1065045600
> DIR = 030
> SPD = 14
> UNITS = KT
> DIRmin = 350
> DIRmax = 070
> CAVOK = 1
> T = 25
> TD = 19
> hectoPasc_ALTIM = 1016
> NOSIG = 1
>
> T_tenths = 25
> TD_tenths = 19
>
>
>
>
>
>
>
> On Fri, 12 Sep 2003, Unidata Support wrote:
>
> >
> > ------- Forwarded Message
> >
> > >To: address@hidden
> > >From: David Larson <address@hidden>
> > >Subject: perl metar decoder -- parsing visibility / altimeter wrong
> > >Organization: UCAR/Unidata
> > >Keywords: 200309122047.h8CKldLd027998
> >
> >
> > --=-VvrFqzQaVt+D4XVsnKEy
> > Content-Type: text/plain
> > Content-Transfer-Encoding: 7bit
> >
> >
> > The decoder seems to mistake the altimeter value for visibility in many
> > non-US METARs.
> >
> > For example:
> > report = GCLA 121800Z 03014KT 350V070 CAVOK 25/19 Q1016 NOSIG
> >
> > rep_type = METAR
> > stn_name = GCLA
> > ob_hour = 18
> > ob_min = 00
> > ob_day = 12
> > time_obs = 1063389600
> > time_nominal = 1063389600
> > DIR = 030
> > SPD = 14
> > UNITS = KT
> > DIRmin = 350
> > DIRmax = 070
> > prevail_VIS_M = 1016
> > CAVOK = 1
> > WXERR = Q
> > T = 25
> > TD = 19
> > NOSIG = 1
> >
> > Note in the above that the Altimeter value Q1016 was taken for the
> > prevail_VIS_M value.
> >
> > While this happens frequently in non-US METARs, from the looks of the
> > code, it could happen anytime/anywhere ...
> >
> > I can work around the problem by moving the code that decodes the
> > Altimeter to just prior to determining the visibility.  But this seems
> > like a terrible hack because of course the general order of processing
> > in the decoder *should* flow with the order of the fields in the
> > report.  I am working on a more elegant solution.
> >
> > Has anyone else encountered this before?  Any better solutions?
> >
> > I'll post another message if I come up with something more reasonable.
> >
> > Thanks.
> >
> >
> > --=-VvrFqzQaVt+D4XVsnKEy
> > Content-Type: text/html; charset=utf-8
> > Content-Transfer-Encoding: 7bit
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
> > <HTML>
> > <HEAD>
> >   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
> >   <META NAME="GENERATOR" CONTENT="GtkHTML/1.1.8">
> > </HEAD>
> > <BODY>
> > <BR>
> > The decoder seems to mistake the altimeter value for visibility in many 
> > non-US METARs.<BR>
> > <BR>
> > For example:<BR>
> > report = GCLA 121800Z 03014KT 350V070 CAVOK 25/19 Q1016 NOSIG<BR>
> >  <BR>
> > rep_type = METAR<BR>
> > stn_name = GCLA<BR>
> > ob_hour = 18<BR>
> > ob_min = 00<BR>
> > ob_day = 12<BR>
> > time_obs = 1063389600<BR>
> > time_nominal = 1063389600<BR>
> > DIR = 030<BR>
> > SPD = 14<BR>
> > UNITS = KT<BR>
> > DIRmin = 350<BR>
> > DIRmax = 070<BR>
> > prevail_VIS_M = 1016<BR>
> > CAVOK = 1<BR>
> > WXERR = Q<BR>
> > T = 25<BR>
> > TD = 19<BR>
> > NOSIG = 1<BR>
> > <BR>
> > Note in the above that the Altimeter value Q1016 was taken for the 
> > prevail_VIS_M value.<BR>
> > <BR>
> > While this happens frequently in non-US METARs, from the looks of the code, 
> > it could happen anytime/anywhere ...<BR>
> > <BR>
> > I can work around the problem by moving the code that decodes the Altimeter 
> > to just prior to determining the visibility.&nbsp; But this seems like a 
> > terrible hack because of course the general order of processing in the 
> > decoder *should* flow with the order of the fields in the report.&nbsp; I 
> > am working on a more elegant solution.<BR>
> > <BR>
> > Has anyone else encountered this before?&nbsp; Any better solutions?<BR>
> > <BR>
> > I'll post another message if I come up with something more reasonable.<BR>
> > <BR>
> > Thanks.<BR>
> > <BR>
> > </BODY>
> > </HTML>
> >
> > --=-VvrFqzQaVt+D4XVsnKEy--
> >
> >
> > ------- End of Forwarded Message
> >
> >
>
> ===============================================================================
> Robb Kambic                              Unidata Program Center
> Software Engineer III                    Univ. Corp for Atmospheric Research
> address@hidden                   WWW: http://www.unidata.ucar.edu/
> ===============================================================================
>