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: 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. 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
rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/
==============================================================================