Process Lutan-1 stripmap SLC images using stripmapApp.py

[bjmarfito]

• Added Lutan-1 stripmap SLC reader
• Generate Lutan-1 stripmap interferograms using stripmapApp.py
• Ability to read orbit information from precise orbit files and annotation files
• Provided example XML files for Lutan-1 stripmapApp.py processing

[bjmarfito]

Request for review, @yunjunz

[piyushrpt]

Since this type of data is hard to get access to, if you feel like it is working with the datasets you have - should be fine to merge. I don't see the set of changes affecting other workflows.

[Arctic-Ambrun]

Good work. I see the difference between PHD students. I just have some Lutan-1 Datas, and I would like to assist the test after July.

[yunjunz]

Thank you @bjmarfito for making this happen! All looks good to me, except for the minor documentation above. Below are my local testing results for bookkeeping purposes using the LuTan-1 data for the 2023 Turkey earthquake, as shown in Xu et al. (2023) Fig. S24.

Running using the precise orbit works very nicely, including both the regular interferogram and dense offsets, which is great! The large invalid data shown in the figure is due to the improper frame cutting in the LT1 data, which is not a problem.

However, running using the rapid near-real-time orbits (from the SLC annotation file) seems to have issues: decorrelated bands along range direction, which we have also seen in the 2024 Hualien earthquake. I believe this is due to the issue in the rapid orbit data, will try to fix it with another PR.

Another desired feature is the frame stitching to process long tracks of LuTan-1 data, as we have discussed offline. Given that stripmapApp does not have this capability yet, we can do that in another PR in the future as well.

• stripmapApp.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<insarApp>
  <component name="insar">
    <property name="sensor name">LUTAN1</property>
    <component name="reference">
        <catalog>reference.xml</catalog>
    </component>
    <component name="secondary">
        <catalog>secondary.xml</catalog>
    </component>
    <property name="demFilename">
        <value>../DEM/demLat_N35_N42_Lon_E034_E041.dem.wgs84</value>
    </property>

    <property name="range looks">7</property>
    <property name="azimuth looks">4</property>
    <property name="filter strength">0.5</property>

    <property name="do rubbersheetingAzimuth">True</property>
    <property name="do rubbersheetingRange">True</property>

    <property name="do denseoffsets">True</property>
    <property name="do split spectrum">True</property>
    <property name="unwrapper name">snaphu</property>
    <property name="do dispersive">True</property>

  </component>
</insarApp>

• With precise orbits (regular interferogram & dense offsets)

• Without precise orbits (regular interferogram & dense offsets)

[piyushrpt]

The decorrelated bands appears to be an issue with inconsistent orbits- i.e inconsistency between position and velocity. You can possibly try using that by setting the orbit method to lagrange/ legendre in all modues rdr2geo , geo2rdr and geocode. By default it is hermite which expects good quality orbits.

[yunjunz]

The decorrelated bands appears to be an issue with inconsistent orbits- i.e inconsistency between position and velocity. You can possibly try using that by setting the orbit method to lagrange/ legendre in all modues rdr2geo , geo2rdr and geocode. By default it is hermite which expects good quality orbits.

Thank you @piyushrpt for the quick feedback, and previous help with the Fortran code issue of size. Will try your suggestion.

[bjmarfito]

Thank you @yunjunz for the review. I already committed the suggestions you made on this PR and for the suggestion in stitching multiple Lutan-1 frames. Thank you also @piyushrpt for suggesting using lagrange/legendre for orbit information from the annotation file.

Should we merge this PR first or incorporate the legendre/lagrange method in this PR, @yunjunz?

[yunjunz]

Yes, I think it's ready to be merged.

[domino20]

@bjmarfito @yunjunz Good to see you can get good results with precise orbit data. We did many tests on this data without precise orbit data last year.

1. We first try to process it following the stripmap.App procedure, just as what you did. The main problem is you cannot coregister the master and slave using the methods in stripmap.App, no matter what method you use, like the lagrange method on the orbit file. Even with the method gamma uses(1), you will have some problems. And In stripmap.App, they use topo and geo2rdr for coarse coregistration (If you do nothing to the orbit, the coarse coregistration result is really bad), and then ampcor for refine. But the ampcor in stripmapApp.py only get the same offset values for all the pixles...
2. Another problem is how they generate the ifg in stripmap.App. They use the range difference instead of substracting topo and flat-earth phase. The orbit info will play an import role in this way. Finally we switch to procedure of alos2App for processing.
   You can still try to use different ways to solve this problem. It will be nice to see how you manage it.

[EllenLee183]

@bjmarfito, Thank you for your support of Lutan data. I would like to try the differential interferometry processing of Lutan satellite. I wonder if you can provide the data in the code example?

[bjmarfito]

@bjmarfito, Thank you for your support of Lutan data. I would like to try the differential interferometry processing of Lutan satellite. I wonder if you can provide the data in the code example?

@EllenLee183, I can’t provide an example of Lutan-1 data for generating interferograms due to the agreement we have with the data provider.