[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong
- Subject: Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong
- Date: Wed, 24 Sep 2003 14:34:05 -0600 (MDT)
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. 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.<BR>
> <BR>
> Has anyone else encountered this before? 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/
===============================================================================