Opened 10 years ago
Last modified 9 years ago
#564 new flight processing
PG14/01, flight day 302b/2014, Kuamut Forest
Reported by: | dap | Owned by: | |
---|---|---|---|
Priority: | immediate | Milestone: | |
Component: | Processing: general | Keywords: | |
Cc: | Other processors: |
Description (last modified by dap)
Data location: ~arsf/arsf_data/2014/flight_data/malaysia/PG14_01-2014_302b_Kuamut_Forest
Data arrived from ARSF via network transfer on 06/01/2015.
Scientific objective: Unknown
Priority: Currently unfunded
PI: Glen Reynolds
The size of this dataset is significantly small (only one flightline) as the flight was aborted. The one flightline may not be usable/useful.
There are no RCD images for this flight due to an instrument failure.
Sensors:
- Fenix (?)
- LiDAR (?)
- LiDAR FW (?)
Change History (13)
comment:1 Changed 10 years ago by dap
- Description modified (diff)
comment:2 Changed 10 years ago by dap
comment:3 Changed 10 years ago by dap
LiDAR Processing
Starting processing.
comment:4 Changed 10 years ago by dap
LiDAR Processing
The sol file from flight 302a was used for this flight as it has sufficient data to be able to process the LiDAR data from this flight.
There is only one flight line for this project. I am processing it using the boresight roll and pitch error values.
comment:5 Changed 10 years ago by dap
LiDAR Processing
The flight line has now been processed using ALSPP. Now classifying isolated points (less than 5 points within 10m).
comment:6 Changed 10 years ago by dap
LiDAR Processing
Noisy points have now been classified and delivery and have been created. Removed elevation differences section from the read me as there is only one flight line.
comment:7 Changed 10 years ago by dap
LiDAR Processing
Ready for delivery check.
comment:8 Changed 10 years ago by tec
LiDAR DC
Started
comment:9 follow-up: ↓ 10 Changed 10 years ago by tec
LiDAR DC
Add to data quality that FW couldn't be generated. Reclassify LiDAR, theres a bit in the dem that shows its not classified.
Demcompare mean was 11 which is greater than 8, but as its only one line, not sure if anything can be done.
LAS1.0 -> LAS1.2 dir
Once thats done, ill recheck.
comment:10 in reply to: ↑ 9 Changed 10 years ago by dap
LiDAR Processing
Thanks for the delivery check. Will have another look at the classifications.
comment:11 Changed 10 years ago by dap
LiDAR Processing
I've reclassified the flight line, converted it to ASCII with Windows line endings, regenerated the DEMs and read me (with suggested changes made). I've also renamed las1.0/ to las1.2/
Ready for delivery check.
comment:12 Changed 10 years ago by tec
LiDAR DC
Delivery is fine. DC done. Marked as blocked as to my knowledge its unfunded.
comment:13 Changed 9 years ago by dac
Delivery
Data delivered to Nathan Renneboog via FTP (arsf11) 29/07/2015
While processing 302a's (ticket:554) LiDAR dataset (producing a logsheet), I found that an extra flight line was being added to the logsheet. I searched ~arsf/arsf_data/2014/flight_data/malaysia for this flight line and found it to be part of this flight's LiDAR collection. It was in this flight's log file because we received the two flights from ARSF ops merged in to the same directory.
The solution for the other flight was to back up the original flight line log and remove the extra flight line from the copied log file.
To avoid the same problem in this flight, I have backed up the original flight line log and removed 302a's flightlines from the new one. This is the one that should be used for processing.