>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.