Detailed query from Luke Bateson regarding gappy/fuzzy Hawk images and projections. Main culprit seems to be that he's used a small pixel size (1-2m for a flight at ~6000ft), causing interpolation gaps. Fuzziness largely caused (I think) by the fact that he's used bands 5, 3, 2 for Hawk (close together, all at the SW end of the spectrum and at least one seems to have some bad pixels). Also some queries about projections and the geoid-spheroid file.

Responded with answers, though I've said we're trying to clarify the circumstances in which a geoid-spheroid file is needed.

Original email below, with various attachments.

Hi,
 
I recently received data from the ARSF for an area in Italy called Latera. This was flown on day 248 of 2007.
 
I have been familiarizing myself with azgcoor using the example azgcorr commands as given in the read_me.txt that was delivered with the data. The geocorrection is working but I have a few questions:
 
Missing data in output image:

   1. If I try to output an image with 1m pixels the result has a lot of data missing: see attachment (h2408013b_532_test_1mpix.jpg)
   2. If I do the same but with a 2m pixel output image the result is much better but there are still a few missing sections (h2408013b_532_2test.jpg)
   3. The command is based on the example given in the read_me file and uses the supplied SRTM dem. I receive a similar looking result if I use a lidar dem that I have for the area. The command used for the 1m pixel image is:

                     azgcorr -v -mTM 3 0 0 9 1 0 500000 -dNO -eh latera.dem -es sphseplx.grd -bl 5 3 2 -1 -p 1 1 -1 h248011b.hdf -3 h248013b_532test.hdf
 

    * This command is found under 'Third command' heading in the attached text doc. The result screen output can also be seen in the attached TXT document (hawk_geocorrection_v2.txt).
    * Is this missing data a function of me trying to get too small a pixel size or is there another reason?
    * What is the maximum pixel size I can expect with eh Hawk data? - I.e. what would be the maximum I can specify in this process?

The 'colour' and appearance of the image

   1. I notice on the supplied screenshot jpegs (with a 4 meter pixels sixe) (h248013b.jpg) that the image appears to be a much better quality than the images that I have produced. Has any other processing been applied these images before they were corrected (atm etc). I have not yet applied anything else and if so this could be a reason, if not then I presume something has not worked correctly in my processing?

Projections

   1. You will see from the script that I am using TM with a central meridian of 9 and a datum code of 3 (WGS84). Is this a valid way to get the data into an equivalent of UTM zone 32? I tried using the UTMZ commands but this caused a problem with the supplied SRTM DEM not enclosing the image and the -dNO argument did not work either.
   2. The lidar DEM that I am using is in UTM zone 32, I resume that this is ok to use with the -mTM argument as shown int eh above command.

Geoid-spheroid correction

   1. Does the file sphseplx.grd cover all possible geoids spheroid corrections or is it specific to this data?
   2. I presume that I need to use this file since I am projecting into UTM zone 32

Additional Information
 
Attached 'myhdffilelisting' has info for an example processed file with 2m pixels.
 
Processed on a new Linux PC with 222gb free disc space, 4GB ram, 2 Xeon 2GHZ processors.
 
The Linux install information is:
Linux kwx14868.ad.bgs.ac.uk 2.6.18-53.1.13.el5PAE #1 SMP Tue Feb 12 13:33:01 EST 2008 i686 i686 i386 GNU/Linux
 
 
Apologies for such a long email.
 
Thanks
 
Luke Bateson.

Ricardo contacted us yesterday with:

  Recently you offered your help with any general Eagle/Hawk/CASI/ATM processing issues and we would like to consult about our Eagle/Hawk data processed with azgcorr. As you maybe are aware, Doñana (SW Spain) was overflown March last year and we have been using azgcorr to produce Level 3 geocorrected data, and able to apply atmospheric corrections with the great help of Andrew Wilson from CEH. However, to manage the huge files of the geocorrected Level 3 data at full spatial and radiometric resolution is still a pain because of file size, specially in cases in which we have lots of ground-thruth positions in different flight-lines (our main EUFARNet aim and goal is to map 2 allien plant species).

   That is why we are also trying to obtain IGM files for ENVI (X and Y coordinate files that help in overlying ground-truth areas, more info at http://www.ittvis.com/services/techtip.asp?ttid=3816), and this is why we are testing
the possibility to do it with PARGE since AZGCORR has not this option (although the calculations must be embedded somewhere in the code, during the geocorrection process, as Andrew Wilson indicated). This might simplify the process of overlaying ground-truth on flight-lines before applying any geocorrection to the final product (mostly classification maps). Would it be possible to incorporate such an option on AZGCORR processing?

As this is not the only project in which we are working, and we are not experienced hyperspectral data users, it is taking us longer than we would have liked to analyse the data.

The IGM files appear to be ENVI's method for specifying per pixel coordinates. This is the same issue as #109.

Replying to Ricardo with the info we have on this, and the current tentative plan for this to be implemented pending availability of development time. Raising the importance of that issue too.

Data location: ~arsf/arsf_data/in_progress/2008/flight_data/arsf_internal_projects/boresight-2008_116/

Data arrived from ARSF via rsync transfer begun 28/April, completed 29th (~19hrs/15GB).

Scientific details: N/A

PI: ARSF

This boresight also includes a long line along a railway track, with wiggles, per action item in the recent meeting.

Sensors:

• ATM
• Eagle
• Hawk

Quicklook

TBD.