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.
David, If sflist can't find any TEXT in the file, then that would be a problem with NWX too. The decoder entry below appears correct, and is the same as I am using here under solaris from the LDM. Running sflist with: SFFILE = metar AREA = @den DATTIM = all SFPARM = text OUTPUT = T IDNTYP = STID GEMPAK-SFLIST>r <snip> KDEN 291553Z 15008KT 10SM FEW160 SCT250 M04/M08 A3030 RMK AO2 SLP294 ACSL DSNT SW-W T10441078 KDEN 291653Z 14009KT 10SM FEW200 SCT250 M02/M08 A3031 RMK AO2 SLP294 CCSL DSNT SW-W T10171083 Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP. GEMPAK-SFLIST> The above works for me on both solaris and osf/1. You might try taking a raw metar file and sending it through dcmetr my hand with -v 4 to see if there are any strange messages, and verify that the decoded file does not contain TEXT or SPCL when done that way also. Steve Chiswell Unidata User Support >From: David Ovens <address@hidden> >Organization: UCAR/Unidata >Keywords: 200012291501.eBTF1Ro18317 >Steve and Harry, > >SFPARM=text does NOT display anything, but gives this > [SFLIST -4] No valid computable parameters. > >Our pqact.conf entry does not contain the -n flag, however. Here it is: ># sfc obs and specials ># Use -m 72 to store data in 20 minute bins, rather than hourly. ># 20 minute bins useful for mesonet and AWOS data ># >DDS|IDS ^S[AP].* .... ([0-3][0-9])([0-2][0-9]) > PIPE /home/ldm/NAWIPS-5.6/bin/sol/dcmetr -b 9 -m 72 -s sfmetar_sa.tbl > -d data/gempak/logs/dcmetr.log > -e GEMTBL=/home/ldm/NAWIPS-5.6/gempak/tables > data/gempak/surface/YYYYMMDD_sao.gem > >Do you see the problem here? I don't. > >David > > >Unidata Support wrote: >> >> >From: Harry Edmon <address@hidden> >> >Organization: UCAR/Unidata >> >Keywords: 200012282354.eBSNsVo26419 >> >> >We have a problem with nwx in 5.6.A (and 5.6). >> > >> > Nwx: >> > Data --> Observed Data --> Surface Hourlies >> > This feature is not working. When you click on a site you get no data. >> > >> >By using truss, it appears that the correct surface file is being opened. >> > >> > >> >-- >> >Dr. Harry Edmon E-MAIL: address@hidden >> >(206) 543-0547 FAX: (206) 543-0308 >> >Dept of Atmospheric Sciences >> >University of Washington, Box 351640, Seattle, WA 98195-1640 >> > >> >> >> Harry, >> >> This feature works for me. You have to be storing the raw obs using dcmetr >> (eg, not using the -n flag) so that nwx can retrieve these from the >> decoded file. Are you storing the decoded files as YYYYMMDD_sao.gem? >> Nwx is pretty picky about file naming, but if you see that the correct files >> are being opened, and the raw obs (eg SFPARM=TEXT in sflist shows the obs) >> are in the file, then maybe its the station IDs. The $NWX_TABLES/sfstns.tbl >> uses 3 letter IDs as the form for retieving the stations from the surface fi > le, >> so this should agree with the table you are using for the decoded data. >> >> Can you give me details? Is this all OS's? >> >> Steve Chiswell >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** >> > > >-- > >David Ovens e-mail: address@hidden >(206) 685-8108 plan: Real-time MM5 forecasting for Pacific Northwest >Research Meteorologist >Dept of Atmospheric Sciences, Box 351640 >University of Washington >Seattle, WA 98195 >