topsApp - Geocoding over antimeridian

[mgovorcin]

ISCE2 version: 2.5.3

Issue related to: topsApp.py and antimeridian

Description of problem:

1. ISCE finds overlap between DEM and SLCs, at the antimeridian on West and DEM extent on East, the data on another Hemisphere are discarded. This makes it not possible to process full SLC frame at once.

2. Geocoding wraps raster outputs around the Globe as SLCs are crossing the antimeridian (-180/180 longitude), creating large output rasters with >100k pixels in width.

   

   Note: black line is an output .geo raster from ISCE

Zoomed image to AOI

Masked

Details:

SAR scenes: Reference: S1B_OPER_AUX_POEORB_OPOD_20210318T152602_V20201214T225942_20201216T005942.EOF Secondary: S1B_OPER_AUX_POEORB_OPOD_20220111T111621_V20211221T225942_20211223T005942.EOF

topo.Overall bounding box = [50.398, 52.576, -179.999, 179.999] SLC scenes cross over the antimeridian (-180/180 longitude)

DEM: Copernicus GLO-90 downloaded using dem-stitcher, with the new update dem-stitcher wraps downloading and merging tiles crossing anti meridian. The selected bounds for downloading DEM are [-185.0, 50., -175.0, 54.]

<?xml version="1.0" encoding="UTF-8"?>
<topsApp>
  <component name="topsinsar">
    <component name="reference">
      <property name="orbit directory">SLC</property>
      <property name="auxiliary data directory">/Users/agram/orbit/S1A/aux</property>
      <property name="output directory">reference</property>
      <property name="swath number">2</property>
      <property name="safe">SLC/S1B_IW_SLC__1SDV_20201215T054451_20201215T054521_024709_02F04A_6033.zip</property>
    </component>
    <component name="secondary">
      <property name="orbit directory">SLC</property>
      <property name="auxiliary data directory">/Users/agram/orbit/S1A/aux</property>
      <!-- <property name="region of interest">[51.2, 51.9, -179.25, -178.5]</property>-->
      <property name="output directory">secondary</property>
      <property name="swath number">2</property>
      <property name="safe">SLC/S1B_IW_SLC__1SDV_20211222T054456_20211222T054526_030134_039920_9391.zip</property>
    </component>
    <property name="demFilename">isce_dem/full_res.dem.wgs84</property>
    <property name="range looks">19</property>
    <property name="azimuth looks">7</property>
    <property name="filter strength">0.5</property>
    <property name="swaths">[1,2,3]</property>
    <property name="esd coherence threshold">-1</property>
  </component>
</topsApp>

It appears that ISCE finds a common area between SLCs and DEM as selecting the aoi from antimeridian -179 to East extent of DEM -175 and runs the topsApp processing to the end. This means that the data on another (East) Hemisphere were discarded (not considered in isce.zerodop.topozero) for processing.

The topsApp runs to the end but in the last stage (geocoding) it wraps the outputs around the Globe (see figures above).

[cmarshak]

Tagging @dbekaert @sssangha @gracebato @jhkennedy.

I wanted to echo the above. With our Access project, we are trying to process over the Aleutian volcano chain and found this issue.

Our xml looked nearly identical:

<?xml version="1.0" encoding="UTF-8"?>
<topsApp>
  <component name="topsinsar">
    <component name="reference">
      <property name="orbit directory">orbits</property>
      <property name="auxiliary data directory">aux_cal</property>
      <property name="output directory">reference</property>
      <property name="safe">['S1B_IW_SLC__1SDV_20211222T054456_20211222T054526_030134_039920_9391.zip']</property>
    </component>
    <component name="secondary">
      <property name="orbit directory">orbits</property>
      <property name="auxiliary data directory">aux_cal</property>
      <property name="output directory">secondary</property>
      <property name="safe">['S1B_IW_SLC__1SDV_20201215T054451_20201215T054521_024709_02F04A_6033.zip']</property>
    </component>
    <property name="swaths">[1, 2, 3]</property>
    <property name="range looks">19</property>
    <property name="azimuth looks">7</property>
    <property name="filter strength">0.5</property>
    <property name="region of interest">[50.399727, 52.575905, -181.35786111767942, -177.2720415305902]</property>
    <property name="demFilename">full_res.dem.wgs84</property>
    <property name="geocodeDemFilename">low_res.dem.wgs84</property>
    <property name="do unwrap">True</property>
    <property name="unwrapper name">snaphu_mcf</property>
    <property name="do ESD">False</property>
    <property name="ESD coherence threshold">-1</property>
    <property name="use virtual files">True</property>
    <property name="geocode list">['merged/phsig.cor', 'merged/filt_topophase.unw', 'merged/los.rdr', 'merged/topophase.flat', 'merged/filt_topophase.flat', 'merged/filt_topophase_2stage.unw', 'merged/topophase.cor', 'merged/filt_topophase.unw.conncomp']</property>
  </component>
</topsApp>

Here is a link to a low resolution DEM (90 meter) that is "unwrapped" over the dateline for the above SLC pairs and referenced in our xml.

low_res.dem.wgs84 low_res.dem.wgs84.vrt low_res.dem.wgs84.xml

Could use the above DEM for both required by XML for understanding the issue caught above.

We are tracking this issue here: https://github.com/ACCESS-Cloud-Based-InSAR/DockerizedTopsApp/pull/81

Note the environment and ISCE version is determined by the environment file in this wrapper for topsApp. When building the virtual environment locally, I checked that we are using ISCE2 version 2.6.1.