20000308: Plymouth NOAAPORT receivers and GINI imagery (cont.)

>From: Jim Koermer <address@hidden>
>Organization: Unidata Program Center
>Keywords: Plymouth NOAAPORT GINI ADDE

Jim,

>The ADDE setup does work well! We've tried it out locally and it's a big
>plus and gives us another way to easily access data.

I think that ADDE is very nice.  I run Linux on a machine at home and
"drop in on" sites that are having data reception problems to check
their data holdings.  I will be asking sites actively running ADDE
remote servers to allow other Unidata ADDE sites to use them as 
"near time" data "archive" sites.  The best instance is the following:

o you have a course coming up in a half hour
o your net was down over night and you do not have upper air obs for
  this morning
o your lab is based on current upper air reports
o your net is up now
o you point McIDAS to a site that has gotten the data and away you go

>I'm looking at
>putting a "Make Your Own..." web page together to take advantage of the
>ADDE and make an easier interface for students to access the variety of
>satellite data available.

Cool.

>WXP is okay, but it does seem to have a few
>navigation problems with the composite images.

I have developed a relationship with the folks in NOAA that are producing
the GINI imagery (this happened at the Long Beach AMS conference).  So
far, problems in the GINI headers that I have reported have been quickly
rectified.  I offered those folks access to GINI imagery off of our
ADDE server so they could monitor the quality of the images, but they
have not taken me up on it so far.  You might think that them running
AWIPS would suffice, but it doesn't.  The AWIPS code has navigation
values hardwired into it.  The GINI header information is only read
to find out what sector it is; the navigation stuff is never looked
at.  I am lobbying for them to change this for the following reason.
If a new sector is ever to be added into NOAAPORT, they have to update
the software at each forecast office BEFORE the data can be used!  This
seems like a bad idea to me.

>I'm glad we can share the data.

Excellent.  I am sure that the community will really appreciate this.

>It actually looks quite efficient, since
>a remote user is not pulling down the entire, huge vis files, but only
>what is needed in the request. It's probably much better than pumping
>out all the raw sat files over the IDD.

Exactly.  And, if one really wants all of the data, s/he can get all
of the data.  The typical way that it is used, however, is to simply
look at the section of interest.  The volume of data that is transferred
then is only enough to fill the frame into which the image is being 
loaded.  This is typically something like 480x640, 600x800, or 768x1024.
On top of that, if one sets the MCCOMPRESS environment variable in
his/her environment (setenv MCCOMPRESS TRUE (actually the setenv MCCOMPRESS
is sufficient)), the data is compressed before the transfer and 
uncompressed on-the-fly on the client end.  If you did not set this for
your tests, do the following:

o if your McIDAS session is running, EXIT it
o set MCCOMPRESS in your environment (best done in .cshrc, etc.)
o start a new McIDAS session
o redo the test transfers

You can get an idea of the time savings by doing the test to our machine
here in Boulder.  First make sure that MCCOMPRESS is not set:

unsetenv McIDAS
mcidas

DATALOC ADD RTGINI ADDE.UNIDATA.UCAR.EDU
DSINFO IMAGE RTGINI
IMGDISP RTGINI/GE1KVIS STA=KBOS MAG=1 EU=IMAGE REFRESH='EG;MAP H'
EXIT

setenv MCCOMPRESS
mcidas

DATALOC ADD RTGINI ADDE.UNIDATA.UCAR.EDU
DSINFO IMAGE RTGINI
IMGDISP RTGINI/GE1KVIS STA=KBOS MAG=1 EU=IMAGE REFRESH='EG;MAP H'
DATALOC ADD RTGINI SNOW.PLYMOUTH.EDU

Pretty cool stuff, huh!?  And, ADDE can be used for all of the datasets
accessible to McIDAS.  This will be a big benefit for small institutions
that simply can not handle IDD data flow volumes.

Tom