Custom Query (432 matches)
Results (367 - 369 of 432)
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. |
|||
#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. |