Output DEM included with RTC/InSAR products potentially has invalid data in areas where DEM data was not needed for processing

[asjohnston-asf]

The DEM included via the --include-dem option for InSAR and RTC jobs has the same spatial extent as the other output products. However, the DEM geotiff is built from only DEM tiles that overlap areas of data, and therefore can have invalid data in the corners where DEM data was not needed for underlying processing.

This example is for S1A_IW_SLC__1SDH_20200307T133427_20200307T133455_031570_03A324_C47F . The output DEM (pictured with the backscatter geotiff overlayed) has an area of invalid data in the upper left of the image.

This issue does not impact RTC/InSAR processing, but has the potential to impact workflows that use the DEM included with the output products.

[asjohnston-asf]

This is potentially resolved by fetching all DEM tiles that intersect the envelope of the scene's geometry (instead of the geometry itself) at https://github.com/ASFHyP3/hyp3-gamma/blob/develop/hyp3_gamma/dem.py#L103

The naive implementation using ogr.Geometry.GetEnvelope() will have issues with the antimeridian, however.

[asjohnston-asf]

@cirrusasf notes that these invalid data in the DEM also create corresponding artifacts in the local incidence angle map.

[jhkennedy]

To illustrate:

Here we see the RGB decomp of the scene overlaid on the output (cropped) DEM GeoTIFF provided with a RTC product, as well as the relevant geometries. When we grab the DEM, we use the preview KML provided with the SLC/GRD (yellow box), buffer it out 0.15 degrees (orange box), and intersect that withe the DEM tiles (green box). We then build a VRT for only the DEM tiles that intersect the buffered preview KML, so the the DEM TIF is showing nodata in the lower-left corner as that DEM tile doesn't intersect our buffered KML geometry.

If instead we tooK the envelope of the KMZ, we'd be using the DEM tif's shape, effectively. We likely would still want to buffer that by 0.15 degrees fro GAMMA processing.