[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030609: McIDAS XRD remap2
- 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