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