[McIDAS #GMM-549214]: Displaying NIMAGE data in IDV/McIDAS

Hi Kevin,

re:
> Many thanks for the clarifications . . .

No worries.

> let me spend a little time
> getting familiar with "all things ADDE".  If my brain refuses to go along,
> I'll get back to you!

OK, sounds good.

In the meantime, you can see how the IDV works in accessing NIMAGE data
from remote ADDE servers.  Some McIDAS v2007 installations that have been
very recently setup and are currently making data publicaly accessible via
ADDE are:

adde.cise-nsf.gov        <- NSF/ATM (operated by Unidata)
idd.unl.edu              <- University of Nebraska-Lincoln
stratus.al.noaa.gov      <- CU/CIRES/NOAA
weather2.admin.niu.edu   <- Northern Illinois University
weather3.admin.niu.edu   <- Northern Illinois University
livos.evsc.virginia.edu  <- UVa

The datasets containing NIMAGE GINI imagery use the standardized set of ADDE
group names:

GINICOMP   <- NOAAPORT composite images in GINI format
GINIEAST   <- NOAAPORT GOES-East image sectors in GINI format
GINIWEST   <- NOAAPORT GOES-West image sectors in GINI format

All of these machines also serve imagery in compressed GINI format in the
NEXRCOMP dataset (images from the IDD FNEXRAD datasetream).

NOTEs:

- it is possible that the UVa machine, livos, will not stay open; I am in
  discussions with Jennie Moody about this

- of the machines listed above, stratus.al.noaa.gov is probably the fastest.
  It is running Solaris 10 x86_64 and is basically dedicated to serving
  data ingested in the IDD via ADDE

- all machines also serve images in the RTIMAGES, CIMSS, and RTNEXRAD datasets

One last comment for the McIDAS neophyte:

My observation is that new/novice McIDAS users have a difficult time "getting
their heads around" the client-server nature of McIDAS.  Clients access data
through server transactions.  The server can be:

- run locally in the user's McIDAS session
- accessible in another account on the same machine
- accessible on another machine in the same lab
- accessible on another machine that is accessible via TCP Ethernet

The nice thing about access using ADDE is its transparency.  Quite frankly, it
is easy to forget where data is being accessed from.  There have been several
instances over the years where a site has setup data ingestion through the
IDD; processing of the data using various decoders (e.g., ldm-mcidas and
McIDAS-XCD); serving of the data via ADDE; and then for some reason "point"
to a server other than their own for data access.  The user then forgets where
s/he is getting data _until_ there is some problem like the remote
ADDE server is not accessible for some reason (network outage, etc.).  S/he
then reviews her/his setup and sees that data is being ingested and processed
correctly.  We invariably get an email that says something like I can not
understand why ADDE no longer works on my machine... everything looks like
it should be working correctly.  This kind of situation attests to how
transparent the data access using ADDE.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: GMM-549214
Department: Support McIDAS
Priority: Normal
Status: Closed