GB09/05, flight day 078c/2009, Leighton Leven Esthwaite

[jatt]

Data location: ~arsf/arsf_data/in_progress/2009/flight_data/uk/GB09_05-2009_078c_Leighton_Leven_Esthwaite

Data arrived from ARSF via SATA disk N on 30th March 2009.

Scientific details: /users/rsg/arsf/arsf_data/2009/ARSF_Applications/GB09-05

Priority: a4L

PI: Dr Alan Blackburn

Sensors:

• Eagle (7/12/2009)
• Hawk (7/12/2009)
• ALS-II Lidar (05/10/2009)
• Photography (06/01/2010)

Quicklook

TBD.

[emca]

Started lidar processing

[emca]

LIDAR processing now complete. Delivery directory created at
~airborne/workspace/GB09_05-2009_078c_Leighton_Leven_Esthwaite/leica/delivery

Passing to mark1 for delivery checking.

[mark1]

Delivery checked, opened ascii files in Grass and opened OK. Read-me needs accuracy vs vectors to be filled in. Otherwise good.

[emca]

LIDAR data sent to PI 05/10/09.

[mggr]

Re: #281 (Hawk frame rates are double what they should be), the following lines are affected and the .hdr file will need to be edited to halve the fps number:

uk/GB09_05-2009_078c_Leighton_Leven_Esthwaite/hawk/SWIR078c-09a-1.hdr: predicted length half recorded length, frame rate doubling problem?

[mark1]

Started processing of E/H hyperspectral. No nav file for any of the Eagle lines and data suffers from the variable boresight issue.

[mark1]

renamed hawk SWIRdatacube.* to SWIR078c-09-1.* although the raw file only contains 4K of data.

[mark1]

Hawk line 1 contains no data, Hawk line 7 has no .hdr file and the raw data appears to be corrupt. Hawk lines 6 and 8 have incorrect number of lines in .hdr files and no dark frames, indicating that hawk probably crashed during capture. Also hawk line 4 has no dark frames. Hawk lines 4 and 6 have been processed using the dark frames from line 3 while hawk line 8 has been processed using dark frames from line 9. This will result in approximate values, not a true radiometric calibration. Both Hawk and Eagle line 9 are very short.

[mark1]

Eagle Line	GPT	SCT	Hawk Line	GPT	SCT
1	0	1.6	1	-	-
2	-0.1	0.8	2	0	0
3	-0.15	0	3	0	0
4	-0.34	0	4	0	0
5	-0.06	0.8	5	0	0
6	-0.35	1.3	6	0	0
7	-0.20	0.8	7	-	-
8	0.02	0.7	8	0	0
9	0	0.7	9	0	0

[mark1]

Boresight values

Eagle line	P	R	H	Hawk Line	P	R	H
1	-0.30	-0.73	0	1	-	-	-
2	-0.05	-0.69	0.50	2	-0.16	0.20	0.13
3	0.05	-0.54	-0.17	3	-0.31	0.14	0.15
4	0.75	-0.70	0.15	4	-0.23	0.20	0
5	-0.12	-0.47	0.1	5	-0.21	0.28	-0.06
6	0.78	-0.70	-0.21	6	-0.12	0.23	0
7	0.32	-0.50	0.16	7	-	-	-
8	-0.40	-0.70	-0.05	8	-0.21	0.20	0
9	-0.10	-0.25	0	9	-0.16	0.48	0.15

[mark1]

Eagle/Hawk ready for delivery checking. Delivery directory located at:
~mark1/scratch_space/2009_data/GB09_05-2009_078c_Leighton_Leven_Esthwaite/delivery

[emca]

Delivery check is complete. Minor changes to be made to read_me (flight line numbers and comment re: missing data in lev1 files).

[mark1]

Edited logsheet flight line numbers

[mark1]

Delivery and run scripts have been rsynced to

~arsf/arsf_data/2009/flight_data/uk/GB09_05-2009_078c_Leighton_Leven_Esthwaite/

[mark1]

Eagle and Hawk data dispatched to PI 7th December 2009

[mark1]

Digital Photography data dispatched to PI on 6th January 2010

[mark1]

Lidar and Photography deliverys rsynced over to main arsf repo:

~arsf/arsf_data/2009/flight_data/uk/GB09_05-2009_078c_Leighton_Leven_Esthwaite/

[mark1]

Everything delivered to PI.

Ready for archiving.

[knpa]

Archived by DTG (12/01/09)
Preparing for NEODC.

[knpa]

Tarball created and NEODC informed ready for transfer.

[knpa]

NEODC have completed transfer.
Was missing dem but have found made available to them.

[tipo]

Raw files for Hawk 6 and 7 were larger than indicated by the header files. Created copies trimmed to the correct size so that they could be processed.

[benj]

Tim, see previous comment from Mark on various aspects of Hawk data corruption. Please consider the appropriate way to handle these - truncating the file may not be the appropriate option, you might be better to correct the header file if we can get more data that way.

[tipo]

The difference in file size is by only part of a line, so I don't think it will be possible to match the sizes by altering the header. The partial line could be padded out with "empty" data to make it a full line, but that seems even less ideal a solution than just removing the partial line.

[benj]

No, I agree - if there isn't a full line then we have to assume the partial one is corrupt, so truncating is the best option in this instance. Still might want to discuss the other lines above with Mark.

[lah]

Archiving

Tidied and ready for upload to NEODC.

[asm]

Archiving

Reprocessed hyperspectral has been archived and it is available from CEDA at ​​browse.ceda.ac.uk/browse/neodc/arsf/2009/GB09_05/GB09_05-2009_078c_Leighton_Leven_Esthwaite/hyperspectral-reprocessed

Plymouth 11th May 2017