Opened 17 years ago
Last modified 16 years ago
#129 closed support
Support: 18/Apr/2008, Luke Bateman, BGS07/02 — at Initial Version
Reported by: | benj | Owned by: | benj |
---|---|---|---|
Priority: | alpha 4 high | Milestone: | |
Component: | Support | Keywords: | |
Cc: | mggr | Other processors: |
Description
Detailed query from Luke Bateman 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.
Note: See
TracTickets for help on using
tickets.
Attached with original email