Custom Query (432 matches)
Results (115 - 117 of 432)
Ticket |
---|
#542 |
Description |
Data location: /users/rsg/arsf/arsf_data/2014/flight_data/malaysia/MA14_16-2014_241_Sarajavo Data arrived from ARSF via network transfer on 19/12/2014 MA14/16 Scientific objective: Unknown MA14/16 Priority: a4m PI: Andy Ford Notes: No RCD data Large difference between fps_set and fps_qpf Sensors:Fenix (Requested) LiDAR (Requested) RCD (Requested) FW LiDAR (Requested) |
#2 |
Description |
Two issues:
Rachel's initial contact email: I am trying to process ATM and CASI data flown last summer over my two sites in Wales (GB06/05, PI - Tim Malthus). Unfortunately we are having a few problems with AZGCORR and I wanted to check whether you had encountered them before and had any idea what might be wrong (or who else might have). As we are carrying out atmospheric correction before geometrically correcting the swaths in AZGCORR, so we are using the resulting .bsq image in conjunction with the original .hdf (and a DTM) as inputs to AZGCORR, as recommended in the user guide. With the CASI data and most of the ATM swaths this appears to work ok (at least as far as can be determined by visual inspection of the results), however with certain swaths the geometric correction is not successful. These seem to be swaths with considerable numbers of missing pixels / scan lines. When the raw .hdf data is geometrically corrected directly, the problems do not appear and AZGCORR works correctly (attached jpeg1), but when the image is first converted to .bsq and atmospherically corrected the image seems to be corrected up until the point of the missing scan lines, but after that appears to be just 'stretched' to fit the correct outline (jpeg2). The same problem is also being encountered by John Dowens in correcting strips from GB06/07. Do you have any ideas what may be causing this problem? Any suggestions very much appreciated. I was also wondering if you know when I might be likely to receive the remaining LIDAR data from this acquisition (I have the lidar from my Glasfynydd site but not from Clocaenog)? |
#11 |
Description |
Just a tracker ticket for an issue found in #2. azgcorr wasn't handling the SCbedit vector correctly when BSEQ/BIL files were used. Reported to Bill 18/May and fixed over the weekend in release 106. Some notes from Bill's email: Updated azgcorr.481 by separate email. SCbedit now works as advertised with the limitation that it only works for the first 16 bands of a data set (because it uses an unsigned int). It was originally only put in for the ATM anyway. The "distortion" was because I had forgotten for BIL/BSEQ input to move the file when a line was skipped, so after each skipped line the image would shuffle up. So now for CASI and Specim data the only option is the whole frame is skipped if it is flagged. This makes sense because with a CCD sensor it would be pretty unlikely to have a whole row dead, columns maybe but not rows. The default in azgcorr.48* is if there is NO -be the SCbedit vector is used; if there is a -be then SCbedit is not used and no lines/scans are ignored. This needs testing |
Note: See TracQuery
for help on using queries.