Opened 11 years ago
Last modified 10 years ago
#501 assigned flight processing
RG13/08, flight day 260a/2013, Ash_Die_1
Reported by: | knpa | Owned by: | emca |
---|---|---|---|
Priority: | alpha 4 medium | Milestone: | 2013 data processing completion |
Component: | Processing: general | Keywords: | |
Cc: | Other processors: |
Description (last modified by knpa)
Data location: /users/rsg/arsf/arsf_data/2013/flight_data/uk/RG13_08-2013_260a_Ash_Die_1
Data arrived from ARSF via network transfer on 18/09/2013
RG13/08 Scientific objective: unknown
RG13/08 Priority: BBSRC (8?)
PI: David Coomes
Sensors:
Camera (23/10/2013)
Eagle (23/10/2013)
Hawk (23/10/2013)
LiDAR (23/10/2013)
Change History (33)
comment:1 Changed 11 years ago by emca
comment:2 Changed 11 years ago by emca
Processed the navigation with slightly better results. Still waiting for confirmation from Ops in relation to the User Frame values for the IPAS20 (litton).
Using the dodgy nav to process the hyperspectral data in order to calculate the sct values. Will need to be reprocessing later when/if we get better nav results.
Will hold off on the lidar processing for now.
comment:3 Changed 11 years ago by emca
PPP results for the basestation SNEO:
Lat: 52 11 07.32797
Long: -0 06 44.97284
Elev: 120.092
comment:4 Changed 11 years ago by emca
The Eagle was processed with binning 4 so created a new qc failures file
eagle_110001_bin4_visualbadpixels.txt
Added this file to /users/rsg/arsf/calibration/2013/eagle/
comment:5 Changed 11 years ago by emca
Processed the LiDAR lines. Couple of problems:
Line 1 has a large blank down the middle, looks like its a range gate issue
Line 4 has only processed partly, about one third, not sure why as ASLPP does not show any errors
Line 5 does not process at all, ALSPP crashes when I load it in
comment:6 follow-up: ↓ 8 Changed 11 years ago by emca
Processed the IPAS honeywell nav data for 260b - which was fine. After checking further looks like a corrupt file in ipas_honeywell/raw was causing the problem. It is the same on thelma so must have been a problem when downloading from the aircraft. Replaced corrupt nav file with the one from day 260 b.
comment:7 Changed 11 years ago by emca
- Description modified (diff)
comment:8 in reply to: ↑ 6 Changed 11 years ago by emca
Replying to emca:
looks like a corrupt file in ipas_honeywell/raw was causing the problem.
Corrupt files... raw files 02, 05, 06, 07 and 08.
Have replaced these with the data from 260b.
comment:9 Changed 11 years ago by emca
Got better nav results using the IPAS20 data. Will process all data using the new nav results.
comment:10 Changed 11 years ago by emca
Flightline | Eagle SCT | Hawk SCT |
1 | -0.02 | -0.05 |
2 | -0.02 | -0.06 |
3 | -0.02 | -0.06 |
4 | -0.02 | -0.06 |
5 | 0.00 | -0.05 |
comment:11 Changed 11 years ago by emca
Hyperspectral data ready for delivery check. Waiting to hear from Gary re: vectors.
comment:12 Changed 11 years ago by tipo
- Component changed from Processing: general to Archiving
- Owner set to benj
check_apl_cmd fails, typo in example commands?
comment:13 Changed 11 years ago by tipo
- Component changed from Archiving to Processing: general
- Owner changed from benj to emca
- Status changed from new to assigned
comment:14 Changed 11 years ago by emca
Recreated the hyperspectral readme - sample commands updated. Check_apl_cmd should work now.
comment:15 Changed 11 years ago by emca
Camera data ready for delivery check
comment:16 Changed 11 years ago by tipo
check_apl_cmd still fails:
/users/rsg/arsf/usr/bin/check_apl_cmd: line 294: 10780 Segmentation fault (core dumped) apltran -inproj latlong WGS84 -igm ../../tmp_cmd_check/e260a013b.igm -output ../../tmp_cmd_check/e260a013b_osng.igm -outproj osng /users/rsg/arsf/dems/ostn02/OSTN02_NTv2.gsb
The .igm file is created, but has no .hdr Does the script work for you? if so, it might be yet another Fedora 19 problem.
comment:17 Changed 11 years ago by tipo
RCD delivery checked, no problems found.
comment:18 Changed 11 years ago by emca
check_apl_cmd works fine for me - perhaps try on mark1's machine (he is away today)
comment:19 Changed 11 years ago by tipo
Yep, running it from Marks's machine seems to work. I'll add the problem to the Fedora 19 issues page.
No other issues found with hyperspectral.
comment:20 Changed 11 years ago by emca
Asked Ops to copy the raw lidar data (RawLaser) from the SSD's to Thelma. They did this and the lidar lines that we causing ALSPP to crash are now processing fine.
The data got lost/corrupt when copying from aircraft to thelma first time around.
Two of the lines suffer from range gate issues (line 2 and line 6)
comment:21 Changed 11 years ago by emca
No obvious roll in the lidar data, but limited overlap so it is difficult to tell.
comment:22 Changed 11 years ago by emca
Hyperspectral and RCD on disk 187 ready to deliver. Just waiting to hear from gary re: vectors.
comment:23 Changed 11 years ago by emca
Finished processing LiDAR, ready for delivery check.
comment:24 Changed 11 years ago by stgo
Beginning LiDAR D/C.
comment:25 Changed 11 years ago by stgo
LiDAR D/C complete, no issues found.
comment:26 Changed 11 years ago by emca
Data sent to D. Coomes 23/10/2013
comment:27 Changed 11 years ago by emca
- Description modified (diff)
comment:28 Changed 11 years ago by emca
Email from Gary 30/10/2013 - Awaiting vector agreement form between OS and PI before vectors can be sent to us.
comment:29 Changed 11 years ago by knpa
- Description modified (diff)
comment:30 Changed 11 years ago by knpa
- Description modified (diff)
comment:31 Changed 11 years ago by emca
Vectors have arrived for this project
comment:32 Changed 11 years ago by emca
Created a lidar intensity with vectors image, and also checked overlap in ENVI. Vectors agree to within 1-2 meters.
comment:33 Changed 10 years ago by lah
uploaded to NEODC 24/06/15
Problems with the IPAS Honeywell, large gaps in the data collected.
Trying to use the IPAS20 but not getting good results. Waiting for confirmation of lever arms values before going any further.
Processed the raw camera image -> tiff.