Custom Query (419 matches)
Results (52 - 54 of 419)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#2 | fixed | Support: 15/May/2007, Rachel Gaulton, GB06/05 | mggr | mggr |
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)? |
|||
#27 | fixed | Support: 15/May/2007, Karl Hennermann, ? | mggr | mggr |
Description |
Karl called Steve and said he has an expired azgcorr (v4.5.9). Contacting to send him an update. |
|||
#166 | fixed | Support: 13/Jun/08, John Stevenson, IPY07/02, Lidar interpolation issue | benj | benj |
Description |
Query relating to Thingvallavatn (#98) lidar data - overlapping flight lines in opposite directions causing interpolation artefacts (see attached image). We believe these are caused by the lidar being aimed down a steep slope flying one way and up it flying the other coupled to a slight boresight offset, causing a difference in exactly where it hits the slope in each case being calculated as the same location (hence why it only happens on steep slopes, and only on slopes that are either roughly parallel to or perpendicular to the plane, depending on which boresight angle is off). Suggested solution is to average the lines using r.mapcalc in Grass prior to interpolation of null areas. If the slope is of a fairly constant gradient and the problem is caused by the above, this should hopefully produce reasonable results. Also asked Gabriel Amable at ULM for any suggestions. Given example data in ~arsf/support/20080813-JohnStevenson Original email as below: Hi, I am working on the 203_Thingvallavatn dataset. I am processing the LiDAR to generate a 1 m DEM. I have combined the xyz points from each of the .all files into one big file for processing. When the data are plotted (via nearneigbor and grdview in GMT, or via v.in.ascii and v.surf.rst in GRASS, or r.in.xyz and r.resamp.rst in GRASS), I find that some areas contain ESE-trending stripes. These have a spacing of 3-5 m and an amplitude of a few 10s of centimetres. The lines are perpendicular to the flightlines and I imagine that they are due to disagreement between data of different flights. How do you recommend that I treat the data to remove these? The stripes are only present on steeper slopes with a NNW to ENE aspect, so I am currently applying a filter to these areas (with the smooth=map parameter in r.resamp.rst). Do you have any other suggestions? I have attached some sample data points and a plot of the problem. Thanks, John |