| Version 11 (modified by benj, 17 years ago) (diff) |
|---|
Known processing problems
CASI data missing GPS sync
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.
"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), 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).
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.
Image looks straight but vector layers are not lined up
(amro comment)
If the image looked okay after modifiying the GPSOFF and then the vector layers did not line up, them it is better to modify the SCTOFF instead of GPSOFF. This will bring the vector layers to their places (e.g project 2006/206 line 1 , 4 , 5 )
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 recored 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.
Geocorrected flight line appears to be flown at wrong angle
This is probably due to an incorrect central meridian specified in azgcorr.
Failed to find GPS sync
(level 1 processing only - will not apply to external ARSF users if only processing level 1 data to level 3)
If azimport fails to find a GPS sync you must use the -sYS option to azimport to use a manual sync:
azimport ... -sYS 0 0 0 0 ...
This will allow processing to complete but will leave the GPS timing wrong (and will therefore put the line in the wrong place during geocorrection). To correct this, use an SCT (scan timing) offset by using the -so option to aznav:
aznav ... -so <sctoff> ...
Trial and error will need to be used to find the correct value for this (align the final results with either vectors for the target area or one of the other known good sensors for the same line), but it is suggested that you try an SCT offset of 13.9, 14.0 or 14.1 - one of these seems to be correct reasonably frequently (possible GPS delay error?).