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.
On Tue, 6 Feb 2001, Greg Thompson wrote: > > > Could you be more specific about what SPECIs are missing? Is it all > > SPECIs, ones in METAR bulletins, Canadian ones, etc. As I stated before > > Yesterday at 13z there were 3 SPECIs issued for KSWF (as told to me > by a user). I checked and found them in RAP's plain text file but > they did not appear in the gdb files created by pqsurf. I haven't > re-investigated the Canadian site issue. I'm assuming all SPECIs > are missing but have not researched it exactly. Greg, I still have not received enough info to look at the problem. As I stated before, SPECI come in under different Bulletin headings, that's what I need, not the the particular station report. Sometime SPECI come out under METAR bulletins, etc. > > > the format of these files are in constant change so it's really hard to > > keep up with this problem. I talked to Russ Rew (system group supervisor) > > What exactly is changing The major change is the line after the WMO message, sometimes there a line that has METAR, SPECI, METAR PIL, etc. If the line is missing like the Canadian reports, the code gets confused and eats part of the report and sometimes throws away the complete bulletin. and why can't the C-code be written to It can be written but it's a much larger effort and not as flexible. > mimic how Perl does its pattern recognition? Seems to me it should > be totally possible. Don't forget Perl is VERY slow compared to > compiled C-code. Not true, I have done many comparison between perl and c programs. There is a small startup cost on perl, otherwise the decoders run at the same rate. That why I don't stop and start the perl decoders on every product. This is a bad practise with any decoder because the spin up time eats much of the machines CPU. Robb... > > > pqsurf and easier to maintain. The perl script would be less indirection > > then the present pqsurf architecture also. The perl decoder metar2nc > > could be used as a template for the new pqsurf. > > Yeah, it's on my list of things to do but these things take time. > We don't use netCDF files at all for our METAR plotting packages > (Java and NCAR Graphics). > > 3 weeks ago I picked up a copy of metar2nc from ftp.unidata. I have > made many improvements to the code primarily for international METARs > which the existing Perl code was sub-optimal. I gutted the netCDF > aspects and am replacing it with MySQL. I'm finished with the > decoder and will now be populating the DB tables by next week. It > should be a dramatic improvement for usability in our environment. > I am using MySQL because I want to write PHP scripts for the web > that can pull the data quickly and efficiently from web pages. It's > a makeover with the web in mind - METARs are first and lots more > weather data will follow. > > -- > +--------------------------------------------------------------+ > | Greg Thompson http://www.rap.ucar.edu/staff/gthompsn/ | > | Research Applications Program | > | (303) 497-2805 National Center for Atmospheric Research | > | (fax) -8401 P.O. Box 3000 Boulder, CO 80307-3000 | > +--------------------------------------------------------------+ > =============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ ===============================================================================