Changes between Version 19 and Version 20 of Processing/KnownProblems


Ignore:
Timestamp:
Feb 28, 2012, 2:47:38 PM (14 years ago)
Author:
mark1
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Processing/KnownProblems

    v19 v20  
    11= Known processing problems =
     2
     3The following is a list of processing problems that will be encountered by [#internalusers internal users] or by [#anyusers any user]. Some issues here are no longer relevant but remain for legacy.
     4
     5== Internal User Problems ==#internalusers
    26
    37== CASI data missing GPS sync ==
    … …  
    4448To 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.
    4549
    46 ---------------------
    47 
    48 == "profile buffer exceeded" - Invalid DEM ==
    49 
    50 If, in the azgcorr output, you see output like:
    51 {{{
    52  ** profile buffer exceeded at: 0 points
    53 
    54  ** profile buffer exceeded at: 0 points
    55 
    56 (repeated many times)
    57 }}}
    58 
    59 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).
    60 
    61 This may also occur if the limits of the DEM are not given in the header as integer values.
    62 
    63 
    64 
    65 ---------------------
    66 
    67 == azgcorr "HDF internal error opening file" ==
    68 
    69 When running azgcorr, it immediately quits with something like:
    70 {{{
    71 ** HDF internal error...
    72 HDF error: (7) <Error opening file>
    73         Detected in Hopen() [hfile.c line 381]
    74 }}}
    75 
    76 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.
    77 
    78 ---------------------
    79 
    80 == Image looks straight but vector layers are not lined up ==
    81 (amro comment)
    82 
    83 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 )
    8450
    8551---------------------
    … …  
    8753== Incorrect  fps in hdr file ==
    8854
    89 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.
     55When 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'''
     56
    9057
    9158---------------------
    9259
    93 == Geocorrected flight line appears to be flown at wrong angle ==
    94 
    95 This is probably due to an incorrect central meridian specified in azgcorr.
    96 
    97 ---------------------
    9860
    9961== Failed to find Eagle/Hawk GPS sync ==
    … …  
    12183Finally, 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).
    12284
     85
     86---------------------
     87
     88== Any User ==#anyuser
     89
     90== "profile buffer exceeded" - Invalid DEM ==
     91
     92If, in the azgcorr output, you see output like:
     93{{{
     94 ** profile buffer exceeded at: 0 points
     95
     96 ** profile buffer exceeded at: 0 points
     97
     98(repeated many times)
     99}}}
     100
     101This 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).
     102
     103This may also occur if the limits of the DEM are not given in the header as integer values.
     104
     105------------------------
     106
     107== Correcting bands: x ** bad scan ends after DEM st: 1962.00 en: 1960.00 inc: 2.00 ==
     108
     109Occurs in azgcorr if the DEM contains '*' for null values. Change the '*' to 0 in the DEM using the following command:
     110{{{cat olddem.dem | sed 's/\*/0/g' > newdem.dem}}}
     111
     112
     113---------------------
     114
     115== azgcorr "HDF internal error opening file" ==
     116
     117When running azgcorr, it immediately quits with something like:
     118{{{
     119** HDF internal error...
     120HDF error: (7) <Error opening file>
     121        Detected in Hopen() [hfile.c line 381]
     122}}}
     123
     124This 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.
     125
     126---------------------
     127
    123128== Complaining about geoid-spheroid correction when there is none present ==
    124129
    … …  
    134139}}}
    135140
    136 You need to add `-es NO` argument to azgcorr_args_extra if there is no geoid-spheroid separation file needed.
     141You need to add `-es NO` argument to azgcorr command if there is no geoid-spheroid separation file needed.
    137142
    138 == Correcting bands: x ** bad scan ends after DEM st: 1962.00 en: 1960.00 inc: 2.00 ==
     143------------------------
    139144
    140 Occurs in azgcorr if the DEM contains '*' for null values. Change the '*' to 0 in the DEM using the following command:
    141 {{{cat olddem.dem | sed 's/\*/0/g' > newdem.dem}}}
    142145
    143146== Incorrect fwhm & Wavelength format in header file ==