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

20011025: GINI conversion to AREA (cont.)

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

Jason,

>  Just to clairfy, we're receving two different types of data:
>
>  1) McIDAS AREA files, with GVAR navigation, from the Storm Prediction
>     Center - they arrive in a satellite on the roof.  I'm trying to
>     find out their origination source
>  2) NOAAPort GINI data

It was clear to me that you were receiving the data in two different ways.
The only thing I was not clear on, and this doesn't matter anyway, is how
you are receiving the images from the Storm Prediction Center.

>We need to do one of three things:

>1) get the GINI data into the same 
>format (with GVAR navigation block) as the SPC files; probably won't work
>since GINI doesn't contain a GVAR block.

You _can_ do this if you follow the procedure I sent you earlier today.
You will have a hard time doing this from first principles, however.

>We found out this afternoon
>that GINI data is remapped into a Lambert Conformal grid.

I told Kevin that the GINI data is remapped GOES data in one of three
projections: Lambert Conformal Tangent Cone (TANC); Polar Stereographic
(PS); or Mercator (MERC).  Which production an image is in depends on
what area it covers.  For instance, images at low latitiudes (e.g.,
over Puerto Rico and Hawaii) are in MERC projections.  Images at mid
latitudes are in TANC; and images at high latitudes (like over Alaska)
are in PS.

2) Remap the
>data in the format like you suggest, though if the GVAR nav information
>changes on a scan-by-scan basis, then won't the data remap incorrectly
>(here, we're "faking" GINI data in the GVAR nav mode, right)?

Using the procedure I gave you will remap the GINI image - no matter
what its projection - into the navigation of the destination image.
The navigation in this case will be as good as the navigation of the
original destination image and input GINI image.  Given this, I would
_carefully_ select a GOES-East and GOES-West image to use as the remap
target.  The images should be selected such that the map registration
is as close as possible to being perfect.  By doing this, you would
cause most errors in the remap to be due to navigation quality in the
GINI images.

3) Read
>TANC information from the converted GINI file, and use that information
>to re-map.

This is what I call first principles.  If you go down this route, you
will have to be come familiar with the GINI format.  I would suggest
that since the work was already done in McIDAS, it would be time
better spent elsewhere.

>  Several problems: we try to read the TANC information, but all that 
>we find where the info is supposed to be is zeros.

This is because the GINI header format is radically different than that
in a McIDAS AREA file.

>The first solution
>won't work since the GINI data doesn't have the GVAR nav info
>(contains all types of things like pitch, roll, and yaw of the bird, etc.).

It is not true that the technique won't work.  I have just done a remap
from a GINI image into a GOES (GVAR) one and the results are of the remap
compare acceptably with the the image in the original GVAR format.

>"Forcing" the data into a GVAR nav info (which I have concerns about
>as voiced above) gives this error after the second step:
>
>
>>    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
>
>imgremap.k: The portion of the image requested does not exist
>imgremap.k: Failed to open source image for read

It would be helpful if you included the actual commands that you are
running.  Again, I just did the remap as I suggested and the results
were acceptable.

Try the following _exactly_ from a McIDAS session:

DATALOC ADD RTIMAGES ADDE.UCAR.EDU
DATALOC ADD GINIALL  ADDE.UCAR.EDU

EU REST IMAGE 1 3

SF 1
IMGDISP RTIMAGES/GE-IR 1 DAY=2001298 TIME=23:15 LATLON=40 90
MAP H GRA=1

IMGCOPY RTIMAGES/GE-IR MYDATA/IMAGES.2000 DAY=2001298 TIME=23:15 SIZE=ALL

SF 2
IMGDISP MYDATA/IMAGES.2000 2 LATLON=40 90
MAP H GRA=2

IMGREMAP GINIALL/GE4KIR MYDATA/IMAGES.2000 DAY=2001298 TIME=23:15

SF 3
IMGDISP MYDATA/IMAGES.2000 3 LATLON=40 90
MAP H GRA=3

SF 4
IMGDISP GINIALL/GE4KIR 4 DAY=2001298 TIME=23:15 MAG=-2 LATLON=40 90
MAP H GRA=4

LB 1 4
DR 4*20
TERM L ON

The image display in frames 1 and 2 will be identical since the copy
from the original image to the destination is identical.

The remap of GINI East 4 km IR data to the copy will show data missing at
the northwest side, but that is to be expected when you look at the
areal coverage of the GINI image in frame 4.

For simplicity, you could clip out the McIDAS commands above and put
them in a McIDAS BATCH file and run it with one command.  What I have
in mind is:

o cd to your McIDAS working directory.  If you are doing this as the user
  'mcidas', this would be ~mcidas/workata.  If you are doing this as
  any user other than 'mcidas', this would be your ~/mcidas/data directory.

o create a file called GINI2ARA.BAT.  The contents of this file will be
  the McIDAS commands above

o run the BATCH file from your McIDAS session:

  BATCH GINI2ARA.BAT


>  From what I can gather, the GINI data doesn't contain the required
>navigation information?

It does, but the format is completely different.  McIDAS takes care of
this for you.

>  It appears we may be stuck with having to write a completely new program
>to read in the GINI data and convert it to the ARPS grid, bypassing
>McIDAS.

I don't think so, but I will let you be the judge of that after you run
through the example above.

>The GINI data is re-mapped in Lambert Conformal,

Among other things.

>which is good
>news since our modeling system also uses that map projection.

So, you have some piece of code already that converts a GVAR navigated
image into "something" that is in Lambert Conformal projection?  Since
this is all going into a model, it would seem that you need a routine that
can turn image data into a grid in the projection that you want.  McIDAS
can do this also.

>  Sigh, you would think this could be easy :-)

I contend that it is if I am understanding what it is that you want to do.

>...thanks again for all of your help.

No problem.

>Any more thoughts?

Please work through the example I gave above and see if it doesn't do
what you originally asked for.  I put together that example in about
three minutes, so the procedure really is easy.

Tom