RANNIS15/28, flight day 244a/2015, Hekla

[asm]

Data location: ~arsf/arsf_data/2015/flight_data/iceland/RANNIS15_28-2015_244a_Hekla

Data arrived from ARSF via SATA disk 8 on 28/09/2015.

Priority: Unknown

PI: Gro Pedersen

CAFAM code: R028

Sensors:

• Fenix (requested)
• Owl (requested - currently unfunded)
• Leica LIDAR (requested)
• RCD (requested)

[asm]

Flight Details
Logsheet has been created.
Only Lidar may be viable. Both Fenix and Owl expected to be low quality and may not be worth processing. Will need to verify if the area covered is present on another day before processing.

[asm]

General Processing
Sent to PI ARSF data arrival notification for RANNIS15/28.

[asm]

Navigation Processing

Started. Needed to download base station information for this project. Used REYK

Lat: 64 08 19.63071
Lon: -21 57 19.7544
Elipsoidal Height: 93.208 (metres)
Antenna Height: 0.057 (metres)

[asm]

Navigation Processing

Could not find a suitable solution with Ipas TC, will try Ipas Pro.

[asm]

Navigation Processing

Finished. Ipas Pro not responding, done on Ipas TC using PPP rather than a basestation GNSS since could not find a suitable solution for height accuracy (~3 metres on GNSS, ~35 cm on PPP).

[gej]

RCD processing

Generating tifs

[asm]

Lidar Processing

Started to have a look at data quality and will be resumed on January. Mostly, flown over lots of raining clouds and has a lot of noise. It seems that still has usable data and dac will work on a filter to remove those clouds of points.

[stgo]

Fenix processing

I've processed through and got half the sct values, checking to see if splitting lines improves loading of files (this may be being caused by server slowing down though)

[dac]

PI prefers delivery by hard drive

[dac]

Marking as blocked - still waiting on GPS data from IMO.

[asm]

Navigation processing

Navigation reprocessed with GPS data provided by Icelandic Met-office .
Basestation verification for FEDG:
Latitude 64 01 30.92939
Lon -19 41 22.05849
Ell Height 503.762
Ant Height 1.00 m, to L1-PC (TRM411249.00, MeasDist 0.929)
Which corresponds on decimal degrees to the values sent by Met-office: -19.68946006 64.02525821 503.73149445

Basestation verification for HESA:
Latitude 64 02 48.62713
Lon -19 33 38.08812
Ell Height 529.122
Ant Height 1.090 m, to L1-PC (TRM411249.00, MeasDist 1.019)
Also match data received: -19.56057992 64.04684073 529.08620580 HESA deltaz=0.244

Basestation verification for MJSK:
Latitude 63 55 58.600002
Lon -19 40 20.53108
Ell Height 770.544
Ant Height 1.050 m, to L1-PC (TRM411249.00, MeasDist 0.979)
Also match data received:-19.6723625459 63.9329479506 770.861162678

Best solution found using HESA. Basestation MJSK is shorter than IMU data, it covers the flown data but IpasTC will hang if processing ending after 215000. Copying files and will rename old basestation and ipas_honeywell to old_nav_basestation (Please clean after processing, before archiving).

[asm]

Lidar Processing

Lidar processing restarted using new navigation.

[asm]

Lidar Processing

Found pitch and roll consistent trough all lines:
Roll: -0.000805
Pitch: -0.002495

Will classify and create delivery.

[gej]

RCD processing

Finished tagging, delivery and read me created.

Ready for delivery check

[asm]

Lidar

Classification is finally finished. Needed lot of work both running locally and manually due to clouds and low returns. Will create delivery.

[lah]

RCD DC

Project code is too long so proj_tidy throws up everything as wrongly named. Might want to update proj_tidy if we're going to keep having long project codes.

Delivery is fine though, so now ready to deliver.

[asm]

Lidar Processing

Lidar delivery and readme created (no full wave form available). Ready for delivery check.

[dac]

LiDAR Delivery Check

Starting delivery check.

[dac]

• Cloud classification looks good.
• Pitch and roll correction are OK.
• Reworded text about clouds in readme.
• Comparison with ASTER - demcompare.py output:

  Difference statistics:                                                          
  Min:            -468.429662109375                                               
  Max:            47.6989895019531                                                
  Sum:            -6778391.1214125                                                
  Mean:           -10.7743153131929                                               
  Median:         -9.4086                                                         
  Absolute mean:  11.717408818906                                                 
  Std deviation:  22.5375141619747                                                
  Total cells:    7644465                                                         
  Non-null cells: 629125                                                          
  

• Marking as ready to deliver.

[stgo]

Hyperspectral processing

I've finished processing and generated a delivery. The files contained in this delivery are quite large, though they are at a diagonal so once compressed they should be fine.

Scts:

Flightline	FENIX
1	0.99
2	1.02
3	0.90
4	1.09
5	0
6	0.90
7	1.10
8	0.93
9	1.01
10	0.60
11	0.97
12	0.95
13	0.99
14	1.01
15	0
16	0.97
17	0.20
18	1.02
19	0.80
20	1.06
21	0.94
22	1.10
23	0.97
24	1.02

Ready for delivery check.

[dac]

Fenix delivery check

Starting delivery check - setting check_apl_cmd and fenix_spectra_check running overnight.

[dac]

Fenix delivery check

Logsheet notes very poor signal for Fenix and probably not be worth processing. Data are indeed very noisy. Also, processing Fenix data for this flight is outside agreed processing costs. Not delivering

Apart from the SCT values for line 19 being off and the low signal everything else looked fine in the delivery.

[asm]

Lidar

Changed data quality remarks on readme for a more precise and descriptive sentence following lah suggestion.

[dac]

LiDAR

Updated readme text to read:

"This project has more than half of its flightlines flown over cloud. Clouds are visible in those lines as a cluster of points in the centre of the flightlines, which have been classified as noise (class 7). Due to the LiDAR pulses passing thorough clouds the density of surface returns is lower than would normally be expected. The intensity of received points is also lower than normal."

Ready to deliver.

[asm]

Delivery

Camera and LiDAR data dispatched via hard drive on 03/03/2016.

[dac]

Fenix

The PI has requested Fenix data be delivered despite low quality as fill in some gaps coverage from other flights.

A couple of points need addressing before delivering.

• Need to find correct SCT for 19
• Add note at top of readme about data quality and file in delivery to make it clear about the low data quality.

[lah]

Fenix DC

Everything looks ok, but I would change the readme warning to say that it is low quality due to low signal rather than low responses, as it is probably not a fault with the Fenix. Early morning start and lots of rain suggests that it's an illumination problem. Could also expand on low quality to say that the data overall appear rather noisy.

[stgo]

Fenix

Updated readme with a new warning message.

[stgo]

Fenix

Before I forget, the updated sct value was 0.20 for line 19

[stgo]

Delivery

Hyperspectral data sent on USB harddrive 24/03/2016

[asm]

Delivery

PI confirmed arrival of hyperspectral data on 31/03/2016

[dac]

Archiving

Data uploaded to CEDA at request of PI.

[dac]

Archiving

Data archived at CEDA. Closing ticket.