NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
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/ ==============================================================================
decoders archives: