[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20010205: LDM-METAR problem
- Subject: Re: 20010205: LDM-METAR problem
- Date: Tue, 13 Feb 2001 11:22:18 -0700 (MST)
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/
===============================================================================