20010509: creating a mosaic in McIDAS (cont.)

>From: address@hidden (Chris Hennon)
>Organization: Ohio State
>Keywords: 200102121741.f1CHf4L28141 McIDAS mosaic IMGREMAP

Chris,

>I found the "problem".  I was remapping MYDATA/IMAGES.1234 into
>MYDATA/IMAGES.1235, which already existed.  Usually not an issue, but for
>some reason (permission problem with the data restoration?) my script
>didn't have write access to MYDATA/IMAGES.1235 as it had before.  My
>script appeared to be "working" because it went on and displayed 1235 -
>only problem was I was looking at an image created before the rebuild, not
>the one I thought I had just made.  So I deleted 1235 and reran the script
>to a successful conclusion.

OK.  The permissions after the restore are causing problems everywhere.

>I tried to run "make clobber" as user 'mcidas' but didn't get very far:
>
>twister:[/home/mcidas/mcidas7.7/src]% make clobber
>rm -f makelog
>*** Error code 2
>make: Fatal error: Command failed for target `clobber'

Sounds like a permission problem as well.  The 'clobber' target in the
makefile is well tested (I use it multiple times a week).

>I don't know why it wouldn't be able to run, since all of the files in
>there are writable by user 'mcidas'.  Luckily, this made me think about
>the solution above so a reinstall wasn't necessary, but I'm still curious.

What about the permissions on the directory?

>Finally, it turns out that EUMETSAT says an image with a date/time of Sept
>1, 24:00:00 UTC actually means Sept 2, 00:00:00 UTC.

I figured that would be the case.

>So not only do I
>have to change the time, but the day also.  Could you tell me which line
>from the LWU command corresponds to the day?  Do I have the ability to
>change it as I did with the time?

Reference, the Unidata McIDAS distribution has online help on the format
of AREA files.  You can get this help using HELP:

SEE area.doc       <- older GOES
SEE area2.doc      <- updated doc including GVAR
 
   WORD   NAME AND DESCRIPTION
   ----   ----------------------
     W1.  Contains zeros if the record is valid
     W2.  Area Format: always 4 (as of June, 1985).
     W3.  SSS:      Satellite Sensor Source; see Table 1
     W4.  YYDDD:    Nominal Year and Julian day of the data
     W5.  HHMMSS:   Nominal Time of the data
     W6.  UPPERLEFTLINE: Image line coordinate of area line 0, elem. 0
     W7.  UPPERLEFTELE: Image element coordinate of area line 0, elem.0
     W8.  Not used.
     W9.  NLINES:   Number of lines in this digital area
    W10.  NELES:    Number of elements in each line
    W11.  ELESIZ:   Number of bytes/element (1, 2 or 4)
    W12.  LINERES:  Line Resolution; spacing in image-lines between
                    consecutive area lines
    W13.  ELERES:   Element Resolution; spacing in image-elements
                    between consecutive area elements
    W14.  NCHANS:   Maximum number of bands/line of the area
    W15.  PRESIZ:   Length of the line prefix in bytes; indicated by the
                    sum of W49, W50, W51 (+ 4 if the validity code is
                    present; see W36)
    W16.  PROJ:     McIDAS user project number under which the area
                    was created
    W17.  CREATION DATE:   Area creation day in YYDDD format
    W18.  CREATION TIME:   Area creation time in HHMMSS format
    W19.  FILTER MAP: (for Multi-Channel Images) a 32 bit vector
                       If a bit=1, there is data for that band in the
                       area; the LSB (rightmost) is for band 1
 W20-24.  SSS specific
 W25-32.  Memo:     32 ASCII characters available for comments
    W33.  Area file number (xxxx from the file name)
    W34.  Byte offset to the start of the data within an area file
    W35.  Byte offset to the start of the navigation block within an
           area file
    W36.  Validity Code: If these bytes are nonzero, they represent a

                                                                   3


                          code which must match the first 4 bytes of
                          the line prefix; if the code and prefix bytes
                          are not equal, the line does not contain valid
                          data and applications must treat as missing.
 W37-48.  SSS specific
    W49.  Line prefix documentation section length in bytes
    W50.  Line prefix calibration section length in bytes
    W51.  Line prefix level map section length in bytes
    W52.  Image source type: 'VISR', 'VAS ', 'AAA ', 'ERBE', 'AVHR', ...
    W53.  Calibration Type: units in which the digital data is stored
                    (e.g. 'RAW ','TEMP','BRIT',...)
 W54-62.  Internal use only
    W63.  Byte offset to the start of the calibration block within
           the area file
    W64.  Number of card image comments (80 bytes each) appended to the
           end of the digital data.

From this list, we can see that the Nominal Yea and Juliand day of the data
is stored in word 4.  The documentation is a little misleading, however.
The format of the year and Julian day is:

YYYDDD
 ^  ^__ Julian day
 |_____ years since 1900 (1999 is 99; 2000 is 100; 2001 is 101; etc.)

So, you would change the Nominal date of the image with an LWU invocation
like:

lwu.k POKE AREA1234 100123 3

Three things to note:

o date is year 100 from 1900, or 2000
o 123 is the Julian day
o the indexing into the AREA directory used by LWU is zero-based

Also notice that the date is included in the AREA file header in another
location:

W17 - Creation Date -- also YYYDDD

>Have a great day!

Later...

Tom