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

20030609: McIDAS XRD remap2

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20030609: McIDAS XRD remap2
  • Date: Mon, 09 Jun 2003 17:11:29 -0600
>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: Northrop Grumman Information Technology, TASC
>Keywords: 200306091217.h59CGxLd005776 McIDAS XRD remap2

Hi Mary Ellen,

I have a question at the very end of this email, so please hang in there
and read the entire message :-)

>       I have been able to compile both SSEC McIDAS XRD and Unidata XRD
>successfully on our Linux box which is running Unidata McIDAS-X 2002b.

Very good.

>However, when I execute remap2.k from either version, I get the following
>error:
>       "REMAP2: Warning - GVAR data"
>       "REMAP2: You may have to change the SS number in the destination
>file to match the source file"

This is just a warning.

>I'm not sure what the "SS number" is that I would have to change.

I see from your second message that you found out that SS refers to 
Sensor Source.

>I created
>my destination file by running the IMGCOPY command with FORM=RECT. Can you
>provide any info?

I think you mean you used IMGREMAP with the PRO=RECT.  IMGCOPY can not
do remapping.

>From address@hidden Mon Jun  9 15:23:11 2003
>
>Hi,
>       I got remap2 to run...but not completely. The SS number (sensor
>source) is the same so I'm not sure why I was getting an error message but
>the remapped image was being created.

The remap2 message was a warning not an error wasn't it, so the remapping
should have proceeded.

>However, there seems to be a limit on
>the size of the destination file I can create. My goal is to remap a
>5-banded GOES East image over all of CONUS.  In order for remap2 to work, I
>first had to IMGREMAP a GOES East image (only one band) with PRO=RECT so
>that my remapped image would have the correct projection. 
>IMGREMAP GE/RAW.215 TEST/MEL.1 BAND=4 PRO=RECT STA=KDDC SIZE=3000 6000

