Known processing problems

The following is a list of processing problems that will be encountered by internal users or by any user. Some issues here are no longer relevant but remain for legacy.

Internal User Problems

CASI data missing GPS sync

(Note... same problem for Eagle/Hawk further down)

If you're seeing azgcorr failing with ** read error on SCO input and, earlier in the output, azcaschk2 is reporting:

GPS message time to CASI clock time difference(s)...
  del_t : 
  freq  : 
  most frequent gap is: 0  secs

** NO (or insufficient) GPS messages or sync pulses
**    ... no sync saved

This means the CASI data files are missing the GPS sync markers (or azcaschk2 can't find them). As a consequence, scans can't be tied to navigation and azgcorr has nothing to work with. Typically, you'll be able to get the file to level 1 without problems, but level 3 can't be done.

To work around the lack of GPS sync, azcaschk2 allows you to use "frame headers" for sync instead. You need to add -FRsync to the azcaschk2 command line.

This should then process through to level 3, though you may need to correct for navigation timing.

Errors in aznav interpolation stage

These can occur (particularly with CASI) when there is a large offset between the site time limits and the ones on the file. azimport will pull in the section of the navigation data according to the file limits and the actual required navigation may be outside this range. A typical error looks something like:

*** DPspline2D no returned vectors  spl_err: 1  slpp 1: -2.4420659 n: 1.9638544
  in  len: 82201   time[0]: 42062.001400  [82200]: 42472.997200
  out len: 11667   time[0]: 42603.547100  [11666]: 43011.876100
  in time vector:
 42062.001400 ...

  out time vector:
 42603.547100 ...

** end of DPspline2D error print

** lat+lng interpolation, vectors incomplete
** should be from index: 0 to index: 11666
** valid data only from idex: 0 to index: 0

To fix this, forcibly specify the time range you want to insert navigation data for with azimport -t JJJ HHMMSS HHMMSS ... (JJJ = Julian date, then the start and end times from the logsheet, plus a few minutes), e.g. azimport -t 261 110000 111000 ... for day 261 11:00:00 to 11:10:00.

---

Incorrect fps in hdr file

When a flight line appears to to be squashed or stretched along track, the problem may be due to an incorrect fps value recorded in the hdr file for that flight line. This can easily be solved by editing the fps field to the correct value. Typical value can be found by checking hdr files from other flights. Note this should have been picked up at unpacking - if it has failed to pick this up fix it

---

Failed to find Eagle/Hawk GPS sync

(level 1 processing only - will not apply to external ARSF users if only processing level 1 data to level 3)

Firstly, check the header file for the affected flightline. Sync problems are sometimes caused by the start time for the line being recorded incorrectly. If it's obviously wrong, copy the start time from the other sensor (or estimate from the logsheet if both are affected - if you do this you will have to fiddle with it later to get it right).

Failing that, the option we usually use to manually set sync that's been irretrievably lost is the -sSE option to azspec:

azspec ... -sSE ...

Once you've done that then you need to not call azimport to import the sync (won't work), though you still do need to call it to import the applanix navigation.

Once that's run through, because it won't have sync it will be in the wrong place. Use the -so <offset> option to aznav to move it along the line to the right place:

aznav ... -so <sct_offset>

This is trial and error, takes a while sometimes (align the final results with either vectors for the target area or one of the other known good sensors for the same line). The offset is in seconds, it's usually in the 14-15 second range if we've had to use -sSE, but will probably go up to 15-16 seconds from 2009 (presumably it's the sync offset to the nearest second plus the GPS-UTC adjustment of 14 seconds... it's 15 now, but for all the data we've got from 2008 and earlier it will be 14).

Finally, doing that will shift a little bit of the data off the end of the flightline and you'll lose it. To recover this, take the offset you found in the previous step and add it on to the start time in the header file (we also add it to the end time, but actually I'm not sure that's necessary). You may want to back the header up first, or at least make a note of the old value. Once you've done that, re-run the processing with the -sSE option to azspec but with the -so option to aznav set to 0 (or omitted).

---

Any User

"profile buffer exceeded" - Invalid DEM

If, in the azgcorr output, you see output like:

 ** profile buffer exceeded at: 0 points

 ** profile buffer exceeded at: 0 points

(repeated many times)

This indicates a problem with the DEM. Typically, this would either mean that the DEM wasn't read correctly (check format - did you add the azgcorr header?), doesn't cover the area (check site limits for image and DEM in azgcorr output) or has invalid values in it (e.g. NULL values are a '*' - replace these with 0 or the invalid data value).

This may also occur if the limits of the DEM are not given in the header as integer values.

---

Correcting bands: x bad scan ends after DEM st: 1962.00 en: 1960.00 inc: 2.00

Occurs in azgcorr if the DEM contains '*' for null values. Change the '*' to 0 in the DEM using the following command: cat olddem.dem | sed 's/\*/0/g' > newdem.dem

---

azgcorr "HDF internal error opening file"

When running azgcorr, it immediately quits with something like:

** HDF internal error...
HDF error: (7) <Error opening file>
        Detected in Hopen() [hfile.c line 381]

This will have various causes, including corrupt/inaccessible HDF files, but a particularly nasty one is that you must have write permission on the (casi, untested on others) HDF to be able to run azgcorr on it, even if nothing about the HDF will be changed.

---

Complaining about geoid-spheroid correction when there is none present

** out of geoid-spheroid grid at c: -97 r: 110  cols: 83  rows: 90
** rerun with full grid

** DEM fatal error...
** image corner out side geoid/spheroid limits
** lat min: 49.75000 max: 60.87500 lng min: -7.50000 max: 2.75000
** corner x: 569880.0 y: 7053870.0 lat: 63.60591 lng: -19.59104
** gsep data covers UK only

You need to add -es NO argument to azgcorr command if there is no geoid-spheroid separation file needed.

---

Incorrect fwhm & Wavelength format in header file

*** stack smashing detected ***: azspec terminated
** ======= Backtrace: =========
** /lib/libc.so.6(__fortify_fail+0x4d)[0x5e717d]
** /lib/libc.so.6[0x5e712a]
** azspec[0x8056716]
** azspec[0x8054285]
** azspec[0x8051257]
** azspec[0x80539dd]
** azspec[0x804c368]
** /lib/libc.so.6(__libc_start_main+0xe6)[0x506bb6]
** azspec[0x8049501]

If the fwhm or the wavelength fields in the header file are not one value per line, even if they are separated by commas then that needs correcting.