[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20051122: McIDAS ADDE access to NEXRCOMP imagery
- Subject: 20051122: McIDAS ADDE access to NEXRCOMP imagery
- Date: Tue, 22 Nov 2005 16:44:35 -0700
>From: "Happel, Shelly" <address@hidden>
>Organization: USF
>Keywords: 200511221843.jAMIhP7s009090 IDD FNEXRAD notifyme ADDE
Hi Shelly,
>Tee hee - I've attached all of my pqact entries...
OK.
>Hmmm, where to start..
>Looks like the pqact.gempak_nexrad is running - not the
>pqact.conf_nnexrad. This pqact.gempak_nexrad looks sparse - like it
>doesn't do any decoding (which the pqact_nnexrad obviously does).
OK.
>I did do the ADDE host thing and you were right - they were pointing at
>the old IP address, however our dataloc list shows atm.geo.nsf.gov as
>the ADDE server.
The ADDE server for GINIEAST and GINICOMP. Any others?
>Doing the dsserve.k GINIEAST - showed nada - nothing...I mean the table
>was there - but nothing filled it.
Yup. The ADDE dataset was never setup on metlab since you are not
ingesting the feed (NIMAGE) that contains these images. You were
always setup to access the images from a remote ADDE server (like
atm.geo.nsf.gov).
>I'm heading home now and probably won't get to this again until after
>the holiday, but again, Tom - thanks for helping me and looking at this.
>I value your time & energy spent keeping this USF ship afloat!
I logged onto metlab and took a quick look. Here are some observations:
- you are not ingesting the NIMAGE data so you are not receiving the
products needed for the GINIEAST, GINIWEST, GINICOMP, or RTGINI
datasets
- you were pointing at metlab for NEXRCOMP data, but you were not
processing the FNEXRAD images.
I edited ~ldm/etc/pqact.conf_nnexrad and commented out the
entry that files the NEXRAD Level III products (this is
already being done in the pqact.gempak_nexrad file)
- like you said, you were not running a pqact to proces the actions
in ~ldm/etc/pqact.conf_nnexrad.
I added an exec line in your ~ldm/etc/ldmd.conf file that runs
a separate invocation for pqact for FNEXRAD data specifying
the use of ~ldm/etc/pqact.conf_nnexrad. FNEXRAD composite images
are now being processed and are accessible in the 'mcidas'
account:
<as 'mcidas'>
cd ~/workdata
dataloc.k LIST NEXRCOMP
Group Name Server IP Address
-------------------- ----------------------------------------
NEXRCOMP METLAB.CAS.USF.EDU
<LOCAL-DATA> indicates that data will be accessed from the local data
directory.DATALOC -- done
The images are now available:
imglist.k NEXRCOMP/1KN0R-NAT
Image file directory listing for:NEXRCOMP/1KN0R-NAT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
5 RADAR 22 NOV 05326 23:12:00 TWX 27
imglist.k: done
imglist.k NEXRCOMP/1KN0R-FLT
Image file directory listing for:NEXRCOMP/1KN0R-FLT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
3 RADAR 22 NOV 05326 23:17:00 TRI 1
imglist.k: done
imglist.k NEXRCOMP/6KN0R-NAT
Image file directory listing for:NEXRCOMP/6KN0R-NAT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
3 RADAR 22 NOV 05326 23:19:00 TWX 1
imglist.k: done
imglist.k NEXRCOMP/10KRCM-NAT
Image file directory listing for:NEXRCOMP/10KRCM-NAT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
1 RADAR 22 NOV 05326 22:50:00 TWX 1
imglist.k: done
imglist.k NEXRCOMP/2KN1P-NAT
Image file directory listing for:NEXRCOMP/2KN1P-NAT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
3 RADAR 22 NOV 05326 23:15:00 TWX 30
imglist.k: done
imglist.k NEXRCOMP/4KNTP-NAT
Image file directory listing for:NEXRCOMP/4KNTP-NAT
Pos Satellite/ Date Time Center Band(s)
sensor Lat Lon
--- ------------- ------------ -------- ---- ---- ------------
3 RADAR 22 NOV 05326 23:15:00 TWX 31
imglist.k: done
Now, the question is if the processes being run out of your web
server cgi-bin script are using the setup from the 'mcidas' or
some other account. If they are using the 'mcidas' account, then
displays of NEXRCOMP composite radar images should now be working.
About the GINI satellite images. I noticed that you had
a client routing table entry for the RTGINI dataset, and the machine
being pointed to was pscwx.plymouth.edu. If your web server is
plotting images out of this dataset, then it is now wonder that
the displays were not working -- pscwx's ADDE server has been down
for several months now (but it is being reserructed). I changed
the pointing for RTGINI to adde.ucar.edu:
<as 'mcidas'>
cd ~/workdata
dataloc.k ADD RTGINI ADDE.UCAR.EDU
So, if your web server cgi-bin scripts were using RTGINI things should
be working now. (I suspect that this governed the displays through
your web site's Interactive satellite page.)
I note that the regional satellite displays still are not working. It
is likely that the web server is using configurations as a user other
than 'mcidas'. If this is the case, it could be that user is using
McIDAS client routing table in addition to (and superceding) 'mcidas'
(~mcidas/data/ADDESITE.TXT). The file to look for is named
MCTABLE.TXT, and it will be located in the directory indicated by the
MCTABLE_READ envrionment variable in scope for that user. I suspect
that user might be pointing to pscwx.plymouth.edu for GINIEAST
images, and the ADDE server on pscwx.plymouth.edu is down.
A couple of comments about the USF website:
1) your page:
http://www.weathercenter.usf.edu/sridhara/index.php
Has a link for "Real Time Lightning Display". Display
of NLDN lightning data outside of one's institution is
expressly prohibited. Under _no_ circumstances can
NLDN lightning data be displayed on a web page that is
not limited to one's own institution. If the USF
lightning display page is not protected from outside
access you MUST remove the link _now_! Making lightning
displays available through a web interface like you have
could result in the loss of NLDN data for the entire
Unidata community. This is a VERY serious issue, so
please take corrective actions ASAP. Thanks! (Sorry
to be a hard ass, but this is incredibly important!!)
2) the same page references "Meteograms". The proper term
is Meteorogram.
>Happy Thanksgiving xoxo
You too (although you might not read this until after
the holiday ;-).
Cheers,
Tom
--
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.