Custom Query (432 matches)
Results (82 - 84 of 432)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #88 | fixed | Restricting level 1 processing by scan line causes error | mggr | anee |
| Description |
The use of -l in azspec produces a blank image if anything than a start line of 0 is used. The end line number does seem to produce the correct effect however. Same problem also occurs in azatm (causes errors saying "scan jump from: 0 to 191119 scan : 191119 rejected"). Same option in azcas2 seems to work correctly. |
|||
| #89 | fixed | BGS07/02, flight day 248/2007, Latera | mggr | mggr |
| Description |
Data location: ~arsf/arsf_data/in_progress/2007/flight_data/med/BGS07_02-2007_248_Latera Data arrived from ARSF via 2 day FTP download completing on 10 Jan 2008. Scientific details: Details of application not available at PML, but basically was to measure ground CO2 release by remote sensing. PI: Jonathan Pearce / Stuart Marsh / Luke Bateson @ BGS Sensors:
QuicklookTBD. |
|||
| #90 | fixed | Experiment with and compare processed LIDAR to NextMAP | benj | mggr |
| Description |
Have a look at the LIDAR point cloud available in ~arsf/arsf_data/in_progress/2007/flight_data/uk/GB2007_06-2007_192a_Dorchester (lidar/07*). Attempt to process it into a DEM and any necessary cleanup using GRASS (Environment Agency use GRASS too). Ask me to talk you through the data format (it has some weirdities) before you start. Compare against the existing NextMAP DEM (tiles sy69,sy78,sy79) to see how 'good' the result is. Document GRASS procedure on the wiki! (maybe http://www.npm.ac.uk/rsg/projects/arsf/trac/wiki/Processing/LIDARDEMs) |
|||