[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010109: papagayo LDM filing of NOAAPORT NEXRAD Level III products

>From: Unidata Support <address@hidden>
>Organization: University of Nebraska-Lincoln
>>Keywords: 200101091754.f09Hsso22365 IDD NNEXRAD pqact.conf


Chiz and I chatted about your NEXRAD Level III product ingestion and
display in GEMPAK late today.  I had noticed that my ADDE server was
not able to display the images that you were uncompressing with Vietor's
ucnids routine, so I was curious about whether or not you were going
to file the products directly.  Since I was already logged onto
papagayo, I decided to snoop around to "see what I could see".

I found out that your ~ldm/etc/pqact.conf entry for dealing with
NNEXRAD feed type products was most likely not what you really wanted:

NNEXRAD        ^SDUS5. .(...) (..)(....) /p(...).*
       FILE    -close /data/gempak/nexrad/NIDS/\1/\4/\4_(\2:yyyy)(\2:mm)\2_\3

To me this looked like you thought that the first parenthesized expression
should be the ID for the NEXRAD station; it isn't.  It is the ID for
the issuing center for the NEXRAD data.  The station ID is contained in
the PIL as the 4th-6th characters.  I took the liberty (shoot me if you
must) of changing your pqact.conf entry to look like:

NNEXRAD ^SDUS5. .... ([0-3][0-9])([0-2][0-9])([0-6][0-9]).*/p(...)(...)
        FILE    -close  

Notice that the 5th parenthesized expression is the 3-character station
ID and it is used in the way that you were using the 1st parenthesized
expression in your action.  (BTW, this is the action that Chiz setup
for GEMPAK use here and on motherlode (modulo the directory preamble)).

The result of using the three characters of the issuing center as the
station ID was that the ID portion of the filing hierarchy did not match
the station ID in the file.  This affects not only McIDAS, but GEMPAK
as well.

After making my change to pqact.conf (and ~ldm/etc/pqact/pqact.radar),
I HUPed the LDM and watched as NEXRAD products rolled in.  They
are now being filed correctly (at least to my way of thinking).  Also,
since the products were being filed incorrectly before, I took the
liberty of deleting all directories that were no longer getting updated
by the LDM's FILE action.  The reason for doing this was that those
that don't get updated reflect the fact that they represented instances
where the station IDs did not match the last three letters of
the issuing center.

Anyway, to make a long story shorter, the McIDAS remote ADDE server
is now able to list/display the images being ingested on papagayo,
and GEMPAK should work correctly also.

One last question, however.  You appear to be getting all of the N0R
products.  Is this what you intended?



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.