Custom Query (432 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (49 - 51 of 432)

Ticket Resolution Summary Owner Reporter
#129 fixed Support: 18/Apr/2008, Luke Bateson, BGS07/02 benj benj
Description

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.
#74 fixed Support: 16/Oct/2007, Rachel Gaulton/Tim Malthus, GB06/05 benj mggr
Description

Rachel contacted us with a problem relating to radiometric calibration.

I'm not sure who specifically is the best person to ask about this,
but I am having some problems with the AISA Eagle data recently
delivered for my sites (Clocaenog and Glasfynydd, acquired July 06).
The radiance values differ considerably to those of the CASI and ATM
data acquired at the same time, specifically they are much lower
(about 1/2 to 2/3) in the Eagle data (see attached spectra of a paved
area in Glasfynydd for an example).  Following attempts at atmospheric
correction, this results in significantly lower reflectance than is
expected based on ground spectra.  I  may be missing something obvious
(e.g. different units), or is this down to errors in the radiometric
calibration of the Eagle sensor?
#38 fixed Support: 16/July/2007, Richard Teeuw (+Chris Hecker), WM mggr mggr
Description

Richard contacted Gary with a query regarding azgcorr versions (expired again). Noted website was out of date too.

Note: See TracQuery for help on using queries.