No changes had to be made to EDEX for awips to ingest these. So support is in
AWIPS for this. Those products have been produced by the ORPG at the radar
sites for some time. Usable by the local WFO locally.So that change was
implemented some time back. Ray
Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: ldm-users <ldm-users-bounces@xxxxxxxxxxxxxxxx> on behalf of Daniel Vietor
- NOAA Affiliate via ldm-users <ldm-users@xxxxxxxxxxxxxxxx>
Sent: Thursday, March 17, 2022 1:26:03 AM
To: Gilbert Sebenste <gilbert@xxxxxxxxxxxxxxxx>
Cc: LDM-Users <ldm-users@xxxxxxxxxxxxxxxx>; Mike Voss <mike.voss@xxxxxxxx>
Subject: Re: [ldm-users] NEXRAD ID changes??
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
As it turns out, it has nothing to do with the overall size of the product.
Mike Istok described it as such:
The radar product is broken down into 4000 byte segments. If a zlib compression
yields more than 5% compression, the segment will be sent zlib compressed. In
other words, if the zlib compressed segment is less than 3800 bytes, the zlib
compressed version will be sent. Otherwise, the uncompressed segment will be
sent. Mike explains that this is the way it's always been done. So he's curious
why this is a problem now.
All Radar products are zlib compressed by default. The compression happens at a
frame (block) level. The uplink reader process will skip each 4000 byte frame
(block) compression when
- uncompressed length is less than minimum frame length of 100 bytes
- difference between uncompressed and compressed is less than 50
- compression factor > 95
A product is divided into multiple blocks/frames and each frame is compressed.
If any of the above criteria is met then the compression for that frame will be
skipped.
This is good information. This explains why the 153 products only have the
first 4000 bytes zlib compressed. This is because the following segments would
gain nothing by zlib compressing them and they are sent uncompressed (as far as
zlib compression is concerned).
What this points out is that there is something in the 153 (N0B) header that
allows it to compress better than what we saw in the 94 (N0Q) header. But it
seems to be on the very edge. Some products get the header compressed and
others don't.
In looking at the difference between the raw files from SBN and the ucnids
files, it appears the difference between the two is roughly between 230 and 300
bytes.
But it seems that the products with little to no precipitation don't get zlib
compressed while those with a lot of precipitation do.
Dan.
On Wed, Mar 16, 2022 at 5:27 PM Gilbert Sebenste
<gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx>> wrote:
Yes. The bottom line is…if the file size gets to a certain point, it will get
the additional compression. As they say: it's a feature, not a bug.
Gilbert
On Mar 11, 2022, at 12:47 PM, Mike Zuranski
<zuranski.wx@xxxxxxxxx<mailto:zuranski.wx@xxxxxxxxx>> wrote:
Has anybody heard an update on this?
I'm still seeing this bad data coming over NEXRAD3, and rather confused why
there hasn't been some kind of admin notice for this yet. I'd have thought
this would be a priority for somebody by now.
-Mike
======================
Mike Zuranski
Meteorology Support Analyst
College of DuPage - Nexlab
Weather.cod.edu<http://weather.cod.edu/>
======================
On Mon, Mar 7, 2022 at 4:52 PM Gilbert Sebenste
<gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx>> wrote:
I got a message from Mike Istok. He says this is the first they have heard of
this, and the NOAAport engineering team is looking at it now. He'll report back
when he finds out more.
Gilbert
On Mar 7, 2022, at 1:55 PM, Daniel Vietor - NOAA Affiliate
<dan.vietor@xxxxxxxx<mailto:dan.vietor@xxxxxxxx>> wrote:
OK, I'll treat this as a bug for now. It does seem like it's getting better. I
wrote a quick script to list those files with zlib compression. There are a lot
of N0S and EET products but these aren't also bzip2 compressed so my code
handles it. There were 46 N0B products in the last hour that were zlib
compressed:
/mnt/data/noaaport/nids/BGM/20220307_1904_N0B.nid 368774 zlib
/mnt/data/noaaport/nids/BGM/20220307_1910_N0B.nid 366048 zlib
/mnt/data/noaaport/nids/BGM/20220307_1916_N0B.nid 365302 zlib
/mnt/data/noaaport/nids/BGM/20220307_1922_N0B.nid 363941 zlib
/mnt/data/noaaport/nids/BGM/20220307_1929_N0B.nid 359692 zlib
/mnt/data/noaaport/nids/BGM/20220307_1935_N0B.nid 355491 zlib
/mnt/data/noaaport/nids/BGM/20220307_1941_N0B.nid 352040 zlib
/mnt/data/noaaport/nids/BGM/20220307_1947_N0B.nid 346301 zlib
/mnt/data/noaaport/nids/BGM/20220307_1953_N0B.nid 338393 zlib
/mnt/data/noaaport/nids/CBW/20220307_1916_N0B.nid 355862 zlib
/mnt/data/noaaport/nids/CBW/20220307_1922_N0B.nid 361885 zlib
/mnt/data/noaaport/nids/CBW/20220307_1928_N0B.nid 369223 zlib
/mnt/data/noaaport/nids/CBW/20220307_1934_N0B.nid 372702 zlib
/mnt/data/noaaport/nids/CBW/20220307_1940_N0B.nid 374620 zlib
/mnt/data/noaaport/nids/CBW/20220307_1946_N0B.nid 375270 zlib
/mnt/data/noaaport/nids/CBW/20220307_1952_N0B.nid 373890 zlib
/mnt/data/noaaport/nids/CCX/20220307_1901_N0B.nid 361946 zlib
/mnt/data/noaaport/nids/CCX/20220307_1907_N0B.nid 360498 zlib
/mnt/data/noaaport/nids/CCX/20220307_1913_N0B.nid 361337 zlib
/mnt/data/noaaport/nids/CCX/20220307_1918_N0B.nid 357527 zlib
/mnt/data/noaaport/nids/CCX/20220307_1924_N0B.nid 352904 zlib
/mnt/data/noaaport/nids/CCX/20220307_1930_N0B.nid 350048 zlib
/mnt/data/noaaport/nids/CCX/20220307_1936_N0B.nid 340482 zlib
/mnt/data/noaaport/nids/CCX/20220307_1942_N0B.nid 329713 zlib
/mnt/data/noaaport/nids/CCX/20220307_1948_N0B.nid 319300 zlib
/mnt/data/noaaport/nids/ENX/20220307_1912_N0B.nid 324750 zlib
/mnt/data/noaaport/nids/ENX/20220307_1930_N0B.nid 329362 zlib
/mnt/data/noaaport/nids/ENX/20220307_1941_N0B.nid 329805 zlib
/mnt/data/noaaport/nids/ENX/20220307_1947_N0B.nid 333013 zlib
/mnt/data/noaaport/nids/ENX/20220307_1953_N0B.nid 333542 zlib
/mnt/data/noaaport/nids/GYX/20220307_1940_N0B.nid 321435 zlib
/mnt/data/noaaport/nids/GYX/20220307_1946_N0B.nid 318901 zlib
/mnt/data/noaaport/nids/HTX/20220307_1902_N0B.nid 286756 zlib
/mnt/data/noaaport/nids/HTX/20220307_1905_N0B.nid 281872 zlib
/mnt/data/noaaport/nids/HTX/20220307_1912_N0B.nid 282532 zlib
/mnt/data/noaaport/nids/MRX/20220307_1902_N0B.nid 286064 zlib
/mnt/data/noaaport/nids/MRX/20220307_1908_N0B.nid 286126 zlib
/mnt/data/noaaport/nids/MRX/20220307_1914_N0B.nid 286212 zlib
/mnt/data/noaaport/nids/MRX/20220307_1920_N0B.nid 286076 zlib
/mnt/data/noaaport/nids/MRX/20220307_1926_N0B.nid 285670 zlib
/mnt/data/noaaport/nids/MRX/20220307_1932_N0B.nid 288133 zlib
/mnt/data/noaaport/nids/MRX/20220307_1938_N0B.nid 283514 zlib
/mnt/data/noaaport/nids/MRX/20220307_1944_N0B.nid 285975 zlib
/mnt/data/noaaport/nids/MRX/20220307_1950_N0B.nid 288229 zlib
/mnt/data/noaaport/nids/RLX/20220307_1901_N0B.nid 312651 zlib
/mnt/data/noaaport/nids/RLX/20220307_1903_N0B.nid 309328 zlib
/mnt/data/noaaport/nids/RLX/20220307_1905_N0B.nid 307597 zlib
/mnt/data/noaaport/nids/RLX/20220307_1911_N0B.nid 299850 zlib
/mnt/data/noaaport/nids/RLX/20220307_1918_N0B.nid 296619 zlib
/mnt/data/noaaport/nids/TYX/20220307_1936_N0B.nid 253444 zlib
Dan.
On Mon, Mar 7, 2022 at 1:32 PM Herzmann, Daryl E [AGRON]
<akrherz@xxxxxxxxxxx<mailto:akrherz@xxxxxxxxxxx>> wrote:
Thanks Dan. I agree, my theory has been debunked!
daryl
________________________________________
From: Daniel Vietor - NOAA Affiliate
<dan.vietor@xxxxxxxx<mailto:dan.vietor@xxxxxxxx>>
Sent: Monday, March 7, 2022 1:31 PM
To: Mike Zuranski
Cc: LDM-Users; Herzmann, Daryl E [AGRON]; Gilbert Sebenste; Mike Voss
Subject: Re: [ldm-users] NEXRAD ID changes??
Here is what I'm seeing:
> pqlist -v -i 2 -p N0BHTX -O
282532 20220307/191247.959 NEXRAD3 73337671 SDUS54 KHUN 071912 /pN0BHTX
desi.unidata.ucar.edu_v_noaaport2.wright-weather.com<http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com><http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com>
286260 20220307/191605.178 NEXRAD3 73347001 SDUS54 KHUN 071915 /pN0BHTX
!nids/
desi.unidata.ucar.edu_v_noaaport2.wright-weather.com<http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com><http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com>
283571 20220307/191903.226 NEXRAD3 73355592 SDUS54 KHUN 071918 /pN0BHTX
!nids/
desi.unidata.ucar.edu_v_noaaport2.wright-weather.com<http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com><http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com>
288726 20220307/192204.649 NEXRAD3 73363877 SDUS54 KHUN 071921 /pN0BHTX
!nids/
desi.unidata.ucar.edu_v_noaaport2.wright-weather.com<http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com><http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com>
285988 20220307/192603.930 NEXRAD3 73374809 SDUS54 KHUN 071925 /pN0BHTX
!nids/
desi.unidata.ucar.edu_v_noaaport2.wright-weather.com<http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com><http://desi.unidata.ucar.edu_v_noaaport2.wright-weather.com>
desi.unidata seems to be the source for all the products. But those that are
zlib compressed don't have a "!nids" on the end of the header,
I checked our feed at AWC which is coming straight from a dish in the back 40.
00000000 01 0d 0d 0a 30 30 30 0d 0d 0a 53 44 55 53 35 34 |....000...SDUS54|
00000010 20 4b 48 55 4e 20 30 37 31 39 31 32 0d 0d 0a 4e | KHUN 071912...N|
00000020 30 42 48 54 58 0d 0d 0a 78 da 85 57 7b 54 13 d7 |0BHTX...x..W{T..|
00000030 ba 1f 1e 8a da 82 de ab d6 16 8a da f6 54 c4 9e |.............T..|
00000040 4a 55 1e 0a 26 82 68 7d b4 12 4f 11 53 c0 84 9e |JU..&.h}..O.S...|
00000050 52 e4 11 92 a8 90 cc 21 c3 58 d4 56 5b 2d a5 ad |R......!.X.V[-..|
00000060 0f 0a 31 80 72 25 2a 92 88 98 44 32 cc 5c 5b 7b |..1.r%*...D2.\[{|
00000070 44 94 80 8a 10 c2 30 33 ad 08 01 92 99 29 8f 64 |D.....03.....).d|
It's coming off the dish that way.
Dan.
On Mon, Mar 7, 2022 at 1:18 PM Mike Zuranski
<zuranski.wx@xxxxxxxxx<mailto:zuranski.wx@xxxxxxxxx><mailto:zuranski.wx@xxxxxxxxx<mailto:zuranski.wx@xxxxxxxxx>>>
wrote:
FWIW it's not just N.B products doing this...
20220307T191633.718220Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 18370 20220307191632.821513
NEXRAD3 73348475 SDUS26 KHNX 071911 /pNBBHNX !nids/
20220307T191633.718326Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 6152 20220307191632.867833
NEXRAD3 73348476 SDUS58 PAFC 071914 /pN0SAIH
20220307T191633.766274Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 19778 20220307191632.870118
NEXRAD3 73348477 SDUS28 PAFC 071910 /pN3BAKC !nids/
20220307T191633.766402Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 2178 20220307191632.870344
NEXRAD3 73348478 SDUS52 KMLB 071913 /pDPAMLB
20220307T191633.810195Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 98306 20220307191632.886132
NEXRAD3 73348479 SDUS21 KCTP 071913 /pN2BCCX !nids/
20220307T191633.810287Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 1552 20220307191632.888075
NEXRAD3 73348480 SDUS55 KSLC 071910 /pNCRSLC
20220307T191633.854166Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 67908 20220307191633.029729
NEXRAD3 73348481 SDUS52 KFFC 071915 /pTV0ATL !nids/
20220307T191633.854309Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 4380 20220307191633.030216
NEXRAD3 73348482 SDUS52 KMLB 071913 /pNTPMLB
20220307T191633.898156Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 233 20220307191633.030298
NEXRAD3 73348483 SDUS55 KSLC 071910 /pNVLSLC
20220307T191633.898265Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 4050 20220307191633.032406
NEXRAD3 73348484 SDUS52 KMLB 071913 /pDSPMLB !nids/
20220307T191633.946219Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 4484 20220307191633.035764
NEXRAD3 73348485 SDUS32 KMLB 071913 /pN1PMLB
20220307T191633.946316Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 73239 20220307191633.047202
NEXRAD3 73348486 SDUS55 KSLC 071915 /pNYGICX !nids/
20220307T191633.990205Z notifyme[70117]
notifyme.c:notifymeprog_5:212 INFO 15915 20220307191633.049020
NEXRAD3 73348487 SDUS26 KHNX 071911 /pNBUHNX !nids/
I have not dug any deeper on those files however.
-Mike
======================
Mike Zuranski
Meteorology Support Analyst
College of DuPage - Nexlab
Weather.cod.edu<http://Weather.cod.edu><http://weather.cod.edu/>
======================
On Mon, Mar 7, 2022 at 1:11 PM Mike Zuranski
<zuranski.wx@xxxxxxxxx<mailto:zuranski.wx@xxxxxxxxx><mailto:zuranski.wx@xxxxxxxxx<mailto:zuranski.wx@xxxxxxxxx>>>
wrote:
I'm gonna go out on a limb and say it's a bug...
An observation I made that correlates with yours: Shortly after RAX began
issuing N.B products there was a period where they were coming in... badly
somehow. The detail I noticed was the missing "!nids/" at the end of nexrad
products while watching the nexrad3 feed. And like you noticed that was
temporary.
I see the same thing this morning from a number of sites (LOT grabbed my
attention first). I also see the number of sites doing this are decreasing, so
I'm wondering if this is being worked on somewhere. But any nexrad products
that I see in LDM that do not contain "!nids/" at the end do not jive with
McIDAS nor Gempak while all others do.
Brief example:
20220307T185809.320700Z notifyme[10618]
notifyme.c:notifymeprog_5:212 INFO 123297 20220307185809.170361
NEXRAD3 73287741 SDUS58 PAFC 071856 /pN0BAKC !nids/
20220307T185811.881051Z notifyme[10618]
notifyme.c:notifymeprog_5:212 INFO 314053 20220307185811.690988
NEXRAD3 73287963 SDUS51 KRLX 071857 /pN0BRLX
20220307T185813.488004Z notifyme[10618]
notifyme.c:notifymeprog_5:212 INFO 191116 20220307185813.222289
NEXRAD3 73287985 SDUS53 KGRR 071856 /pN0BGRR !nids/
Daryl: I'm not sure there's a correlation to
exengine4.fox.com<http://exengine4.fox.com><http://exengine4.fox.com>, last
time it was data straight out of SBN doing this. My Noaaport's been down a
while so I can't confirm that right now though.
-Mike
======================
Mike Zuranski
Meteorology Support Analyst
College of DuPage - Nexlab
Weather.cod.edu<http://Weather.cod.edu><http://weather.cod.edu/>
======================
On Mon, Mar 7, 2022 at 1:04 PM Daniel Vietor - NOAA Affiliate via ldm-users
<ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>>>
wrote:
Is it just me or are people seeing a strange zlib compression of the new N0B
products. When RAX first came out, it was OK and then for a couple of days I
saw the front end of the product was zlib compressed like the old days of the
nexrad products. It went away so I didn't think much about it.
But then yesterday it came back. Several sites were intermittently zlib
compressing the N0B product. I noted Topeka, Kansas City, Springfield, St
Louis, Chicago, Evansville, Indianapolis and N Indiana were doing it. But it
was intermittent. One scan would be zlib compressed and the next wouldn't be.
It was like something in the product, like size, was triggering the zlib
compression.
I took a look at some of the data. Only the first 4000 bytes are zlib
compressed. The radial payload is still bzip2 compressed. Since only the
header, which is about 100 bytes, is uncompressed, the zlib compression is
compressing over 3800 bytes of the radial payload. This seems strange. Why
compress data that are already compressed?
After last night, it seems like this is a feature of the new N0B radar data and
not a bug. So I resurrected the old ucnid.c program I wrote 24 years ago to
remove the zlib compression on the N0B products.
So is this a bug or a feature?
Dan.
On Fri, Mar 4, 2022 at 10:36 AM Gilbert Sebenste
<gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx><mailto:gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx>>>
wrote:
Nothing beats a good Daryl LDM-users rant in the morning. He never lets me down!
Imagine my utter surprise when I did what Daryl said and I found products I
didn't know were being sent over NOAAport. Then, I got curious and instead of
using the "NEXRAD" feedtype, I used "ANY". That's when I was shocked to find
several products being sent under the HRS feed that were completely
undocumented by the NWS, and were needed! I alerted Steve Emmerson, who put out
a fix for it. 6.13.16 has it all sorted out now.
I'll point out that this thinking goes for any product. If there's a product
you think should be there that isn't coming in, and you know you're getting the
entire feed, use a request of "ANY" on that header. Rarely, it's an LDM bug,
but like the example above, it can happen where a product shows up on an
unexpected feedtype.
Gilbert
> On Mar 4, 2022, at 10:17 AM, Herzmann, Daryl E [AGRON]
> <akrherz@xxxxxxxxxxx<mailto:akrherz@xxxxxxxxxxx><mailto:akrherz@xxxxxxxxxxx<mailto:akrherz@xxxxxxxxxxx>>>
> wrote:
>
> Good morning,
>
> I'd like to chime on the topic of "best practice for pqact entries". For the
> WMO header found in products, there's a general form for the entries found:
>
> TTAAII CCCC DDHHMI
>
> When there's a string found in the line below the WMO header that is six or
> so characters, this "PIL" is appended to LDM product name in the form like so:
>
> TTAAII CCCC DDHHMI /pPILXXX
>
> Summary: I *do not* trust the TTAAII value and only sparingly use it within a
> pqact entry, but instead fully trust the /pPILXXX section.
>
> In December 2015, I meet with the NWS Data Management folks expressing
> interest in quality controlling the CCCC portion of the WMO header. Can you
> imagine that it is sometimes wrong? Well, it has been 6+ years now, hundreds
> of emails, and I'm still not done getting them to correct issues with it. As
> an example of how painful the rabbit hole is, NWS Cheyenne KCYS was issuing
> TAFs for 3 sites using KOAX as the CCCC. This took 8 months to fix and I am
> still unsure if it is fully fixed.
>
> I have not even attempted automated quality control of the TTAAII, nor
> bugging NWS to fix it. Another story. I actually did attempt to get NWS to
> fix the TTAAII in the case of a product that wasn't using 6 characters for
> the TTAAII, can you imagine that it is sometimes only 5? That request was
> rejected. Anyway, this value used to be more rigorously set, but is now
> more arbitrary than ever. So in the original example below.
>
> NEXRAD ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
>
> I would only trust the SDUS and drop any checks on the other TTAAII fields.
> Instead, put your limiters into the /p section.
>
> NEXRAD ^SDUS.. ....
> ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(N0Q|N0B|N0G|Nwhatever)(...)
>
> Oh, there are examples in the TTAAII, where the AA is wrong, but I have
> ranted/whined enough already.
>
> daryl
>
> ________________________________________
> From: ldm-users
> <ldm-users-bounces@xxxxxxxxxxxxxxxx<mailto:ldm-users-bounces@xxxxxxxxxxxxxxxx><mailto:ldm-users-bounces@xxxxxxxxxxxxxxxx<mailto:ldm-users-bounces@xxxxxxxxxxxxxxxx>>>
> on behalf of Gilbert Sebenste
> <gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx><mailto:gilbert@xxxxxxxxxxxxxxxx<mailto:gilbert@xxxxxxxxxxxxxxxx>>>
> Sent: Friday, March 4, 2022 9:54 AM
> To: Daniel Vietor - NOAA Affiliate
> Cc: LDM-Users; Mike Voss
> Subject: Re: [ldm-users] NEXRAD ID changes??
>
> If you have LDM version 6.13.16, this shouldn't be happening. A bug fix was
> applied to ensure that everything NEXRAD3 is supposed to be there.
>
> Gilbert
>
> On Mar 4, 2022, at 9:15 AM, Daniel Vietor - NOAA Affiliate via ldm-users
> <ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>>>
> wrote:
>
>
> I see a lot of them on the HDS feedtype. So I request both NEXRAD and HDS.
>
> Dan.
>
> On Fri, Mar 4, 2022 at 9:04 AM Mike Voss
> <mike.voss@xxxxxxxx<mailto:mike.voss@xxxxxxxx><mailto:mike.voss@xxxxxxxx<mailto:mike.voss@xxxxxxxx>><mailto:mike.voss@xxxxxxxx<mailto:mike.voss@xxxxxxxx><mailto:mike.voss@xxxxxxxx<mailto:mike.voss@xxxxxxxx>>>>
> wrote:
> Hi All,
> For me at least, some of my NEXRAD products stopped filing correctly
> yesterday at 18Z using this generic pattern match:
>
> NEXRAD ^SDUS[2357]. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
> FILE -overwrite -close
> nexrad/NIDS/\5/\4/\4_(\1:yyyy)(\1:mm)\1_\2\3
>
> as a test, when I changed to this:
> NEXRAD ^SDUS66 ....
>
> I started getting my "N0Q" products for MUX station.
>
> Also, I stopped receiving the FNEXRAD NEXRCOMP products. Is it possible
> these things are related such that the NEXRCOMP depends on the NIDS product
> ID's and somehow a recent change (yesterday) cause this to break?
>
> thanks for any insights,
> -MIke
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> ldm-users mailing list
> ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>>>
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
>
> --
> Dan Vietor
> Senior Research Meteorologist
> CIRA, Colorado State Univ
> Aviation Weather Center
> Kansas City, MO
> 816.584.7211
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> ldm-users mailing list
> ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>>
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
--
Dan Vietor
Senior Research Meteorologist
CIRA, Colorado State Univ
Aviation Weather Center
Kansas City, MO
816.584.7211
_______________________________________________
NOTE: All exchanges posted to Unidata maintained email lists are
recorded in the Unidata inquiry tracking system and made publicly
available through the web. Users who post to any of the lists we
maintain are reminded to remove any personal information that they
do not want to be made public.
ldm-users mailing list
ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx><mailto:ldm-users@xxxxxxxxxxxxxxxx<mailto:ldm-users@xxxxxxxxxxxxxxxx>>
For list information or to unsubscribe, visit:
https://www.unidata.ucar.edu/mailing_lists/
--
Dan Vietor
Senior Research Meteorologist
CIRA, Colorado State Univ
Aviation Weather Center
Kansas City, MO
816.584.7211
--
Dan Vietor
Senior Research Meteorologist
CIRA, Colorado State Univ
Aviation Weather Center
Kansas City, MO
816.584.7211
--
Dan Vietor
Senior Research Meteorologist
CIRA, Colorado State Univ
Aviation Weather Center
Kansas City, MO
816.584.7211
