20011025: GINI conversion to AREA (cont.)

>From: "Jason J. Levit" <address@hidden>
>Organization: Center for Analysis and Prediction of Storms, University of Okla
homa
>Keywords: 200110222135.f9MLZn102781 McIDAS-X ADDE GINI AREA

Jason,

>Yesterday, in my discussions with Kevin, he mentioned that there is a
>way to re-map the converted GINI data in TANC format into a image with
>the GVAR projection (however, as you mentioned, this is the second
>remapping of the data).

Yes.  McIDAS has a command, IMGREMAP, that allows one to remap into several
projections as well as into a file that has its own projection (like GVAR).

>However, the data we receive via the Storm
>Prediction Center has as it's map projection "GVAR".

So, this data is probably not remapped.

>So, I'm wondering
>if the McIDAS data we're receiving is already re-mapped a second time? 

The "McIDAS" data you are receiving?  Do you mean the NOAAPORT GINI
data (which is not in McIDAS format), or are you referring to the imagery
that is included in the Unidata-Wisconsin datastream (which all Unidata
participants are entitled to get)?

>I'm looking into this now via e-mails.
>
>  When I use IMGLIST to look at the formats of the data, here's what I
>notice:
>
>#1) Data we receive from the Storm Prediction Center:
> Pos Satellite/         Date       Time      Center      Res (km)  
>Image_Size
>     sensor                                 Lat  Lon    Lat   Lon
> --- -------------  ------------  --------  ---- ----  ----- -----
>------------
>   1  G-8 IMG       25 OCT 01298  17:02:00    36   96
>    Band: 1   0.65 um Visible - Cloud Cover              1.0   2.0  2800
>x 4200
>     proj:    0 created: 2001298 171330  memo: RT GVAR
>     type:VISR     cal type:BRIT
>     offsets:  data=    2816 navigation=  256 calibration=    0
>auxillary=    0
>     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
>     valcod:          0 zcor:  0 avg-smp: N
>     start yyddd: 2001298  start time:170142  start scan:  372
>     lcor: 3060  ecor:  8061  bytes per pixel: 1  ss: 70
>     Image Center Point Res (derived)  Lat:   1.47 (km)  Lon:   1.33
>(km)

OK.  We can see that this data is already converted from RAW to VISR
(2-byte to 1-byte).

>#2) Converted GINI data (from GINI to VISR/BRIT):
> Pos Satellite/         Date       Time      Center      Res (km)  
>Image_Size
>     sensor                                 Lat  Lon    Lat   Lon
> --- -------------  ------------  --------  ---- ----  ----- -----
>------------
>   1  G-8 IMG       25 OCT 01298  16:45:00    41   88
>    Band: 1   0.65 um Visible - Cloud Cover              1.0   1.0  5120
>x 5120
>     proj:    0 created: 2001298 194011  memo: GINI:: Sat 11  SecID  1 
>ChID  1
>     type:VISR     cal type:BRIT
>     offsets:  data=     768 navigation=  256 calibration=    0
>auxillary=    0
>     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
>     valcod:          0 zcor:  0 avg-smp: N
>     start yyddd: 2001298  start time:164500  start scan:    0
>     lcor:    1  ecor:     1  bytes per pixel: 1  ss: 70
>     Image Center Point Res (derived)  Lat:   0.98 (km)  Lon:   0.98
>(km)

Instead of saying "Converted GINI", I would say GINI since all NOAAPORT
GINI data has been remapped into projections that match grid
projections in the NOAAPORT datastream.  This was done by the NWS so
that AWIPS workstations could overlay satellite images without having
to do any navigation transforms (so the displays are fast).

>The resolution of the two images is different, yet they are both
>VISR/BRIT data from GOES-08.

They are both VISR (meaning data values range from 0 to 255) and they are
both originally from GOES, yes.

>I'm guessing the first data has been remapped a second time?

No, I would not say that.  I would say that the first image has been
created from a GVAR RAW image by:

o blowing down in the element dimension (original GVAR images are over
  sampled in the element dimension by a factor of 1.7)

o turning RAW counts into BRIT values by scaling the 10 bit data to
  8 bits

Neither of these conversions reflects a remapping.

>Maybe I should try the remapping and see if this creates a similar data
>set.  How would I use IMGREMAP to try this?  Again, thanks for your
>help.

Here is a way to remap the GINI data into the GOES projection of the
Storm Prediction Center images you have.

1) make a copy of a GOES image that is appropriate to the GINI image
   that you are going to want to remap (i.e., a GOES-8 image for
   the GOES-8 GINI image and a GOES-10 image for the GOES-10 GINI image):

   Since I don't know the dataset name you use for images you get
   from the Storm Prediction Center, I will use 'STORM/GOES08VIS' for
   GOES-8 VIS images.  I will also assume that you have defined the
   MYDATA/IMAGES dataset (if you havn't, simply run 'BATCH MYDATA.BAT'
   from your McIDAS session):

   IMGCOPY STORM/GOES08VIS MYDATA/IMAGES.2000 SIZE=ALL

2) remap your latest GINI GOES-8 VIS image into this copy:

   IMGREMAP GINICAPS/GOES08VIS MYDATA/IMAGES.2000

3) since IMGREMAP does not transfer several pieces of information
   from the original image to the remapped one, you will have to
   use IMGLIST on the original to discern the information and IMGCHA
   on the remapped one to change those values:

   IMGLIST STORM/GOES08VIS FORM=EXP

   Now change the DAY, TIME, and BAND in the remapped image:

   IMGCHA MYDATA/IMAGES.2000 BAND=<band#> DAY=<day> TIME=<time>

   Here <band#> is the band number you got from the IMGLIST; <day>
   is the DAY you got from the IMGLIST, and <time> is the TIME
   you got from the IMGLIST.

After doing the above, the image in MYDATA/IMAGES.2000 will be the
remapped copy of the original GINICAPS/GOES08VIS image.  You can
further refine the IMGCOPY and IMGREMAP commands above to do things
like copy a particular image (specify DAY= and TIME= keywords to
specify which image to copy/remap).

Please let me know if the above is not clear enough.

Tom