20010218: McIDAS question about AREA and DIRFILE

>From: 10 <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 200102182128.f1ILSbL25380 McIDAS ADDE named datasets IMGCOPY

Robert,

>I know that 7.7 allows you not to be restrained to AREA files..

It is not constrained to AREA file naming convention for input.  It takes
a subserver to know how to read imagery in non-AREA file format.

>so I set up a data set as this
>
>TEST/IMAGE               IMAGE AREA                                           
>        
>                               DIRFILE=/export/home/weather/images/*

Hmm...  Since a name pattern was not supplied in the DIRFILE= keyword,
I was under the assumption that the file names should be named AREAnnnn.
I say this because of a comment that Dave Santek made at either the
last MUG meeting or the one before.  Closer examination and testing
shows this to not be true, however.

>I would like to do an imgcopy from another machine into this dataset,
>but when I try IMGCOPY BLA/BLAH TEST/IMAGE SIZE=ALL, I get an error
>IMGCOPY: MCAOUT rc= -1.  I gues this has to do with the fact that
>since there are no AREA #'s associated with TEST/IMAGES it doesn't
>know what to do.

Right.  It doesn't know how to name the output image.  There was just
some talk about this sort of thing in the MUG inquiry tracking system
(comments from Scott Linstrom).  I had thought about this before and
came to the conclusion that one would have to come up with a formalism
for specifying the naming convention before the output server would
have a chance at making up a reasonable name (in the same manner that I
created a formalism for the ldm-mcidas decoder, pnga2area).  I suppose
the output server could name the output file something off the wall and
(re)try to get a name that was not already in use, but this has not
been implemented.

>I knew what I tried would not work..but what
>do I need to get it to work since I can't specify anything
>other than group/descriptor.position for the dest. dataset?

Here are a couple of things that can work:

1) make the destination dataset conform to AREA file naming
   conventions

2) IF a valid AREA file exists in the directory specified by DIRFILE=
   and IF your DIRFILE= mask looks like

DSSERVE ADD TEST/IMAGES AREA DIRFILE=/home/mcidas/workata/AREA* "AREA form

   the the IMGCOPY:

IMGCOPY RTIMAGES/GE-IR TEST/IMAGES.1 SIZE=ALL

   will succeed.  The write is simply done over the existing AREA file.

The ability to describe how an output file is to be named is obviously an
area that needs work in McIDAS.  Any thoughts you might have on how
this can be done would be appreciated.

By the way.  Does NSBF or Universal Wx have/use any Linux boxes?  If so,
what OS are they using (version number)?  The reason I ask is that I
unearthed the inability of serving sounding data (thermodynamic diagrams,
UALISTs, and HODOs) through a remote ADDE server hosted on RedHat 6.x,7.x
Linux.  The process works in RedHat 5.2 and on other platforms where
the code is built using gcc/f2c (Solaris x86, FreeBSD, etc.).  I have
been struggling to pinpoint the source of failure for over a week now
and am making very little progress.  I am currently looking for sites
that might be running something like Debian or Slackware Linux to see
if the problem is in the RH distribution on in glibc 2.[12].  I have
been looking at this so hard for so long that my head hurts!

Tom