Opened 15 years ago

Last modified 7 years ago

#278 closed flight processing

GB08/13, flight day 285/2009, Lake Vrynwy — at Version 25

Reported by: mark1 Owned by: mark1
Priority: alpha 4 high Milestone: 2009 Data processing completion
Component: Archiving Keywords:
Cc: Other processors: benj

Description (last modified by knpa)

Data location: ~arsf/arsf_data/2009/flight_data/uk/GB08_13-2009_285_Lake_Vrynwy

Data arrived from ARSF via network transfer on 14th October 2009.

Scientific objective: Monitoring and modelling vegetation response under catchment-scale treatment regimes using Earth Observation (EO) data

Priority: alpha-4-high

PI: M. Disney

Sensors:

  • Eagle (14/12/09)
  • Hawk (14/10/09)
  • Leica LIDAR (22/04/2010)

Change History (25)

comment:1 Changed 15 years ago by mark1

Logsheet suggests we are missing 7 Eagle flight lines - have emailed gary enquiring if this is so.

comment:2 Changed 15 years ago by mark1

Have renamed Hawk285* files to SWIR285*

comment:3 Changed 15 years ago by mark1

Copied the 7 missing files from Thelma to project directory.

comment:4 Changed 15 years ago by chrfi

  • Owner set to chrfi

navigation data processing complete

comment:5 Changed 15 years ago by 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/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-10.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-12.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-13.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-14.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-15.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-16.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-17.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-18.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-19.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-1.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-20.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-21.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-22.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-23.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-24.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-2.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-3.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-4.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-5.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-6.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-7.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-8.hdr: predicted length half recorded length, frame rate doubling problem?
uk/GB08_13-2009_285_Lake_Vrynwy/hawk/SWIR285-09-9.hdr: predicted length half recorded length, frame rate doubling problem?

comment:6 Changed 15 years ago by chrfi

eagle line 17 header states incorrect number of lines, changed to 2417

comment:7 Changed 15 years ago by chrfi

eagle line 17, created dark frame file and pointed azspec at it, this allowed the viable lines to be processed but the flightline is truncated due to the missing lines.

comment:8 Changed 15 years ago by chrfi

eagle offsets

gpt sct
1 0.0 0.07
2 0.0 0.1
3 -0.03 0.02
4 -0.03 0.04
6 0.0 0.08
7 -0.04 0.06
8 0.0 0.06
9 0.01 0.01
10 -0.07 0.03
11 0.05 0.08
12 -0.005 0.05
13 0.05 0.05
14 -0.01 0.05
15 -0.02 0.04
16 -0.01 0.02
17 0.05 0.07
19 -0.02 0.07
20 0.04 0.01
21 0.06 0.07
22 -0.01 0.01
23 0.02 0.0
24 -0.15 -0.05

comment:9 Changed 15 years ago by mggr

Phil fixed up the LIDAR data and put on thelma - pulled to arsf directory. There are now 28 lines instead of ~10.

comment:10 Changed 15 years ago by chrfi

due to the lack of linear geographic features this made eliminating wobbles hard, this in turn made matching up the flight lines difficult. The vector files and lidar have been used to give better accuracy. here are the new offsets

eaglehawk
gptsct gptsct
10.00.07 0.040.24
2-0.050.05 0.00.2
30.020.07 0.00.23
4-0.04-0.03 -0.10.08
50.00.06 0.00.2
6-0.050.03 0.030.23
70.10.11 0.180.24
8-0.07-0.07 0.00.3
90.010.01 -0.40.16
100.02-0.02 -0.080.12
110.120.15 0.10.3
12-0.0050.05 0.00.2
130.10.1 0.070.21
14-0.08-0.02 -0.050.13
15-0.020.04 0.040.16
160.02-0.01 0.00.14
170.050.07 0.140.3
180.00.07 0.00.18
190.030.12 0.060.26
20-0.02-0.05 -0.140.04
210.060.07 0.180.18
22-0.010.01 0.00.14
230.020.0 0.040.14
24-0.01-0.01 0.00.2

comment:11 Changed 15 years ago by benj

  • Other processors set to benj

Doing delivery checking

comment:12 Changed 15 years ago by benj

Comments:

  • Needs up-to-date data quality report (and update readme with correct date for this)
  • Update "Quality of data" section in readme (still a TODO in there, don't know if you updated it or not)
  • Rename level 1 files and screenshots in delivery to get rid of timing information (should just be e281011b.*, not _sct etc.)
  • Update azgcorr and azexhdf commands in readme to be correct for delivered files and have named DEM. Update text with it appropriately.

Still checking through level 1s, readme should be re-checked once above changes are made.

comment:13 Changed 15 years ago by benj

Eagle line 17, number of lines in header reports wrong (should be checked) plus for some reason the first seven and last eleven bands (approx.) have higher values than they should (spectral profile has a spike in these bands). Number of lines in the header should be fixed (check against raw to see what's happened), abnormally high value problem should be checked before delivery (possibly wrong cal file used or something?), if it looks like it's a problem with the data itself (rather than the processing) then should be mentioned in the readme.

comment:14 Changed 15 years ago by benj

Last hawk band is always blank (see #291). Doesn't need to be fixed before delivery but should be mentioned in readme.

Finished delivery check, once the items above are fixed and the readme is updated this can be delivered.

comment:15 Changed 15 years ago by chrfi

delivery check acted on.

delivering on hard drive 20

comment:16 Changed 15 years ago by benj

Just for the record, the problem with Eagle line 17 was that it cut off half way through (the last incomplete line confused the processing results so there was an extra line reported), plus it didn't have dark frames (causing the problem with the wrong values).

comment:17 Changed 15 years ago by chrfi

eagle and hawk delivered on usb hard drive 20, 14th dec

comment:18 Changed 15 years ago by chrfi

data in workspace needs to be rsynced back to arsf/arsf_data once space becomes available

comment:19 Changed 15 years ago by emca

  • Owner changed from chrfi to emca
  • Status changed from new to assigned

Starting LIDAR processing

comment:20 Changed 15 years ago by mark1

  • Owner changed from emca to mark1

Taking over LIDAR processing

comment:21 Changed 15 years ago by mark1

LIDAR delivery created at
~airborne/workspace/GB08_13-2009_285_Lake_Vrynwy/delivery/20100414/GB08_13

comment:22 Changed 15 years ago by emca

Delivery checked LIDAR data, all looks good.

Ready to deliver.

comment:23 Changed 15 years ago by mark1

  • Description modified (diff)

LIDAR delivery dispatched to PI on 22/04/2010

comment:24 Changed 15 years ago by mark1

  • Component changed from Processing: general to Archiving

LIDAR rsynced over to:
~arsf/arsf_data/2009/flight_data/uk/GB08_13-2009_285_Lake_Vrynwy

All data delivered. Ready to archive.

comment:25 Changed 15 years ago by knpa

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