You should be aware that your output image will only be 1-byte data.
IMGREMAP will convert the two byte input data into 1-byte output data
unless you are remapping into an existing image that has two bytes per
pixel.  This seems to be contradictory to your objective of using
remap2 which saves the number of bytes per pixel, but, then again,
remap2 may only need to use the nav info (I don't know).

>When I run remap2 for BANDS=1 2 3 4 6, I get an error message that my
>Destination AREA is too large. However, if I run remap2 for BANDS=1 2 only
>then it is successful. 
>REMAP2 1214 7000 BAND=1 2  vs  REMAP2 1214 7000 BAND=1 2 3 4 6
>
>Any thoughts?

I created an image from a GOES-East CONUS multibanded image in the same
way as you did above:

IMGLIST EAST/CONUS.7320 FORM=EXP
Image file directory listing for:EAST/CONUS
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
7320  G-12 IMG       9 JUN 03160  21:40:00    32   87
    Band: 1   0.65 um Visible - Cloud Cover             1.32  0.61  3460 x 8504
    Band: 2   3.9 um Night clouds; shortwave window     5.29  2.44   865 x 2126
    Band: 3   6.5 um Upper level water vapor            5.29  2.44   865 x 2126
    Band: 4  10.7 um Surface temp; longwave window      5.29  2.44   865 x 2126
    Band: 6  13.3 um CO2; cloud height determination    5.29  2.44   865 x 2126
     proj:    0 created: 2003160 214013  memo: RT GVAR
     type:GVAR     cal type:RAW
     offsets:  data=    3328 navigation=  256 calibration= 2816 auxiliary=    0
     doc length: 228   cal length:   0   lev length:   0 PREFIX= 232
     valcod:  160214000 zcor:  0 avg-smp: N
     start yyddd: 2003160  start time:214013  start scan:  360
     lcor: 2877  ecor:  9277  bytes per pixel: 2  ss: 78
     Resolution Factors (base=1):   Line=    4.0   Element=    4.0
IMGLIST: done

IMGREMAP EAST/CONUS.7320 MYDATA/IMAGES.1234 BAND=4 PRO=RECT STA=KDDC SIZE=3000 
6000
Beginning Image Data transfer, bytes= 891028
IMGREMAP: transformations complete ... begin data move
Transferring AREA data outbound, bytes= 18000928
IMGREMAP: Done...

IMGLIST MYDATA/IMAGES.1234 FORM=EXP
Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
1234  G-12 IMG       9 JUN 03160  21:40:00    38  100
    Band: 4  10.7 um Surface temp; longwave window      1.00  0.79  3000 x 6000
     proj:    0 created: 2003160 215542  memo: RT GVAR
     type:VISR     cal type:BRIT
     offsets:  data=     768 navigation=  256 calibration=    0 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2003160  start time:214013  start scan:  360
     lcor: 8501  ecor:  7001  bytes per pixel: 1  ss: 78
     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
IMGLIST: done


A couple of things to note here are:

- the output remapped image only has 1 byte per pixel
- the output image that contains only one band is big, 18000928 bytes

So, if each band needed 18 MB of disk, you would need 90 MB total
space.  Given that full disk GOES scans are something like 300 MB
in size, I would not have expected that the eventual output file
would be too big.  Perhaps the size limit is one in remap2.pgm
itself?

I tried then running remap2 like your example:

REMAP2 1233 1234 10 BAND=1 2
REMAP - TRANFORMATIONS COMPLETE..BEGIN DATA MOVE
REMAP2: Warning - GVAR data
REMAP2: You may have to change the SS number
REMAP2: in the destination file to match the
REMAP2: source file

IMGLIST MYDATA/IMAGES.1234 FORM=EXP
Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
1234  G-12 IMG       9 JUN 03160  21:40:00    38  100
    Band: 1   0.65 um Visible - Cloud Cover             1.00  0.79  3000 x 6000
    Band: 2   3.9 um Night clouds; shortwave window     1.00  0.79  3000 x 6000
     proj:    0 created: 2003160 215542  memo: RT GVAR
     type:GVAR     cal type:RAW
     offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   4 PREFIX=   4
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2003160  start time:214013  start scan:  360
     lcor: 8501  ecor:  7001  bytes per pixel: 2  ss: 78
     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
IMGLIST: done
 
DMAP AREA1234
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw-  72013600 Jun 09 17:05 AREA1234 /home/mcidas/workdata
72013600 bytes in 1 files
 
REMAP2 1233 1234 10 BAND=1 2 3
REMAP - TRANFORMATIONS COMPLETE..BEGIN DATA MOVE
REMAP2: Warning - GVAR data
REMAP2: You may have to change the SS number
REMAP2: in the destination file to match the
REMAP2: source file
--REMAP DONE
 
DMAP AREA1234
PERM      SIZE LAST CHANGED FILENAME DIRECTORY
---- --------- ------------ -------- ---------
-rw- 108013680 Jun 09 17:06 AREA1234 /home/mcidas/workdata
108013680 bytes in 1 files
 
IMGLIST MYDATA/IMAGES.1234 FORM=EXP
Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
1234  G-12 IMG       9 JUN 03160  21:40:00    38  100
    Band: 1   0.65 um Visible - Cloud Cover             1.00  0.79  3000 x 6000
    Band: 2   3.9 um Night clouds; shortwave window     1.00  0.79  3000 x 6000
    Band: 3   6.5 um Upper level water vapor            1.00  0.79  3000 x 6000
     proj:    0 created: 2003160 215542  memo: RT GVAR
     type:GVAR     cal type:RAW
     offsets:  data=    1280 navigation=  256 calibration=  768 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   4 PREFIX=   4
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2003160  start time:214013  start scan:  360
     lcor: 8501  ecor:  7001  bytes per pixel: 2  ss: 78
     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
IMGLIST: done
 
REMAP2 1233 1234 10 BAND=1 2 3 4
REMAP - TRANFORMATIONS COMPLETE..BEGIN DATA MOVE
REMAP2: Warning - GVAR data
REMAP2: You may have to change the SS number
REMAP2: in the destination file to match the
REMAP2: source file
Program terminated, segmentation violation
REMAP2 failed, RC=1


So, my conclusion is that a buffer in remap2 is being overrun and
causing problems: core dump on my Solaris SPARC system, and a too large
size error on your Linux system.

The problems may all relate back to the compilers used to build
remap2.  I am using gcc/g77, what are you using?

Tom