Opened 6 years ago
Closed 3 years ago
#638 closed flight processing (fixed)
CA18/208, flight day 224b/2018, Ontario, Canada
Reported by: | dac | Owned by: | |
---|---|---|---|
Priority: | immediate | Milestone: | |
Component: | Processing: general | Keywords: | |
Cc: | Other processors: |
Description (last modified by dac)
Data location: /users/rsg/arsf/arsf_data/2018/flight_data/canada/CA18_207-2018_224b_Ontario
Data arrived from NERC-ARF via hard driver on 12/09/2018
Scientific objective: Canadian Wildfire Observations with SLSTR & Aircraft: Directional Effects of Thermally Emitted Radiation & Exploration of Flaming/Smouldering Partitioning and Plume Trace Gas Emission Ratios. Fenix and Owl data are being processed to aid geocorrection of other thermal sensors flown on the aircraft.
PI: Martin Wooster
BAS Project Code: D207
- Labelled as 224a (local) but renamed to 224b (UTC).
- Missing navigation synchronisation data and some files have incorrect FPS set
- Navigation data (.sol format) and level1b (unmapped) data to be delivered first. The level1b data will be used to determine which lines map.
Sensors:
- Fenix (requested, flown)
- Owl (requested, flown)
Change History (23)
comment:1 Changed 6 years ago by dac
- Description modified (diff)
comment:2 Changed 6 years ago by asm
comment:3 Changed 6 years ago by asm
Owl processing
Symlinked missing T2 owl files using existing ones for processing purposes and renamed the files according with the flightline number.
comment:4 Changed 6 years ago by asm
Owl Processing
Started in order to create the level1b files.
comment:5 Changed 6 years ago by wja
Navigation Processing
Basestation PPP identified as:
Latitude | 51°04'01.40097" |
Longitude | -93°48'14.27082" |
Ellipsoid Height | 346.814 |
comment:6 Changed 6 years ago by wja
Navigation Processing
Process GNSS/IMU with IPAS TC.
This looks like a boresight flight. Flightlines are all at different orientations centred over the basestation (presumably at the airport).
Solution looks good. Height position separation drifts around 0.1m for a period but nothing else is beyond that.
RINEX, GPB, PPP, SOL files put back in associated directories.
comment:7 Changed 6 years ago by wja
Owl Boresight
Currently finding SCT values.
comment:8 Changed 6 years ago by wja
Fenix Boresight
Processing Fenix data to help with SCT identification.
Flightlines 1 and 5 have the same start and end time in header files. End times have been updated with the creation times of the original headers.
comment:9 Changed 6 years ago by wja
Fenix/Owl Boresight
ASTER DEM was erroneous and causing issues with geocorrected data.
SRTM DEM has been produced.
comment:10 Changed 6 years ago by wja
Fenix/Owl Processing
SCT values:
Flightline | Fenix | Owl |
1 | TBA | 5.01 |
2 | 3.54 | 5.23 |
3 | 2.56 | 4.57 |
4 | 2.23 | TBA |
5 | 31.02 | 4.57 |
comment:11 Changed 6 years ago by wja
Fenix/Owl Boresight
Boresights from flights earlier in the year look okay:
Parameter | Fenix | Owl |
Pitch | +0.40 | +0.28 |
Roll | -0.76 | +0.17 |
Heading | +0.55 | +0.20 |
comment:12 Changed 6 years ago by wja
Fenix/Owl Processing
Creating delivery.
comment:13 Changed 6 years ago by wja
Fenix/Owl Delivery
Deliveries created for Fenix and Owl data respectively.
Logsheet is missing metadata, screenshots have been created as usual with the addition of /mosaic/ in the project directory which contains a georefernced mosaic (same format as flight 229).
Ready for checking.
comment:14 Changed 6 years ago by dac
Fenix delivery check
Starting delivery check
comment:15 Changed 6 years ago by dac
Fenix Delivery Check
- Mosaic in readme is labeled as owl
- Logsheet is lacking in details although it looks like we don't have this information from ops
- Processed using SRTM rather than standard ASTER, will make decision on if we should use SRTM for all data in Canada or stick with standard ASTER
- check_apl_cmd ran through fine
- Checked spectra using Py6S script and looked OK
If we decide it is OK to deliver using SRTM this is ready to go once readme has been fixed.
comment:16 Changed 6 years ago by dac
Owl Delivery Check
- Text for SRTM is wrong in readme, the v3 product was used which has a 1 arcsecond revolution (~ 30 m), will be the same for Fenix but missed it.
- SCT for line 5 looks a bit off (although not a problem, see next point)
- The data quality for lines 3, 4 and 5 is really bad, the spectra are completely smooth with no features, there is also no texture in the data and you can only see big changes in cover type. Given that there is Fenix data which can be used by the PI for geolocation these lines should be removed. If there was no usable Fenix data (e.g., night flights) would be different.
- Need better name for geolocated mosaic, suggest base on flightlines and use: o224b_mosaic_3b_mapped_utm15n.bil. Same for Fenix.
Will recheck once changes have been made.
comment:17 Changed 6 years ago by wja
Fenix/Owl Delivery Check
Owl and Fenix deliveries have been corrected.
It has been decided to use the SRTM DEM.
comment:18 Changed 6 years ago by dac
Fenix and Owl Delivery Check
Rechecked, requested changes have been made. Ready to deliver once Owl files have finished zipping up.
comment:19 Changed 6 years ago by wja
Fenix/Owl Delivery
Sent to PI via FTP slot 1.
comment:20 Changed 6 years ago by wja
Archiving
JSONs created and added to PostGIS. In the queue to rsync to CEDA.
comment:21 Changed 6 years ago by wja
Archiving
Started rsync to CEDA.
comment:22 Changed 6 years ago by wja
Archiving
Upload to CEDA complete (17/01/2019)
comment:23 Changed 3 years ago by dac
- Resolution set to fixed
- Status changed from new to closed
Unpacking checks
-There are 5 owl lines and 5 fenix, navigation files don't have timestamps. Will need to find SCTs manually.
-Only one T2 cal files (flightline 1). There is a different of 20 minutes between the first and last line so it is whithin the 30 minutes window that Specim suggests.
-1 dropped frame incident on owl line 1, another one in line Fenix 5
-Large differences in the fenix header files between fps to fps_qpf suggesting there might have been problems with the fps.