Opened 15 years ago
Last modified 7 years ago
#278 closed flight processing
GB08/13, flight day 285/2009, Lake Vrynwy — at Version 26
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/12/09)
- Leica LIDAR (22/04/2010)
Change History (26)
comment:1 Changed 15 years ago by mark1
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: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
eagle | hawk | ||||
gpt | sct | gpt | sct | ||
1 | 0.0 | 0.07 | 0.04 | 0.24 | |
2 | -0.05 | 0.05 | 0.0 | 0.2 | |
3 | 0.02 | 0.07 | 0.0 | 0.23 | |
4 | -0.04 | -0.03 | -0.1 | 0.08 | |
5 | 0.0 | 0.06 | 0.0 | 0.2 | |
6 | -0.05 | 0.03 | 0.03 | 0.23 | |
7 | 0.1 | 0.11 | 0.18 | 0.24 | |
8 | -0.07 | -0.07 | 0.0 | 0.3 | |
9 | 0.01 | 0.01 | -0.4 | 0.16 | |
10 | 0.02 | -0.02 | -0.08 | 0.12 | |
11 | 0.12 | 0.15 | 0.1 | 0.3 | |
12 | -0.005 | 0.05 | 0.0 | 0.2 | |
13 | 0.1 | 0.1 | 0.07 | 0.21 | |
14 | -0.08 | -0.02 | -0.05 | 0.13 | |
15 | -0.02 | 0.04 | 0.04 | 0.16 | |
16 | 0.02 | -0.01 | 0.0 | 0.14 | |
17 | 0.05 | 0.07 | 0.14 | 0.3 | |
18 | 0.0 | 0.07 | 0.0 | 0.18 | |
19 | 0.03 | 0.12 | 0.06 | 0.26 | |
20 | -0.02 | -0.05 | -0.14 | 0.04 | |
21 | 0.06 | 0.07 | 0.18 | 0.18 | |
22 | -0.01 | 0.01 | 0.0 | 0.14 | |
23 | 0.02 | 0.0 | 0.04 | 0.14 | |
24 | -0.01 | -0.01 | 0.0 | 0.2 |
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)
comment:26 Changed 15 years ago by knpa
- Description modified (diff)
Logsheet suggests we are missing 7 Eagle flight lines - have emailed gary enquiring if this is so.