Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong (fwd)

NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.



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

---------- Forwarded message ----------
Date: 25 Sep 2003 10:09:29 -0500
From: David Larson <davidl@xxxxxxxxxxxxxxxxxx>
To: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
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: support-decoders@xxxxxxxxxxxxxxxx
> >From: David Larson <davidl@xxxxxxxxxxxxxxxxxx>
> >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
>
>


  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the decoders archives: