Opened 9 years ago
Closed 8 years ago
#591 closed flight processing (fixed)
RG13/08, flight day 234b/2015, Monks Wood
Reported by: | lah | Owned by: | |
---|---|---|---|
Priority: | immediate | Milestone: | 2015 data processing completion |
Component: | Processing: general | Keywords: | |
Cc: | Other processors: |
Description
Data location: ~arsf/arsf_data/2015/flight_data/uk/RG13_08-2015_234b_Monks_Wood
Data arrived from ARSF via USB on 27/08/2015.
Scientific objective: Measuring ash die back.
Priority: Unknown
PI: David Coomes
Flown on same day as Cambridge (RG13/08) and Alconbury(GB15/00).
Sensors:
- Fenix
- Leica LIDAR
- FW Leica LIDAR
- RCD
Change History (33)
comment:1 Changed 9 years ago by lah
comment:2 Changed 9 years ago by gej
RCD processing
Have produced tif files, waiting to do navigation.
comment:3 Changed 9 years ago by stgo
Nav processing
lat | 52 11 07.32948 |
long | -0 06 44.97121 |
height | 120.043 |
comment:4 Changed 9 years ago by stgo
Nav processing
Navigation data processed with seperation below 5 cm variation and a good position accuracy. Proceeding to lidar processing.
comment:5 Changed 9 years ago by stgo
Lidar processing
There were only 3 lines and all are seperated so much overlap info cannot be estimated and pitch/roll/heading cant be calculated. Have generated a delivery from the data (there is the same amount of data for hyperspectral so I assume its safe to proceed with just three lines)
comment:6 Changed 9 years ago by stgo
Lidar processing
Completed delivery. ready for delivery check
comment:7 Changed 9 years ago by lah
Fenix Processing
Found SCTs:
Flightline | FENIX |
7 | 1.00 |
8 | -0.02 |
9 | 1.00 |
comment:8 Changed 9 years ago by lah
Fenix Processing
Delivery created, ready for checking.
comment:9 Changed 9 years ago by lah
Lidar Delivery
Replaced logsheet with fixed version.
comment:10 Changed 9 years ago by lah
Lidar DC
- Not many buildings, but lines up very well with 2014 152a
- Slightly too many returns classified as noise (generally second returns in forested areas). Could be important for application?
- changed las1.0 to 1.2
- changed sol file name -234b to _234b
- demcompare mean -0.94
- fw look as normal
Ready to go if lots of noisy points not a problem.
comment:11 Changed 9 years ago by gej
RCD processing
Have created camera navigation file, tagging tiff images now.
comment:12 Changed 9 years ago by gej
RCD processing
Delivery and Readme created, ready for delivery check
comment:13 Changed 9 years ago by stgo
Fenix delivery check
starting check
comment:14 follow-up: ↓ 15 Changed 9 years ago by stgo
Fenix delivery check
A couple of things.
- apl command check fails on mapping stage. This is because the igm filename is incorrect (3b vs 1b), I'm checking the generator and checking script to see if this is a problem with them.
- should we be worried about proj tidy saying "The number of wavelengths in FENIX234-15-8.hdr is not the same as the length as any of the .wls files in /users/rsg/arsf/calibration/2015/fenix/" ? (says this for all files)
comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 9 years ago by lah
Replying to stgo:
Fenix delivery check
A couple of things.
- apl command check fails on mapping stage. This is because the igm filename is incorrect (3b vs 1b), I'm checking the generator and checking script to see if this is a problem with them.
There's not a problem with the names generated by the script; these were added manually. The problem is that if there is no line 1 it doesn't generate the commands automatically so human error is far more likely.
- should we be worried about proj tidy saying "The number of wavelengths in FENIX234-15-8.hdr is not the same as the length as any of the .wls files in /users/rsg/arsf/calibration/2015/fenix/" ? (says this for all files)
That is odd, as the wavelengths are from 201509. Are you sure this isn't just for the original_headers subdirectory?
comment:16 in reply to: ↑ 15 Changed 9 years ago by stgo
Replying to lah:
That is odd, as the wavelengths are from 201509. Are you sure this isn't just for the original_headers subdirectory?
I've just checked, it only looks at the files in the sensor directory and won't go down into the original headers folder. APL would have complained before this point so I *think* it's ok.
I'd assumed the apl commands were auto generated, they can be fixed by changing igm file references from 3b to 1b.
comment:17 Changed 9 years ago by dac
RCD Delivery Check
Starting delivery check.
comment:18 Changed 9 years ago by dac
RCD Delivery Check
All looks fine - ready to deliver.
comment:19 Changed 9 years ago by lah
Fenix Delivery
Have corrected filenames in config file and regenerated Readme. Should all be ok now.
comment:20 Changed 9 years ago by stgo
Lidar delivery
Recreated the delivery with much reduced noisey points, would be worth a quick check of readme but otherwise are identical files
comment:21 Changed 9 years ago by lah
Lidar re-DC
- classification looks much better
- renamed las1.0 to 1.2
- changed sol file name in delivery again
Everything else looks fine, so ready to deliver.
comment:22 Changed 9 years ago by stgo
Fenix delivery
Can't see anything wrong with the delivery now. Need someone to double check spectra but otherwise ready for delivery.
comment:23 Changed 9 years ago by dac
Fenix Delivery Check
Checked spectra against Py6S. Looks fine - ready to delivery.
comment:24 Changed 9 years ago by dac
Fenix
Started zipping mapped files ready for delivery.
comment:25 Changed 9 years ago by dac
Fenix, LiDAR and RCD Delivery
Sent to PI via FTP (arsf19) 17/12/2015
comment:26 Changed 9 years ago by stgo
LiDAR processing
With the updated processing reg the overlap has been significantly increased, as was stated before the data lines up with 152 and what features are available to estimate from do not seem to show any alterations in pitch and roll.
Creating delivery.
comment:27 Changed 9 years ago by stgo
LiDAR processing
Created lidar delivery, ready for check.
comment:28 Changed 9 years ago by dac
LiDAR Delivery Check
Starting delivery check
comment:29 Changed 9 years ago by dac
LiDAR Delivery Check
Looks fine. The .trj files are missing, not sure if these need to be generated again or ones from previous delivery can be used.
The quality of the ASTER DSM is really poor - it is very noisy. I was unsure if there was a problem with the LiDAR so also compared to SRTM and there was a good match there so I think it is just a problem with the ASTER.
Once .trj files are added ready to deliver.
comment:30 Changed 9 years ago by dac
LiDAR
Re-generated .trj files. The .reg file was missing so needed to re-create - will check with stgo (likely local copy).
Ready to deliver
comment:31 Changed 9 years ago by dac
LiDAR data delivery
Redelivered via FTP (arsf19) - 26/02/2016
comment:32 Changed 8 years ago by dac
Archiving
Started uploading to NEODC.
comment:33 Changed 8 years ago by dac
- Resolution set to fixed
- Status changed from new to closed
Archiving
Data now available from NEODC. Closing ticket.
Unpacking
All extra files have been split out except from RCD, which is duplicated for 234a, 234b and 234c. Please only process RCD for one of these projects, then split once processed.