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.
============================================================================== 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: