Opened 17 years ago

Closed 16 years ago

#129 closed support (fixed)

Support: 18/Apr/2008, Luke Bateson, BGS07/02

Reported by: benj Owned by: benj
Priority: alpha 4 high Milestone:
Component: Support Keywords:
Cc: mggr Other processors:

Description (last modified by mggr)

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.

Attachments (7)

h2408013b_532_test_1mpix.jpg (192.6 KB) - added by benj 17 years ago.
Attached with original email
h2408013b_532_2test.jpg (196.7 KB) - added by benj 17 years ago.
Attached with original email
hawk_geocorrection_v2.txt (13.0 KB) - added by benj 17 years ago.
Attached with original email
h248013b.jpg (369.5 KB) - added by benj 17 years ago.
Attached with original email
myhdffilelisting (3.8 KB) - added by benj 17 years ago.
Attached with original email
vent_locs_on_hawk.jpg (225.2 KB) - added by benj 16 years ago.
Location of vents being investigated
loc_uncorr_hawk.jpg (223.0 KB) - added by benj 16 years ago.
Location of vents on level 1 image

Download all attachments as: .zip

Change History (9)

Changed 17 years ago by benj

Attached with original email

Changed 17 years ago by benj

Attached with original email

Changed 17 years ago by benj

Attached with original email

Changed 17 years ago by benj

Attached with original email

Changed 17 years ago by benj

Attached with original email

comment:1 Changed 16 years ago by mggr

  • Description modified (diff)
  • Summary changed from Support: 18/Apr/2008, Luke Bateman, BGS07/02 to Support: 18/Apr/2008, Luke Bateson, BGS07/02

Oop, name typoed.

Changed 16 years ago by benj

Location of vents being investigated

Changed 16 years ago by benj

Location of vents on level 1 image

comment:2 Changed 16 years ago by benj

  • Resolution set to fixed
  • Status changed from new to closed

Had a look at vent areas (see attached images) to see if I could see anything (back in October), but had the same problem as Luke - I couldn't identify extra absorption due to excess CO2 over the vents. Either I was looking in the wrong places (the vents aren't easy to locate on the level 1), or I was doing something wrong, or the extra absorption signature isn't visible in our images. Haven't heard anything back from Luke since so I'm closing this.

Note: See TracTickets for help on using tickets.