NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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: