Opened 6 years ago

Last modified 2 years ago

#557 closed flight processing

MA14/21, flight day 283/2014, Danum Valley — at Version 27

Reported by: dap Owned by:
Priority: whenever Milestone: 2014 data processing completion
Component: Processing: general Keywords:
Cc: Other processors:

Description (last modified by dac)

Data location: /users/rsg/arsf/arsf_data/2014/flight_data/malaysia/MA14_21-2014_283_Danum_Valley

Data arrived from ARSF via network transfer on 19/12/2014.

Scientific objective: Quantifying the accuracy of current estimates of forest biomass by combining data retrieved from state-of-the-art ground-based laser scanner with airborne data.

Priority: ?

PI: Mathias Disney

Delivery requested via FTP / Hard Disk

Note that this project directory contains the LiDAR and navigation data collected from the aborted flight 283a as well as the LiDAR and navigation data collected from flight 283b. The data relevant for this project are the ones collected in flight 283b. See the logsheet for more details.

Sensors:

  • Fenix (Requested)
  • Leica LIDAR (Requested)
  • Leica LiDAR FW (?)
  • RCD (Not Requested, flown anyway)

Change History (27)

comment:1 Changed 5 years ago by tec

Navigation Processing
Antenna height 1.40m
Lat 4 57 48.36552
Lon 117 48 10.32636
Ell 209.225

Last edited 5 years ago by tec (previous) (diff)

comment:2 Changed 5 years ago by tec

Nav done, processed in ipas pro, all defaults seemed fine though it wouldn't finish processing in ipas tc for some reason.

comment:3 Changed 5 years ago by tec

Fenix Processing
Starting, stuck on error TreeGridSize, waiting on mark1

comment:4 Changed 5 years ago by tec

RCD Processing
Started converting tiffs

comment:5 Changed 5 years ago by lah

Lidar Processing
First 4 lines don't process because they don't have corresponding nav data. Logsheet mentions that there was a problem and that these lines were reflown, so these probably don't need to be processed. Line 5 looks to have been aborted and is not worth processing (only 5MB compared to 200-250 MB for the other lines).

comment:6 Changed 5 years ago by lah

Lidar Processing
Only tree canopies to check roll and pitch offsets, but boresight values seem fine (r: -0.006375, p: 0.00016318)

comment:7 Changed 5 years ago by tec

RCD Processing
Removing images 008 011 012 013 014 021 022 026 027 029 036 037 038 039 040 041 042 044.

comment:8 Changed 5 years ago by lah

Logsheet
Generated logsheet, but align in and out are before and after takeoff, so transit time is invalid.

comment:9 Changed 5 years ago by tec

RCD Processing
Finished

comment:10 Changed 5 years ago by lah

Lidar delivery created, ready for checking.

comment:11 Changed 5 years ago by tec

LiDAR DC
Started

comment:12 Changed 5 years ago by tec

LiDAR DC
Dem looks wrong, all lines are black and also looks far too big. Have asked Dac's opinion.
Demcompare gives 165, not good :'(
Pitch and roll look good.
Sol file was incorrectly named. -fixed
AGC is only in fw but that's acceptable, though ideally should be in both.

Other than the dem project is fine.

comment:13 Changed 5 years ago by dac

When comparing the lidar DSM to ASTER the elevation values are too low, some areas I looked at were ~ 200 m lower, demcompare results reported by tec confirms this. Also checked against 3 arcsec SRTM, values are ~ 20 m different to ASTER but still a lot higher than lidar DSM.

Insufficient features to check horizontal accuracy (which could be the reason for the vertical offset) - suggest comparing to hyperspectral once processed.

comment:14 Changed 5 years ago by lah

Lidar

Checked alspp settings and it appears that files might have been processed with horizontal datum ETRF89. Reprocessing with WGS84 to see if this solves the problem.

comment:15 Changed 5 years ago by tec

Fenix
Line 8 doesnt line up at the end of the road, its most odd but I minimised the wobbles so dont think this is an sct problem.

comment:16 Changed 5 years ago by lah

Lidar
Alas, reprocessed files dem has same problem. Lines appear identical to previous delivery, so they were probably processed in WGS84.

comment:17 Changed 5 years ago by dac

RCD DC

Starting delivery check

comment:18 follow-up: Changed 5 years ago by dac

RCD DC
Looks good, couple of minor comments on the readme but other than that ready to deliver:

  • Might want to mention that images weren't included for all lines (if normally do this)
  • In the readme there is 'Some images contain cloud, they have been included as the images still contain useable data.' However, all the images look cloud free. There are some cloud shadows, so I would change to mention this.
Last edited 5 years ago by dac (previous) (diff)

comment:19 Changed 5 years ago by lah

Lidar
Checked overlapping flight lines with 243b and the vertical offset is definitely in the flight lines (165m). Horizontal position matches 243b though. Could just put vertical offset into alspp, but doesn't explain why the offset is there.

comment:20 in reply to: ↑ 18 Changed 5 years ago by tec

Replying to dac:

RCD DC
Looks good, couple of minor comments on the readme but other than that ready to deliver:

  • Might want to mention that images weren't included for all lines (if normally do this)
  • In the readme there is 'Some images contain cloud, they have been included as the images still contain useable data.' However, all the images look cloud free. There are some cloud shadows, so I would change to mention this.

Done, marking as ready to deliver

comment:21 Changed 5 years ago by tec

Fenix

Flightline FENIX
6 0.98
7 1.10
8 0.97
9 0.90
10 0.97
11 -0.22
12 0.90
13 0.99

comment:22 Changed 5 years ago by tec

Fenix
Ready for delivery check

comment:23 Changed 5 years ago by dac

Fenix DC

Starting delivery check

comment:24 follow-up: Changed 5 years ago by dac

Fenix DC

Delivery looks fine. However, the files look a bit weird. There is a bright / dark (depending on wavelength) strip down the centre of every line starting from band ~ 240 until the last band. This is present in the 1b and mapped data. It would be good to try and figure out what is causing this and mention in the readme.

Couple of comments.

  • Empty fodis directory - removed
  • There are two DEMs, one of which looks filtered. Remove the one which isn't required.

comment:25 in reply to: ↑ 24 Changed 5 years ago by tec

Replying to dac:

Fenix DC

Delivery looks fine. However, the files look a bit weird. There is a bright / dark (depending on wavelength) strip down the centre of every line starting from band ~ 240 until the last band. This is present in the 1b and mapped data. It would be good to try and figure out what is causing this and mention in the readme.

Couple of comments.

  • Empty fodis directory - removed
  • There are two DEMs, one of which looks filtered. Remove the one which isn't required.

Removed DEM, mark1 is looking into the band thing

comment:26 Changed 5 years ago by dac

LiDAR

Created DSM and compared to one generated from 243b data (both at 0.5 m resolution) using 'create_lidar_diff_image.py' with variance mask turned off (set to very high value).

Absolute mean diff 164.670 m (standard deviation 6.728)

Added this value onto every point in LAS 1.2 and LAS 1.3 files using laspy and copied to:

/users/rsg/dac/scratch_network/MA14_21-2014_283_Danum_Valley_lidar_offset

Updated files match up with 243b point clouds so suggest using these files for the delivery unless we can determine the actual reason for the offsets. Add explanation that an offset was applied to readme file.

comment:27 Changed 5 years ago by dac

  • Description modified (diff)
Note: See TracTickets for help on using tickets.