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.
=============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ =============================================================================== ---------- Forwarded message ---------- Date: 25 Sep 2003 10:09:29 -0500 From: David Larson <address@hidden> To: Robb Kambic <address@hidden> Subject: Re: 20030912: perl metar decoder -- parsing visibility / altimeter wrong My mistake, terribly sorry, thanks for taking the time to check this out. I went back to the original/prestine 2.4.4 release code and the results came out correctly for me as well. I'll do a diff and see what I botched to cause this ... Dave On Wed, 2003-09-24 at 15:34, Robb Kambic wrote: > 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/ > =============================================================================== >