[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010411: time issues in meteosat imagery (cont.)



>From: address@hidden (Chris Hennon)
>Organization: Ohio State University
>Keywords: 200104061848.f36ImGL26255 McIDAS METEOSAT time

Chris,

>A "file core" returns:
>
>core:           ELF 32-bit MSB core file SPARC Version 1, from 'aputserv'

OK, this is a good clue.

>The core file is a direct or indirect result of running the IMGCHA
>command.

Right.

>Let me know if you need anything.

I logged in and immediately verified everything that you reported earlier.
I then decided to take a look at the files in question, and the problem
struck me fairly quickly.

The dataset you have defined for the METEOSAT images is populated by images
of type AREA _but_ they do not use AREA naming conventions.  This means that
they are read only by the ADDE access routines (this is not obvious at all,
but it is true).  To verify that the IMGCHA command can work correctly
if the output naming is AREAnnnn, I did the following:

cd /home/chennon/data/meteosat7/active
ln Mcidas_1998-10-01_12_64622_1_1_1.IR AREA3000
cd ~mcidas/workdata
redirect.k ADD AREA3000 \"/home/chennon/data/meteosat7/active

Now, since you already have a dataset named MYDATA/IMAGES defined:

dsserve.k LIST MYDATA

Group/Descriptor         Type  Format & Range     RT Comment
------------------------ ----- ------------------ -- --------------------
MYDATA/GRIDS             GRID  GRID 1-9999           All gridded data in GRID fo
                                                     rmat
MYDATA/IMAGES            IMAGE AREA 1-9999           All images in AREA format
MYDATA/PTSRCS            POINT MD   1-9999           All point source data files
                                                      in MD file format
MYDATA/TEST-IMAGES       IMAGE AREA 4000-4004        Scratch areas for testing
MYDATA/TOPO              IMAGE AREA 9000-9019        All topographic images in A
                                                     REA format
dsserve.k: done

AND, since I added a REDIRECTion to AREA3000 so it could be found by McIDAS:

redirect.k ADD AREA3000 \"/home/chennon/data/meteosat7/active

I can list and change this image using the MYDATA/IMAGES dataset:

imglist.k MYDATA/IMAGES.3000
Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
3000  METEOSAT7     30 NOV 98334  24:00:00     0    0 8
imglist.k: done

imgcha.k MYDATA/IMAGES.3000 TIME=00:00:00

     Directory Block Changes
Changed Image Time from: 240000  to: 0

Transferring AREA data outbound, bytes= 416

Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
3000  METEOSAT7     30 NOV 98334  00:00:00     0    0
    Band: 8  11.5 um Nighttime cloud detection           5.0   5.0  2500 x 2500
     proj:    0 created: 2001067  95809  memo: METEOSAT
     type:MSAT     cal type:RAW
     offsets:  data=     768 navigation=  256 calibration=    0 auxillary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  1 avg-smp: A
     lcor:    1  ecor:     1  bytes per pixel: 1  ss: 58
     Image Center Point Res (derived)  Lat:   4.52 (km)  Lon:   4.49 (km)

IMGLIST: done

IMGCHA: Done ...

So, the problem is that with a generalized file naming scheme, McIDAS has
no direct way of figuring out the exact output file name for things like
IMGCOPY:  the DIRFILE= mask says include as part of the dataset everything
named Mcidas* in /home/chennon/data/meteosat7/active.  I'll grant you that
it could figure out which file represents a certain position of this
dataset IF the position number is within the bounds of the dataset, but
it would not have enough information to create a new file name for a position
number that was outside of the bounds of the dataset.  What I mean by this
can be illustrated as follows:

o if you do an imglist.k METSAT-7/IR.ALL, you will find that there are 242
  images in the set
o if you try to copy a new image to the dataset, say in position 243, there
  would not be enough information in the DIRFILE= mask to be able to specify
  the image uniquely

Does this make sense?

So, _unfortunately_, you will not be able to use IMGCHA to modify the
Mcidas* images in your dataset.  There are a couple of another ways, however:

First, you could link each file in the /home/chennon/data/meteosat7/active
to a unique AREA file name (say AREA3000 - AREA3241).  You would they use
your script that runs IMGCHA on the MYDATA/IMAGES dataset instead of on
the METSAT-7/IR dataset.  In order to accomplish this, you would need
to refine your REDIRECTion for AREA3*:

redirect.k ADD AREA3\* \"//home/chennon/data/meteosat7/active

Second, I setup a REDIRECTion for files named Mci* in the
/home/chennon/data/meteosat7/active directory:

redirect.k ADD Mci\* \"/home/chennon/data/meteosat7/active

Now, McIDAS can find these files:

dmap.k Mci
PERM      SIZE LAST CHANGED FILENAME                              DIRECTORY
---- --------- ------------ ------------------------------------- ---------
-rw-   6250768 Apr 11 19:52 Mcidas_1998-10-01_12_64622_1_1_1.IR   
/home/chennon/data/meteosat7/active
-rw-   6250768 Mar 27 12:02 Mcidas_1998-10-01_24_64622_1_1_2.IR   
/home/chennon/data/meteosat7/active

 ...

and look inside of any/all of them:

lwu.k LIST Mcidas_1998-10-01_12_64622_1_1_1.IR
       0.          0           4 HEX:        0        4 ASCII:
       2.         58       98274 HEX:       3A    17FE2 ASCII:    :   
       4.      60000           1 HEX:     EA60        1 ASCII:    `
       6.          1           1 HEX:        1        1 ASCII:
       8.       2500        2500 HEX:      9C4      9C4 ASCII:
      10.          1           2 HEX:        1        2 ASCII:
      12.          2           1 HEX:        2        1 ASCII:
      14.          0           0 HEX:        0        0 ASCII:
      16.     101066      160438 HEX:    18ACA    272B6 ASCII:        r
      18.        128           0 HEX:       80        0 ASCII:
      20.      54519       10377 HEX:     D4F7     2889 ASCII:        (
      22.         50           2 HEX:       32        2 ASCII:    2
      24. 1296389189  1330856276 HEX: 4D455445 4F534154 ASCII: METE OSAT
      26.          0           0 HEX:        0        0 ASCII:
      28.          0           0 HEX:        0        0 ASCII:
      30.          0           0 HEX:        0        0 ASCII:
      32.          0         768 HEX:        0      300 ASCII:
      34.        256           0 HEX:      100        0 ASCII:
      36.          0           0 HEX:        0        0 ASCII:
      38.          0           0 HEX:        0        0 ASCII:
 --END OF LISTING

(the default listing is for 40 words of the directory)

You can use lwu.k (LWU) to modify a file in McIDAS.  Let's choose an image
that has a time of 24:00:00:

lwu.k POKE Mcidas_1998-10-19_48_64622_1_1_76.IR 0 4
 Value was:       240000 HEX:        3A980 ASCII:

So, LWU can be used to change the values in the file directly if you can
figure out which files need to be changed.  This can be done with a Unix
shell script in combination with LWU.

I would try to generate such a script, but I have got to run right now.
Please let me know if you need some help.

Tom