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

19990919: shef data

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: 19990919: shef data
  • Date: Mon, 20 Sep 1999 15:27:12 -0600

On Mon, 20 Sep 1999, Arthur A. Person wrote:

> On Mon, 20 Sep 1999, Dan Vietor wrote:
> 
> > Now for the million dollar question!  Does anyone have an up to date
> > database of SHEF station locations??  When I last checked, these were
> > kept locally or regionally and thus it was next to impossible to get a
> > complete list.  I have a partial list but I doubt its terribly up to
> > date.
> 
> I have an old one (about 7 years old) but my bigger concern is that there
> were about 26,000 entries in it for the whole U.S.  I want to use it with
> gempak but the station index limit (as it's set now in the Unidata
> distribution) is 9800, which means I can't use the whole index at one
> time.  I'm still contemplating a solution to this, as I'm not sure who
> gempak would run with the index set to 30000.
> 
>                                             Art.
> Arthur A. Person
> Research Assistant, System Administrator
> Penn State Department of Meteorology
> email:  address@hidden, phone:  814-863-1563
> 
> 


Art,

You can up the number of stations to 30,000. The NLDN files are an example
of this- since the number of lightning strikes frequently exceeds 10,000
in an hour. 

The programs ltglist and ltgmap are the same as sflist and sfmap-
only the array sizes are increased in the header files. But, you can
define the sizes as needed for the genaral build- eg as described in
http://www.unidata.ucar.edu/glimpse/gempak/3101. The considerations
are of course, file size (and the efficiency of searching a large file),
and the ability for others to read your files if needed- since they
will have to have similarly large sizes defined.

The AFOS pil identifiers may be of use for specifying smaller regional
decoded files as an alternative to singularly huge files however.
By keying on the /p... part of the identifier in pqact.conf, you
could descriminate how to store the data sets.

Steve Chiswell
Unidata User Support