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.
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.