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 Pete, > Where did you get that format btw?? In the textlightninig EDEX plugin (baseline code), there are a number of given formats that the lightning data tries to match to. That file is here: https://github.com/Unidata/awips2/blob/unidata_18.2.1/edexOsgi/com.raytheon.edex.plugin.textlightning/src/com/raytheon/edex/plugin/textlightning/impl/TextLightningParser.java Some examples are listed there: line 169, line 202, line 240, etc. > 1. The amplitude is implicit how its plotted (as a + or - sign) in CAVE and > what "unknown" title in the product stack it will then fall under. But > removing >the - sign will always have it plotted/listed as +. I will try the > other pattern and let you know what happens. Correct, but whether it's -2.2 vs -22, it will show up the same in CAVE (as a negative CG and vice versa if there was no "-"). So you should be able to use the first pattern. > 2. As for the pqact entry here it is... its pretty generic. > # NLDN > LIGHTNING LIGHTNING > FILE -close -edex /awips2/data_store/lightning/%Y%m%d%H%M.nldn > pqinsert -v -l ./log.log -f LIGHTNING ./test_nldn Looking at your pqact entry, it's expecting a feedtype of "LIGHTNING" and a filename or WMO header of "LIGHTNING" Looking at your pqinsert command, you are giving it the feedtype "LIGHTNING" but your file doesn't have a WMO header and your filename is not "LIGHTNING" Depending on how you are storing your initial file/passing it in via your pqinsert you will need to update your pqact entry to match the filename. I can help with that once you let me know how you are storing your file. > We'd like to pursue the pqact method since it *should* work and rendering in > CAVE will be implicit based on polarity and should fall under the already- > >present NLDN menu in CAVE's "Surface" menu. Using pqact method is fine, however that is not what specifies how the data will be ingested by EDEX. Because you have text data, EDEX will decode your file using the textlightning plugin, not the binlightning (NLDN) plugin. With the current code, the textlightning plugin stores the data as "UNKN" using the first two pattern matching strings. In order to store the data as "NLDN" the java code would need to be updated by adding a new pattern matching block and setting the LightSource as "NLDN". Thanks, Tiffany Meyer AWIPS Lead Software Engineer UCAR-Unidata If you're interested, please feel free to fill out a survey about the support you receive: https://docs.google.com/forms/d/e/1FAIpQLSeDIkdk8qUMgq8ZdM4jhP-ubJPUOr-mJMQgxInwoAWoV5QcOw/viewform