| Version 3 (modified by benj, 15 years ago) (diff) |
|---|
Q: Why does azgcorr say "DEM does not enclose the image" and then stop, and how do I fix it?
A:
The usual cause for this is exactly what it says - the hyperspectral imagery is not entirely covered by the DEM you're using. This problem is often caused by using LiDAR data from the same flight where either the LiDAR was switched off before the hyperspectral sensors (or on afterwards), or else the LiDAR was running in narrow-swath mode and the LiDAR swath is narrower than the hyperspectral swath. If it's the former then all of the affected data should be outside your area of interest unless the LiDAR actually failed during the line and you can safely use solution 3 below. If it's the latter then you will need to use one of the other solutions given below.
You can check what azgcorr thinks the relative limits are by looking for the following sections in your run log:
Site details... input lines to be processed: 6035 corrected image pixels : 5520 lines: 3565 limits from scans x: 392563.7 403599.0 y: 7095299.4 7102425.7 pixel/line limits x: 392562.0 403600.0 y: 7095298.0 7102426.0
DEM file: /arsf/214a/dems/a_dem_100.grd
limits SW: 389033.0 7095665.0 NE: 401403.0 7103967.0
You can then compare the DEM limits to the imagery limits. The south and west limits of the DEM file should be smaller than the smallest y and x limits for the imagery, and the north and east limits should be larger than the largest ones. In this case it can be seen that azgcorr thinks the DEM doesn't extend south far enough (by ~400m - 7095665 compared to 7095298) or east far enough (by ~2km - 401403.0 compared to 403600.0). It is OK in the north and west dimensions.
There are a few possible solutions to this:
- Extend your DEM coverage using external datasets such as NextMap for the UK or SRTM outside the UK. Depending on where your flight is, this may not be an option since SRTM only covers the area between 54S and 60N. If you do this, be careful about using data in the correct projection and datum (both vertical and horizontal) to match your data. Our LiDAR data is typically supplied processed against the WGS84 ellipsoid. NextMap is in British National Grid projection and therefore uses the Ordnance Datum Newlyn vertical datum. SRTM uses the EGM96 geoid as the vertical datum.
- Use a program such as GRASS to extrapolate DEM coverage beyond your current coverage. Gives you a DEM that is essentially completely made up for part of it, but since it's hopefully at approximately the right height (and therefore shouldn't cause significant distortion in the output), you may not mind. It may also only to affect one end of one or two flightlines (which may be beyond the area you're interested in).
- Use the -l option to azgcorr to not process one end of the affected line(s) - see part 2 here for instructions for how to do this. You can then process the area within your DEM, and then if you want you can process the remaining part separately without using a DEM.
- Just process the entire flightline without using a DEM. This is the easiest solution, but will deform your output image (typically it will magnify the image, largely in the across-track direction) because of the difference between the real and assumed height of the ground.
Related articles: