[LDM #UEA-117531]: LDM data feed type recycle request

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