NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ ============================================================================== ---------- Forwarded message ---------- Date: 25 Sep 2003 10:09:29 -0500 From: David Larson <davidl@xxxxxxxxxxxxxxxxxx> To: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx> 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: 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 > >
decoders archives: