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.
Chris, NWX reads the products as FILEd from the LDM. It does not use gdbm. Steve Chiswell Unidata User Support >From: "C. Vandersip" <address@hidden> >Organization: . >Keywords: 200003211724.KAA18866 >Peter, > >Thnaks very much. We're running 4.9.1 on Solaris 2.5 and 2.7. One of the >reasons we'd like to do this is to improve the access times for our web >page (http://www.met.fsu.edu/weather), which utilizes your (very fine) >software. I allow folks to access up to 10 sites at a time and back to 72 >hours previous. Eliminating duplicates will speed up access times. > >I see in the README about the improvements using gdbm. The legacy here >has always been to use the ascii method, but I'm willing to change. Do >you know if using the gdbm method creates any conflicts at all with the >"nwx" program? > >Regards, > >Chris > >On Tue, 21 Mar 2000, Peter Neilley wrote: > >> Chris, >> >> WEATHER should filter out the duplicates. I capture the same WMO headers >> as you, but store them in gbdm files (the recommended way) and my duplicates > are >> filtered. However, I just noticed that if I run weather using flat, ascii M > ETAR >> files as input, the duplicates are not filtered. Hmmmm..... looks like a bu > g. >> >> I'll look into it when I get a chance and will post a new version of WEAT > HER. >> What version do you have running now? What platform? I'm dropping upgra > de >> support for SunOS (only support Solaris) and AIX. >> >> I wouldn't recommend trying to solve the problem with a more selective se > t >> of WMO headers. I think that will end up removing from your database sit > es for >> which there is not duplicate. I'd rather have duplicate reports, but be > assured >> I had 100% coverage, than not duplicates and only 98% coverage. (Those p > ercentages >> are just a top of the head guess). >> >> Peter >> >> >> Unidata Support wrote: >> > >> > >From: "C. Vandersip" <address@hidden> >> > >Organization: Florida State >> > >Keywords: 200003210659.XAA18578 weather METAR >> > >> > Chris- >> > >> > >Very often we deal with multiple metar obs for the same hour, such as: >> > > >> > >KTLH 210153Z 00000KT 10SM CLR 14/09 A3003 RMK AO2 SLP169 T01390089 >> > >KTLH 210153Z 00000KT 10SM CLR 14/09 A3003 RMK AO2 SLP169 T01390089= >> > >KTLH 210153Z 00000KT 10SM CLR 14/09 A3003= >> > >KTLH 210253Z 00000KT 10SM CLR 12/08 A3005 RMK AO2 SLP173 T01170083 51021 >> > >KTLH 210253Z 00000KT 10SM CLR 12/08 A3005 RMK AO2 SLP173 T01170083 51021= >> > >KTLH 210253Z 00000KT 10SM CLR 12/08 A3005= >> > >KTLH 210353Z 00000KT 10SM CLR 10/09 A3005 RMK AO2 SLP175 T01000089 >> > >KTLH 210353Z 00000KT 10SM CLR 10/09 A3005 RMK AO2 SLP175 T01000089= >> > >KTLH 210353Z 00000KT 10SM CLR 10/09 A3005= >> > > >> > >For the "weather" program, this type of duplication has proved to be quit > e >> > >inconvenient. Here's how the relevant code in pqact.conf is set up now: >> > > >> > > # -- METAR Reports -- >> > > # >> > > WMO ^S[AP].* .... ([0-3][0-9])([0-2][0-9]) >> > > STDIOFILE data/weather/METAR/(\1:yyyy)(\1:mm)\1\2.METAR >> > > # >> > > >> > >Do you know of a simple way to modify the header portion of the code to >> > >eliminate the duplication without dropping any original data? It appears >> > >that S*US70 and S*US80 have the full unduplicated reports while S*US53 >> > >have the "stripped" obs and S*US4* have the next-hour's obs. The latter >> > >two we'd like to delete. Yet, I still want to keep the non-S*US info. My >> > >regular expression is not very sharp right now, so I guess I'm looking fo > r >> > >a ready-made fix first before I plunge headlong into rewriting the >> > >pqact.conf header line myself. >> > >> > GEMPAK and McIDAS filter out the duplicates so we don't worry about >> > duplicates. Since we don't use (or support) the "weather" program here, >> > I'm cc'ing Peter Neilley on this for his input. Perhaps he has dealt >> > with this issue. >> > >> > >Thanks for helping the lazy (and busy), >> > >> > Another option is to send a message out to the address@hidden >> > list to see if others have dealt with this problem. >> > >> > Don Murray >> > ************************************************************************** >> > Unidata User Support UCAR Unidata Progr >> > (303)497-8644 P.O. Box 30 >> > address@hidden Boulder, CO 803 >> > -------------------------------------------------------------------------- >> > Unidata WWW Service http://www.unidata.ucar.edu/ >> > ************************************************************************** >> >> -- >> Dr. Peter P. Neilley >> Research Applications Program >> National Center for Atmospheric Research >> 3450 Mitchell Lane >> PO Box 3000 >> Boulder, CO 80307-3000 >> (303) 497-8446 >> address@hidden >> > > ############################################################### > # Chris Vandersip # > # Computer Research Specialist/Dept. Sysadmin # > # Rm. 024, Dept. of Meteorology, Florida State University # > # address@hidden (850)644-2522 # > ############################################################### >