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

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

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong
  • Date: Tue, 23 Sep 2003 14:21:51 -0600 (MDT)
David,

I see the problem that you are referring too, not good. I need to catch up
here,  been out of town for 1.5 weeks.  Will get back with a solution.

Thanks,
Robb...


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/
===============================================================================