20010828: McIDAS XCD decoders and WSI NIDS products (cont.)

>From: David Fitzgerald <address@hidden>
>Organization: Millersville University of Pennsylvania
>Keywords: 200108271943.f7RJhW128098 McIDAS-XCD rapid access

Dave,

Sorry that I couldn't get back to you yesterday, but I was in the final
stretch of selling my house (moving and then closing, phew!).

re: I ran smack dab into a brick wall
>Now you know haw I feel.

Yes, I could really relate to your frustration.

>My gempak decoders are working properly.  I am
>getting current data and can view it in garp and nmap just fine.

OK.

I just logged onto twister and took a look at XCD decoding of files for
the RTPTSRC and RTGRIDS datasets.  Apparently, things started working
correctly beginning for RTPTSRC files with 0Z today.  I have _NO_
explanation for this, but I am of the mind to not worry about it unless
the decoding goes south again.  The GRID decoding appeared to be
working correctly on Monday; sorry I didn't mention this.

One thing that I did do was comment out the scouring of the McIDAS data
files from ~ldm/etc/scour.conf.  This is not needed since your McIDAS
data is being scoured by the ldm-mcidas/bin/mcscour.sh invocation in
your LDM user's crontab file.

By the way, I get pretty good response from your ADDE remote server
for RTPTSRC, RTGRID, and RTIMAGES datasets.  Has your network bandwidth
increased recently, or are Millersville students not back yet (or
not bogging down the network with the demise of Napster)?

Please let me know if you see a reoccurrance of the decoding problems.
I will continue to peek at your data via ADDE from time-to-time from
here.

Also, I _think_ that I noticed you still converting WSI NIDS images into
McIDAS AREA files; I see lots of files with AREA numbers above 300.
If this really is the case, you can save a good bit of CPU by:

o not converting the imagery
o providing ADDE access to the raw files directly

If you are interested in pursuing this, please let me know and I can
help you set it up.  I would guess that you are already using the
filed NIDS products withing GEMPAK/GARP/NMAP.  McIDAS can use the same
hierarchical directory structure as GEMPAK and provide ADDE access
to those data.

One last thing.  If your network bandwidth has improved significantly,
would you consider joining the list of cooperating ADDE server sites?
What this would mean in practice is that you would allow McIDAS and
MetApps users to access data off or your ADDE remote server.  How much
this may be done is unknown, but I suspect that it would not be that
much.  The idea is for McIDAS sites to act as each other's realtime
data "archives".  If your feed was hosed for some reason but your
network connection was still OK, you could access someone else's data
holdings.  If they were in the same boat, they might come to you for
realtime data access.  Please give some thought to participating in
this endeavour and get back to me.

Tom