RG13/06, flight day 302a/2014, Maliau Basin

[dap]

Data location: /users/rsg/arsf/arsf_data/2014/flight_data/malaysia/RG13_06-2014_302a_Maliau_Basin

Data arrived from network transfer on 17/12/2014.

Scientific objective: Investigating the impact of humans on tropical forests.

Priority: alpha 5

PI: David Coomes

Owl data present
RCD crashed and so there are no RCD images.

This flight's data files were merged with those from flight 302b (i.e. put in the same project directory) when received from ARSF operations. Because of this, these flights share the same navigation data (posatt/ipas20/raw). These should be split during processing or the same sol file should be used for both flights.

Sensors:

• Fenix (requested)
• Leica FW LIDAR (?)
• Leica LIDAR (requested)

Duplicate lines

Process only one for Fenix and RCD - check for which has least cloud cover, failing that choose closest to local noon

• 1257-1259 (3 times, repeated day 303)

[dap]

Beginning Navigation Processing

[dap]

Navigation Processing

MALIAU_3r Basestation Information
Latitude	4 44 08.45842
Longitude	116 58 34.69346
Ell. Height	272.586m

[dap]

Navigation Processing

Have processed the nav data with GrafNav and IPAS Pro, using elevation mask of 13.5 degrees and set C/A code to 1.3

No significant problems found within the navigation data for the flightlines.

[dap]

Beginning LiDAR Processing

[dap]

LiDAR Processing

Processed all flight lines with config file from 238 boresight flight and found that the data have a considerable roll/pitch error. Have also processed using the older config file from boresight flight 182 (output directory processing/las/old-config) and found a similar roll/pitch error.

[dap]

Fenix Processing not required as all flight lines were duplicated in flight 303 (ticket:556), whose flight lines were affected less by cloud than those collected during this flight.

[dac]

Navigation Processing

Reprocessed basestation data

Latitude	4 44 08.45833
Longitude	116 58 34.69331
Ell. Height	272.952 m

[dac]

Navigation Processing

Reprocessed navigation data in IPAS Pro. No ipas_honeywell data so used ipas20.

[dac]

LiDAR Processing

• Checked navigation data by processing hyperspectral data - all looked OK.
• Tried processing with pitch and roll values from 303 (shown below). Still needs some improvement but looks a lot better than with boresight values.

Roll	-0.006095
Pitch	-0.00061

[dap]

LiDAR Processing

Processed all lines with pitch error value of -0.0005 and seems fairly consistent across all. Now processing to find consistent roll error value.

[dap]

LiDAR Processing

The following pitch and roll error values seem to produce good results:

Flightline	Pitch	Roll
005039	-0.00061	-0.006095
005331	-0.0005	-0.006375
005621	-0.0005	-0.006175
005947	-0.0005	-0.006175
010238	-0.0005	-0.006175
010537	-0.0005	-0.006175
010829	-0.0005	-0.006175
011104	-0.0005	-0.006175
011416	-0.0005	-0.006175

[dap]

LiDAR Processing

All noise has been classified, now creating delivery.

[dap]

LiDAR Processing

I came across a problem when trying to generate a logsheet for the flight where an additional flight line was being added to it. This was because the flight line was in the LiDAR flight line log. I searched all of ~arsf/arsf_data/2014/malaysia for flightlines with the name of the extra flight line and found that it is actually part of flight day 302b's (ticket:564) LiDAR collection (the data from these two collections were merged when received from ARSF ops, as noted in the ticket above).

Solution was to copy the flight line log to a new file and back up the original (141028_234547_FlightLineLog_original.csv) then remove the last flight line from the copied flight line log, retaining it in the original.

I have also looked at the flight line log in flight day 302b's project directory and found that this contains flight lines from 302a's flight, so I have removed them from that flight line log (keeping the original backed up).

[dap]

LiDAR Processing

Delivery and read me created, now ready for delivery check

[dac]

LiDAR DC
Starting Delivery Check

[dac]

LiDAR DC

Apart from the classification, everything looks fine.

• Pitch and roll values look good.
• Only the height difference between two lines is included in the Readme.
• Some of the ASCII files didn't have Windows line endings (have corrected).
• Too many within canopy returns are classified as noise, likely due to the values used in the isolated points identification. This could cause problems when creating a DTM.

[dap]

LiDAR Processing

Re-classifying the data using a smaller threshold with the isolated classification algorithm (-isolated 10 5).

Looking at the first line, this threshold seems to be a better threshold and classifies fewer points within canopies.

[dap]

LiDAR Processing

• Reclassified las1.2 files, both manually and automatically.
• Converted las1.2 files to ASCII format (and converted line endings to be Windows compatible).
• Copied classifications over to las1.3 files.
• Recreated DEMs with new classifications patched.
• Re-generated read me with new classification info.

Ready for re-checking.

[dac]

LiDAR DC

New classification looks much better. Ready to deliver.

[lah]

PI notified of lidar delivery 05/05/2015

[dac]

Archiving

Checked and ready for upload to NEODC.

[dac]

Archiving

Uploaded to NEODC.