[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[NOAAPORT #LVN-177572]: Mod for NOAAport component of LDM
- Subject: [NOAAPORT #LVN-177572]: Mod for NOAAport component of LDM
- Date: Thu, 09 Jul 2020 14:38:30 -0600
Hi Dan,
I just sent you an email with an invitation to join Steve and I in
an Google Meet...
re:
> AWC was using NOAAPort ingest software developed within NWS for a long
> time. But when we upgraded to RH6 back in 2015, that software no longer
> worked. So I recommended going to LDM and noaaportIngester. I set up a
> server running LDM and getting NOAAPort data. We started getting data and
> the system has been far more stable than the previous ingest code we used.
>
> The problem quickly became duplicate products. The backup feed we have from
> the TOC had a slightly different product configuration and duplicate
> products were no longer duplicates. So we got 2 sets of METARs, TAFs,
> basically any text product we also got from the TOC. I researched the
> difference and modified the productMaker code accordingly. Here are the
> changes:
>
> 1) removed an extra space after the sequence number in the WMO header CCB.
> 2) changed the sequence number to "000" to match the TOC sequence number
> 3) put in a check to not add a CR-CR-LF on text products that already ended
> with CR-CR-LF.
>
> This meant that the text products were 4 bytes shorter but it allowed
> duplicates to be removed.
>
> I put in a request to see if this could be added to the LDM baseline back
> in 2015. At the time, Gregg had requested to do the same for their
> ingesters at SPC. So rather than propagating these changes on each upgrade
> of LDM, it would be nice to have it in the baseline.
>
> Back then the same issues came up surrounding IDD and downstream
> compatibility. I recommended making it a command line toggle or a
> preprocessor directive. Back then this was deemed as a one time local
> change. So it never made it into the baseline.
>
> I'm OK with propagating the changes. It only affects two lines of code.
> There has only been one upgrade of productMaker that made me search for the
> code to change. It's been pretty stable. This is why I haven't gone back to
> Unidata promoting the changes.
>
> But if other NWS sites are running into the same problem, maybe it makes
> sense to investigate this again?
My view is that is that a decision was made to modify the LDM to make
products look like the system that was reading from a socket. It seems
to me that there would likely be a LOT less impact if the code that
reads from the socket were changed to make the products look like
the ones in NOAAPort. What do you think?
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: Open
===================
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.