Data location: ~arsf/arsf_data/in_progress/2007/flight_data/ipy/IPY07_08-2007_214ef_Langjokull

Data arrived from ARSF via SATA disk transfer in August, with post-processed GPS arriving in December following Kidlington visit.

Scientific details: (details of IPY applications not currently available at PML)

PI: I Willis

Langjökull anglicises to Langjokull - use this for filenames just in case of problems.

Sensors:

• ATM (delivered 23/May/2008)
• CASI (delivered 6/May/2008)

Quicklook

CASI

ATM

Had a request for help from a user of existing CASI data (Jon Atherton) who was not an original PI but obtained some 2005 flight data from NEODC:

Hello,

I'm a complete novice at preprocessing CASI data. I have access to the NEODC online data sets, and I would like to use CASI data from Sitia, 2005 (http://neodc.nerc.ac.uk/cgi-infrastructure/data_browser/data_browser/neodc/arsf/2005/MC04_15).
I need about 15 bands worth centred at 685 nm (band 32 to 47) from images c130021b and c130041b.

Your colleague (Gary Llewellyn) kindly provided me with the FTP for AZGCORR. I had a go with the basic line of code (provided in the tutorial) which produced a blurred image on an angle, when compared with the three bands-worth of images already processed to level 3b which are available online. Any help on correcting the blurriness would be greatly appreciated.

The only code I used was (I don't have a DEM):

 "./azcor -bl 1 -1 -p 2.0 2.5 -1 c130021b.hdf -3 c130023a.hdf"


Best wishes,

Jon Atherton

PhD student
University of Edinburgh

Replied to the query (suggested he applied a correct projection, used square pixels and tried some different bands), which seems to have solved the problem.

What if any support level should we be providing to new users of existing data? On the one hand we don't want to leave ourselves open to potentially large open-ended support requests from non-PIs, on the other it's in our interests to have ARSF data as widely available and used as possible.

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.