MA14/21, flight day 243b/2014, Danum Valley, Malaysia

[dac]

Data location: ~arsf/arsf_data/2014/flight_data/malaysia/MA14_21-2014_243b_Danum_Valley

Data arrived from ARSF USB Pen on 20/10/2014

Scientific objective: Unknown

Priority: Unknown

PI: Mathias Disney

Currently only sample of data sent by ops to check.

Navigation and LiDAR data is also from aborted 283a flight.

Sensors:

• Fenix (flown)
• Leica LIDAR (flown anyway)
• RCD (flown)

[lah]

Nav basestation ppp result
Lat 5 56 25.40280
Long 116 03 01.55349
Heght 52.101

[lah]

Processed nav data with default settings, but with elevation mask set to 16 to bring the longitudinal separation below 0.05 m for most of the data.

[lah]

Nav data does not appear to correspond to HSI files. Now processing other raw nav data (there were 3 in 243b).

[lah]

On further checking, 3rd nav file corresponds to lines 9 & 12, so nav processing is complete. I have moved the reflown lines (2 & 3) to a subdirectory so they won't be automatically processed. The other nav files will correspond to the other lines, so won't process them any further at this point (with various settings I can't get a fixed ambiguity solution).

[lah]

Fenix
Started hyperspectral processing for lines 9 & 12. Renamed 283b files to 243b and replaced headers using replace_wavscale.py.

[lah]

Lidar
Started lidar processing for lines 9 & 12. Trees seem to overlap quite well, so keeping boresight offsets. No features to use to improve.
Roll offset: -0.006375
Pitch offset: 0.00016318
Heading offset: 0.00008

[lah]

Fenix
Found SCTs, both 0.99, though mostly just trees. (Using previous boresight) Made delivery, but missing xml files (area missing from database). Pixel resolution is 1 m. No need for ReadMe as only a subset of data.

[lah]

Lidar
Made lidar delivery with the 2 lines for future reference. Little noise whilst classifying. dems produced fine. Again no ReadMe produced for this set. No FW to check.

[lah]

Pre-checks complete
No Owl, RCD or FW to check, so changing status to blocked until rest of data arrives. Emailed Ops Tom to say data processed 22/10/2014 and looks fine.

[dac]

Emailed ops to check on status of missing lines.

[dac]

James is currently away - will check backup disks for missing lines when he returns at the end of November.

[dac]

Spoke to Gary about missing lines. There are only two flight lines with the repeats intended to provide higher LiDAR point density so missing lines are less of a problem for Fenix.

[dac]

Heard back from Gary and James - they don't have a copy of missing lines after the move to Cambridge. Checking here.

[dac]

ARSF-DAN don't have a copy of extra lines. Download of all data from Ops server was confirmed 08/01/2015 but didn't flag missing lines.

Fenix can be delivered as missing lines aren't a problem. Will try and process the other two LiDAR lines which wouldn't previously process to provide an extra set of repeats.

[dac]

Fenix

Replaced wavelengths and started reprocessing lines using 2015 calibration.

[dac]

Fenix

Lines processed - starting to make delivery.

[dac]

Fenix

While preparing files for delivery noticed strip down centre of line for bands > 240, observed for 2014/288, are also present for this flight.

[dac]

Fenix

Changed numbering of raw file from '-09' to '-9' as expected by scripts.

[dac]

Fenix

Have created delivery with available lines. Ready for checking.

[dac]

LiDAR

Processed first navigation file from flight, which covered first to LiDAR lines. With updated navigation file lines processed OK. Calculating roll offsets.

[dac]

There is actually 2014/283 (10/10/2014) but was incorrectly labelled as 243b. No further processing is required.

[dac]

Have moved to ~arsf/arsf_data/2014/flight_data/arsf_internal/MA14_21-2014_243b_Danum_Valley and removed from database.