[NOAAPORT #LVN-177572]: Mod for NOAAport component of LDM

HI Gregg,

re:
> Yes, I can see why consideration needs to be given to all IDD sites.

The NWS has adopted the LDM as a primary mover of data in their latest
refresh.  Raytheon adopted the LDM for use in AWIPS.  The Army Corps of
Engineers and NASA also use the LDM for data delivery.  Foreign weather
services use the LDM for their data delivery, etc.  This is all on
top of the educational community that relies on the LDM/IDD as their
primary source of real-time data.  As you can imagine, the impact of
fundamental changes to the size of products which, in turn, changes
their MD5 signatures, would be quite far reaching.

re:
> For a site that has a "NOAAPort downlink AND are fed from the IDD", does
> this mean the IDD is essentially a NOAAPort feed from some upstream LDM
> server?

The IDD content is composed of NOAAPort-derived and other sources of data.
The IDD feeds HDS, IDS|DDPLUS, NEXRAD3, NGRID and NOTHER are populated
solely with products from NOAAPort.  Given the decrease/cessation of
GINI products, the NIMAGE feed was appropriated so that we could
deliver fully reconstituted GOES-16 and GOES-17 images (that are created
by stitching together the tiles sent in the NOAAPort NOTHER feed) to
user sites thus alleviating them of the overhead of stitching together
the tiles themselves.  All of the other IDD feeds come from non-NOAAPort
sources.  For reference, the listing of feeds from a randomly chosen
real-server backend of one of the Unidata top level IDD relay clusters
can be seen in:

https://rtstats.unidata.ucar.edu/cgi-bin/rtstats/siteindex?node5.unidata.ucar.edu

re:
> Or is it possibly some other feedtype from the NWS (e.g. a socket
> feed, or Weather Wire feed)?

We do not put data coming from socket or Weather Wire feeds into the
IDD as we do not have/use those sources of data.  Whether or not a
source of data that we deliver does (e.g., CONDUIT which is maintained
by NCEP) I can not say.

re:
> What if there was an argument or flag for noaaportIngester, and if the flag
> is set then this part of the code is executed/utilized for those sites that
> also have a socket connection to the NWSTG/GATEWAY?

That is the kind of approach that Steve would have to weigh in on as it
would affect the LDM packaging, documentation, support, etc. not to
mention development time.

Earlier today, I sent a note to Steve musing that it would be interesting
to get Raytheon's slant on your proposed incorporation of Dan's code
into the LDM core.  Steve has worked with Raytheon to incorporate changes
that they deemed vital for AWIPS, so there is a precedence for inclusion
of new code that is not active by default.  Since I don't know the size
of the job to incorporate Dan's code and thoroughly test it, I can not say
if it would be feasible without additional sources of funding.

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: LVN-177572
Department: Support NOAAPORT
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.