[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20001023: GEMPAK tables

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.

  • Subject: 20001023: GEMPAK tables
  • Date: Tue, 24 Oct 2000 08:09:26 -0600
>From: "Larry D. Oolman" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200010232043.e9NKha416362

>The suggested actions for the gempak decoders in decoder.tbl uses snworld.tbl
>for the station table for dcuair.  This table has not been updated since
>1995 and is missing among other things, Riverton, WY.
>
>Larry Oolman
>

Larry,

Thanks. I will repack with the snworld table that I have maintained for the
past few years. Since NCEP has updated snstns.tbl (with Riverton,
I'll change the pqact.conf entry to use that table (which is the default
for the decoder). After the workshop is over, I'll go through the
data stream and check out the tables. In the mean time, I have the snworld.tbl
filee (from my 5.4 distribution in ~gbuddy/nawips-5.4/tables/stns/)


Also, I would suggest changing the $GEMTBL/pack/snmerg.pack entry for
SPED to store with .1 resolution. Since the US soundings are
transmitted using Knots, the conversion from SKNT to SPED for storage
will not be an integer, and as a result, the info will get truncated).

Steve Chiswell