[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LDM #UEA-117531]: LDM data feed type recycle request
- Subject: [LDM #UEA-117531]: LDM data feed type recycle request
- Date: Tue, 07 Oct 2008 17:47:12 -0600
Hi Dave and Wilson,
Let me introduce myself: Tom Yoksas I work with Steve Emmerson here in the UPC
and have a lead (but not sole) responsibility for the configuration and
functioning
of the IDD.
Dave, could you introduce yourself? Your address@hidden email address does
not give us much information on who you are; who you work for; or what your
position
is. Thanks!
I must say that we were quite surprised that your request for the (exclusive?)
use of
an LDM/IDD feed type came with such a short fuse attached (ref: 'we are ready
now
to go "live" with the LDM RPCCDS'). This is not the procedure that was followed
for either the NEXRAD Level II or CONDUIT (NCEP high resolution model output)
feeds.
re: Dave's comments:
> That is a good question. The best answer I can give you at the moment
> is that some will be and some probably will not. For example, we already
> have three down-stream LDM receiver systems connected to our top-tier
> source servers both within NOAA (NCDC and NCEP). NCDC has its own feed-type
> (FT29 - NXRDSRC) for Level II NEXRAD WSR88D radar product archival
> distribution. NCEP (The National Centers for Environmental Prediction) in
> Suitland, MD are using the same down-stream LDM receivers to obtain our
> Level III NEXRAD Product fileset along with other IDD feeds from other
> sources. There are five existing receivers of our multicast Level III
> NEXRAD product dissemination system (soon to be retired) that will migrate
> their connections to our top-tier LDM source servers starting this month
> and some of these are also connected to the IDD (one of which is WSI who is
> a notable example as they also have their own LDM feed-type FT15 already
> reserved exclusively for them and this is the very feed-type we have been
> using for testing and validation of our own server configuration). There
> are also a growing number of others interested in obtaining our Level III
> Radar Product feed because the protocol is accessible over the Internet
> instead of requiring private T1 or MPLS circuits into the NWSTG. We expect
> that a number of these will also be connected to the IDD.
Very good. Thanks for the information.
> We could, of course, simply require that LDM receivers permitted to
> connected to our LDM RPCCDS feed be isolated from the IDD to eliminate any
> potential conflict and/or confusion, however, we expect that eventually,
> our product dissemination would become a part of the IDD as so much other
> related NOAA data already is and, of course, we would like to be prepared
> for that eventuality ahead of time.
We agree completely.
After a number of discussions here at the UPC (we are taking your request _very_
seriously), we still believe that the appropriate LDM/IDD feed type to use is
NNEXRAD.
Here is our reasoning:
- we have been using this feed type for Nexrad Level III product distribution
for several years, so our community knows what kind of products to expect
in it.
As an aside: WSI was assigned an LDM/IDD feed type when they were awarded a
contract to provide NEXRAD Level III data to the Unidata community at reduced
prices.
Since they still use this feed type to send data to a small number of Unidata
community members, we have never sought to recover the feed type for general
IDD use.
- the type of products you want to distribute using the LDM are NEXRAD Level III
products
- as you point out, the product IDs for the products you will be distributing
will be easily distinguishable from the Level III products in the NNEXRAD
feed. Give this, downstream sites can request all or select parts of the
data using appropriate regular expressions in ldmd.conf 'request' lines.
- as of LDM-6.4, the upstream feed site has control over what portion of a
datastream
a downstream will be allowed to get even when the downstream requests
everything in
that datastream (the ".*" request)
- the GPSSRC feed (aka AFOS, FT11) is being used in the SuomiNet project for
collection
of GPS data
- we have been involved in discussions with other groups whose data would make
a valuable
addition to the IDD (e.g., climate data; air quality data; etc.). Because of
this
we would rather not use the few remaining feed types remaining to LDM-6 on
data
that is essentially the same as that in an existing feed.
- Even though the restriction caused by a limited number of feed types is
designed to go
away with the next-generation LDM, exactly when the new system will be ready
as a full
replacement of the LDM-6 is not known. We believe, therefore, that
conservatism in
"resource" allocation is prudent.
re: Dave's comment:
"... it would seem appropriate to assign some other low-volume feed-type the
additional
moniker 'NEXRAD3' or 'NEXRD3' for these data instead of the much more general
'NWSTG'"
The Primary Name for the FT27 feed type could be changed from NNEXRAD to
NEXRAD3 to better
indicate that it contains NEXRAD Level III products. (The NNEXRAD name would
continue
as an alias.) If we all agree on this approach, we will change the Primary
Name for
FT27 and description to:
Primary Name Alternate Names Description
--------------+---------------------+--------------------------
NEXRAD2 FT27,NNEXRAD,NEXRAD NEXRAD Level-III products
We are assuming that you understand that the name associated with a feed type is
tied to the version of the LDM being used by a site. If you are using
LDM-6.7.x (where
6.7.x is a version in which the NNEXRAD name has been changed to NEXRAD3) to
distribute your data to a downstream who is running a version earlier than
6.7.x,
you will see the feed referred to as NEXRAD3 and the downstream will see the
feed
referred to as NNEXRAD. The feed type itself is defined by a bit in a 32-bit
word;
the feed name is somewhat irrelevant other than it being recognizable for the
type
of data in the datastream.
By the way, your request prompted us to make some long-needed updates to the
LDM-6 feed
types listed in:
http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/feedtypes/
The Primary Names now listed are, in fact, the Primary Names for sites running
LDM-6.4+.
Also, the descriptions better reflect the current contents of the various
datastreams.
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: UEA-117531
Department: Support LDM
Priority: Normal
Status: Closed