BGS12/01, flight day 251/2012, Merthyr

[knpa]

Data location: /users/rsg/arsf/arsf_data/2012/flight_data/uk/BGS12_01-2012_251_Merthyr

Data arrived from ARSF via SATA disk on 24/09/2012

BGS12/01 Scientific objective: unknown

BGS12/01 Priority: ?

PI: Colm Jordan

Notes: This flight has FW Lidar.

Sensors:

Camera (05/12/2012)
Eagle (05/12/2012)
Hawk (05/12/2012)
LiDAR (05/12/2012)
FW LiDAR

[knpa]

Various files missing as a result of corrupt delivery disk.

This affects ipas20 data, eagle data and full waveform lidar data.

[besm]

Navigation processed

[besm]

Processing RCD and LiDAR

For reference (as there may be pitch and roll problems), I used the following pitch and roll errors from the 206a calibration:
Roll Error: 0.00023
Pitch Error: -0.00298

[besm]

Noting that I didn't see any over/under exposed images from the RCD at all. rcd_tester.py only throws up false-positives too. Seems odd for 799 images, but not impossible I guess.

[besm]

Decided on pitch and roll errors for LiDAR for this flight.

Roll: +0.000358
Pitch: -0.00285

[besm]

Appears to be some kind of alignment error, but can't tell what. It doesn't seem consistent going by height differences in the north-west corner of the dataset. Out of this corner, the flightlines 001-013 look okay, while the errors get much bigger between 014-016.

Inconsistent heights, where many surfaces are frequently sloped, could be clearly visible if there were some kind of subtle pitch error, but the pitch error as-is lines up houses in the south-eastern corner, so I'm reluctant to change it.

No height error seems consistent (generally, on the whole, it looks kinda right), so I'm leaving the data as-is for now.

SUMMARY: Flightlines 014-016 have erratic height errors in the north-west corner of the dataset, especially line 014.

EDIT: Also, looking at the south-east end, it looks like these errors aren't consistent across the entire flightline. Since I corrected everything for the middle of the flightline with the above pitch and roll errors, I'd just chalk this down to a one-off hiccup (fingers crossed) on the part of the sensor or navigation data, and hope it doesn't come up in other data sets.

[knpa]

Regarding missing files:

Have not been able to locate missing FW lidar and ipas files. However, from the date stamps I don't think this data is needed.

Found the missing Eagle lines, however they appear to be corrupted as most are of a significantly smaller size than the header indicates. Have already looked through ops' disks so not sure if these will be recoverable. The following eagle lines are affected: 4a, 4b, 5, 7, 10, 13. Note that these have been re-named to match the Hawk and logsheet, the original file names were a jumble due to crashes.

[anhi]

Hyperspectral delivery created

[besm]

Beginning delivery check. Showing Ed how to.

[edfi]

Delivery check complete, missing cross flightline in Hyperspectral but was not flown

[besm]

On my todo list I have "deliver w/o FW" next to 251. Since the full-waveform boresight might be a little while yet, we can make do with the standard lidar delivery already created. Marking as ready to DC.

NOTE TO THE FULL-WAVEFORM LIDAR PROCESSOR (probably me): ONE FLIGHTLINE IS ADJUSTED IN HEIGHT IN THE FINAL DELIVERY.

[edfi]

Beginning LiDAR delivery check

[edfi]

LiDAR delivery check complete. FW missing however will be added latter. ASCII files adjusted into Windows friendly format. Everything else ok

[besm]

Delivered eagle, hawk, camera and lidar all on one disk to Colm Jordan at British Geological Survey, Kingsley Dunham Centre, Keyworth, Nottingham, NG12 2AY. Sent on 5th December.

Still need to check OS vectors against hyperspectral and LiDAR data.