Terrain artefacts in los.rdr.geo?

[mjacqu]

Hi everyone,

I've been doing some work that requires the use of the incidence angle file generated by ISCE. I was expecting this file to just vary evenly across the image, showing a smooth progression across the image. The information found in los.rdr.geo.xml describes the content of this file as:

<property name="description">
        <value>['Two channel Line-Of-Sight geometry image (all angles in degrees). Represents vector drawn from target to platform. \n                Channel 1: Incidence angle measured from vertical at target (always +ve).\n                Channel 2: Azimuth angle measured from North in Anti-clockwise direction.']</value>
        <doc>Image description</doc>

This suggests to me that these values should be completely independent of topography, but this does not seem to be the case. Rather, there are strange discontinuities that correlate with topography. I see this in the files from different locations. In the example below, I am showing the first band, so incidence angle.

Can anyone provide insight into the reason for this, and how I might be able to get just incidence angle?

Many thanks,
Mylène

[EJFielding]

Hi Mylene,

You are right, the incidence angle layer in your los.rdr.geo file should not have those strange contours and variations. Does your interferogram look reasonable? Are you supplying your own DEM instead of using the SRTM DEM that is automatically downloaded in ISCE2? Those strange contours look like a DEM that was not read correctly, such as floating point numbers read as integers or byte-swapped or the wrong file format.

[mjacqu]

Hi Eric,

Many thanks for your reply, it may come just in time! The interferograms generally look very presentable and I am picking up on deformation where I know it is. In one case there were strange artefacts though, that I haven't been able to explain. I wonder whether those might also be connected to this issue. In all cases, I am supplying my own DEM because SRTM doesn't cover the region or recent terrain changes are not reflected in it. The DEMs typically come as GeoTiffs that I convert to ENVI file format using gdal and run gdal2isce_xml.py. Here's an example xml file. What does ISCE expect, or what would I look for to figure this out?
HMA_wgs84.wgs84.txt

Many thanks,
Mylène

[EJFielding]

The gdal2isce_xml.py script should write the file in the format that ISCE expects. I would check whether the file is in integers or floating point values. Your HMA_wgs84.wgs84.txt says the file is in floating point values.

There is an additional issue about the vertical datum for your user-supplied DEM. Did the HMA DEM have a geoid-based datum like EGM96 or EGM2008 or was it relative to the WGS84 ellipsoid datum already? I see the filename says "wgs84" so maybe it was in ellipsoid heights. This should not have a big effect and cause the strange pattern. The difference between the geoid and the ellipsoid in the Himalayas is around 80 meters, so it could cause small errors.

[mjacqu]

Thanks Eric! I just ran the same area with the automatically downloaded SRTM DEM. Interestingly the issue remains, or rather, it gets worse. I am running ISCE version 2.5.3.
Take a look:

I have compared the effect of geoid vs. ellipsoid, it doesn't seem to effect the results much given that I am usually looking at a really small area, but I do try to apply the correction if I use a DEM that is in geoid heights.

Any other thoughts? I'm really grateful for your help!

[EJFielding]

The SRTM v3 DEM has huge errors in some parts of the Himalayas, with elevations off by hundreds of meters. When the los.rdr file is geocoded, the DEM errors could cause large shifts of the incorrect patches.

The NASADEM has quite a few improvements in the Himalayas. You can download that with the ISCE2 dem.py option for type.
Another DEM that I found was much better than either NASADEM or SRTM v3 is the newly released Copernicus GLO30 DEM. That has fewer large errors in areas of steep slopes.

[EJFielding]

I would look at the DEMs in QGIS or with mdx.py to see if there are large discontinuities. The errors in SRTM and NASADEM tend to be patches that have incorrect elevations.