Version 41 (modified by knpa, 13 years ago) (diff)


Eagle/Hawk Processing Guide

This guide describes how to process hyperspectral data using the apl suite. This should be used for 2011 data onwards. If you are processing earlier data, see here for instructions for processing with the az suite.

The apl suite consists of the following programs: aplcal, aplnav, apltran, aplmap.

Before starting, make sure the navigation is processed and all raw data is present and correct.


To return sensible results for all but very flat areas, you will need a dem. One should have already been completed in the unpacking stage. If not, it will need to be created. For the UK, use NextMap. Otherwise use ASTER. If you can't use ASTER for some reason, then you can also create one from our own LiDAR using

Creating config file

This file will be used to automatically generate the commands necessary to process your hyperspectral lines.

If no config file exists (in <proj_dir>/processing/hyperspectral) then, in top project directory, run: -s s -n <numlines> -j <jday> -y <year>

This should generate a config file based on the raw data and applanix files, and output it to the processing/hyperspectral directory.
Go through carefully and check everything is correct. Most notably:

  • project_code
  • dem and dem_origin
  • transform_projection is correct for the data

If using SBETs from IPAS to process the hyperspectral make sure to use these lever arm values (referenced from pav80 not GPS antenna. They should be automatically selected according to the year but best to check):

Eagle : 0.415 -0.014 -0.129
Hawk : 0.585 -0.014 -0.129

And use these boresight values (PRH):

Eagle : -0.322 0.175 0.38
Hawk : -0.345 0.29 0.35

Submitting processing to gridnodes

To submit jobs to the grid, from the top level directory use: <config_file>

The actual script which does the processing of each job is:

Once submitted, you can keep an eye on your jobs using qmon.

Individual processing stages

You shouldn't have to worry about this unless something goes wrong. However something often does! Detailed explanation of each step is explained here


If you have any problems, check the files created in logs e.g.


The last part of the name is the grid node job number.
Check these for errors (look for stars). Common problems are listed here, along with possible solutions.


The script will have produced 21 iterations of each flightline, with a range of sct values. SCT is a timing offset which affects the position and geometry of the image. Currently they range from -0.1 to 0.1 seconds. A tiff will have been produced for each version, you will need to go through these using gtviewer and find the image that looks correct, and note down the sct value. You usually determine the correct image by the amount of wobble in the image. Lines with an incorrect offset will cause kinks in straight lines such as roads where the plane trajectory wobbles. Selecting the image with the straight road is usually what is required.

Create final files

The stage that creates the geolocated tiff's that you use to find SCTs, deletes the original level 1 files after it's finished. You therefore need to use the config one more time to generate the full set of files for each flightline, using the correct SCT value. To do this, change the sctstart and sctend values so they are both the correct figure, then run again in the global section set slow_mode = true. Running this with will once again submit your lines to the gridnode and you should soon have all the files you require to make a delivery.

Making a delivery

Use the script to make the delivery directory. Run it from within the main project directory. By default it runs in dry run mode.

Use --final if happy with what it says it will do. Use -m <config> to generate screenshots and mosaics

To make the readme file use the script:

This page details the old manual way for creating the delivery and Readme.