Custom Query (418 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (34 - 36 of 418)

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Ticket Resolution Summary Owner Reporter
#119 fixed Difference between Azspec and Caligeo processed Hawk data benj benj
Description

Split off from ticket #113.

Hawk data processed with Azspec and Caligeo shows a gap between the two, particularly at the short-wave end of the spectrum. Over land the two are very close at the longer-wave end, over water Caligeo is consistently higher than Azspec (though the gap is larger at the short-wave end). Azspec data looks more plausible but Hawk needs calibrating to check which (if either) is correct.

Over water: Azspec and Caligeo processed data over water

Over land: Azspec and caligeo processed data over land

#121 fixed Azatm -cuo option seemingly not working benj benj
Description

If you use the -cuo option in azatm to change the values it's supposed to set overflowed and underflowed pixels to, it doesn't seem to have an effect - always sets underflowed pixels to 0 (even if told to set them to ffff) and always says:

************* radcal underflow and overflow fill values changed ********
      under : 00000  = 0     over: 00000  = 0

...in azatm output, regardless of what values are entered for the under/overflow (tried with 0 fffe and ffff ffff).

Arose from testing on #115

#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.
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Note: See TracQuery for help on using queries.