Misalignment of bursts on ascending track

[SofiViotto]

Dear community,

I am working with Sentinel-1 data over NW Argentina. I have noticed that the ascending tracks near the geomagnetic equator are frequently affected by burst misalignment, making those tracks difficult to use. Additionally, I have observed that when dealing with NESD for the stackSentinel for TOPS, the presence of non-uniform misalignments in the burst overlap can contaminate the registration of the entire stack (see article https://ieeexplore.ieee.org/abstract/document/7637021 ). This issue seems to persist even with geometric alignment.

I suspect this problem may be related to the ionosphere since coherence is generally not an issue in dry areas. I have attached some screenshots showing clear misalignments in the bursts, from two different areas but close each other and from the same track (Asc-T76).

Given this context and the potential ionospheric influence, I have a few questions:

1. Assuming this is an ionospheric effect, would it be advisable to implement BESD (Bivariate Enhanced Spectral Diversity) in the stack processing to address burst misalignment? (see article https://ieeexplore.ieee.org/abstract/document/8114326)
2. Images from the years 2014-2016 and from 2022 onwards are expected to be more affected by this problem, and assuming again that the problem is related to the ionosphere. Is there a recommended method to eliminate or mitigate this issue?

I believe solving this problem is crucial for producing long-term stacks of interferograms from ascending tracks.

I look forward to hearing your thoughts on this issue.

Best,
Sofia

[piyushrpt]

This looks like the issues that were addressed in https://ieeexplore.ieee.org/abstract/document/8706258 . Have you tried using the features that @CunrenLiang and others have already implemented in topsApp and topsStack?

[piyushrpt]

It's hard to know if the steps followed were right but there are a couple of very simple checks:

1. Make sure that z.rdr /inc.rdr is aligned with your reference SLC. If they are not, I suspect the issue is not in S1 metadata but in the DEM setup. I would check lat/lon specified in the XML. GDAL geotrans and what is needed for ISCE should be off by half a pixel - unless this was applied, I would expect a shift.

2. Verify that values corresponding to randomly selected pixel in lat.rdr, lon.rdr and z.rdr are what you expect in the custom DEM file that you built. If the heights are offset by magnitude of geoid height - then there may be double correction. Check the reference tag in dem.xml file - it should be WGS84 if its already been corrected.

If you still see these, then these are most likely tropospheric contributions. I think you are mixing up effects of azimuth misalignment. Those will not generate artifacts that you are pointing to. They just show small phase offsets at burst boundaries - not these types of artifacts that follow topography.

[SofiViotto]

Hi again,
Thanks for your reply!

I have updated the first example.

In my first post and in the following ones, I always refer to what you call features in the burst overlap. I know they are small offsets; in fact, I have detected and measured them.

But if we think for a moment, if I have 9 bursts overlapping and each one represents, let's say, a small phase jump of 0.2 mm in a particular unwrapped interferogram, that means that between the first burst and the last one, there is a phase difference of 0.2 * 9 = 1.8 mm, only related to jumps between bursts. In a stack with multiple interferograms, several of them having small phase jumps, this would result in a signal along the azimuth direction. If the signal we intend to study is much larger than that, then there is no problem. However, if the signal is tectonic and its magnitude is small, those small phase jumps in the burst overlapping area are a problem.

In my area, small offsets between bursts are characteristic of ascending tracks, not descending ones. I don't see or detect them at all for the descending track.

If we have a phase jump in the burst overlap areas, this is (to my understanding) a misalignment, since the previous steps, NESD and geometric alignment, should prevent it. What do you think?

I'll check the DEM again.

Thanks again for discussing this topic with me!

Best,
Sofia

[SofiViotto]

Hi,
About the first check

Verify that values corresponding to randomly selected pixel in lat.rdr, lon.rdr and z.rdr are what you expect in the custom DEM file that you built. If the heights are offset by magnitude of geoid height - then there may be double correction. Check the reference tag in dem.xml file - it should be WGS84 if its already been corrected.
So, I have corrected the Copernicus DEM before using it in ISCE and after I run the fixXmlImage.py command, the XML file states:

GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]

Whereas gdalinfo of such DEM provides the following information:
dalinfo Copernicus_DSM_S20_S29_W062_W069_30m_int16.wgs84.dem Driver: ISCE/ISCE raster Files: Copernicus_DSM_S20_S29_W062_W069_30m_int16.wgs84.dem Copernicus_DSM_S20_S29_W062_W069_30m_int16.wgs84.dem.aux.xml Copernicus_DSM_S20_S29_W062_W069_30m_int16.wgs84.dem.xml Size is 28801, 36001 Coordinate System is: GEOGCRS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84",6378137,298.257223563, LENGTHUNIT["metre",1]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433]], CS[ellipsoidal,2], AXIS["geodetic latitude (Lat)",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433]], AXIS["geodetic longitude (Lon)",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433]], ID["EPSG",4326]] Data axis to CRS axis mapping: 2,1 Origin = (-69.000138888888884,-18.999861111111112) Pixel Size = (0.000277777777778,-0.000277777777778) Metadata: AREA_OR_POINT=Area Corner Coordinates: Upper Left ( -69.0001389, -18.9998611) ( 69d 0' 0.50"W, 18d59'59.50"S) Lower Left ( -69.0001389, -29.0001389) ( 69d 0' 0.50"W, 29d 0' 0.50"S) Upper Right ( -60.9998611, -18.9998611) ( 60d59'59.50"W, 18d59'59.50"S) Lower Right ( -60.9998611, -29.0001389) ( 60d59'59.50"W, 29d 0' 0.50"S) Center ( -65.0000000, -24.0000000) ( 65d 0' 0.00"W, 24d 0' 0.00"S) Band 1 Block=28801x1 Type=Int16, ColorInterp=Undefined Min=81.000 Max=6727.000 Minimum=81.000, Maximum=6727.000, Mean=1962.740, StdDev=1740.405 Metadata: STATISTICS_APPROXIMATE=YES STATISTICS_MAXIMUM=6727 STATISTICS_MEAN=1962.7396392758 STATISTICS_MINIMUM=81 STATISTICS_STDDEV=1740.40513619 STATISTICS_VALID_PERCENT=100

How can I do this?:

Make sure that z.rdr /inc.rdr is aligned with your reference SLC. If they are not, I suspect the issue is not in S1 metadata but in the DEM setup.

Best,
Sofia

[piyushrpt]

The 9 bursts * 0.2mm makes no physical sense to me and that is not what happens when there is a burst timing error/ misalignment. I think you may want to revisit the papers on ESD and actually understand what the resulting phase offset looks like in azimuth looks like due to misalignment.

You are still using GDAL only - which could be the source of the problem. Download one raw SRTM tile and run gdalinfo on it. Lets say left edge of the tile is -60 - you will see it report -60.00013888888889 whereas the actual text in the ISCE XML file should be -60.0. Just using gdalinfo doesn't solve your issue. Check the numerical values in the xml file and make sure that they have the right values in pixel_is_point convention. GDAL uses pixel_is_area convention. I don't think the ISCE driver in GDAL understands these subtleties.

[SofiViotto]

Hi again,
Thanks again for your ideas!

I checked the Copernicus DEM:

1. The heights are above the WGS84 ellipsoid, in int16 format.
2. You were right; the coordinates as they appear in the DEM's XML file are not rounded. Should I round them?
   <property>name="xmax"> <value>-60.999815822</value> <doc>Maximum range value</doc> </property> <property name="xmin"> <value>-69.0001</value> <doc>Minimum range value</doc>

However, luckily for me, I had processed the same area with the same images using SRTM (prepared through ISCE, round coordinates in the XML file). However, I encountered the same problem after using SRTM. See the example below, which corresponds to an interferogram from a stack created with SRTM as the DEM, and the same created with Copernicus DEM. The reference image of the stack (during the processing stage with ISCE2) is the same. The interferogram from SRTM covers a smaller area than the Copernicus one, so I have indicated the approximate position of the example from SRTM within the area of the example from Copernicus with a black rectangle. The discontinuities are quite obvious in the coherence as well.

We can also rule out a processing error, as I have reprocessed most of these stacks several times after noticing the burst overlap discontinuity or offset. Since those offsets appear repeatedly in the same pairs, what are the chances that a process would fail more than three times?

Again, thank you for all your comments and ideas.
Best,
Sofia

[piyushrpt]

1. Yes, you need to round them out since ISCE expects pixel_is_point convention in the XML files. You can see how isce automatically builds the DEM file vs manually building the DEM using the same steps you followed from an SRTM tile.
2. I still don't understand what you mean by phase offset in the figures. You just seem to be pointing out regions where phase goes from -pi to +pi. You are interpreting the color change from blue to red as a phase jump? +pi/-pi are adjacent in terms of wrapped phase - so I don't understand why you are interpreting these as discontinuities. jet or non-cyclic colormaps are bad for visualizing wrapped interferograms. Choose a cyclic colormap like hsv or the one in mdx/ mintpy to visualize wrapped interferograms.

[CunrenLiang]

For ionospheric correction, since we are only able to get a smoothed version of the ionosphere, we are not able to remove burst discontinuities precisely. In general, however, the burst continuities should be smaller after applying ionosphere correction. This is clear if you do time series analysis, e.g.
https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2022GL099835

[fdelgadodelapuente]

Hi Sofia,

My group routinely process Sentinel-1 time series in the Salar de Atacama region northern Chile and we also observe lots of discontinuities between bursts (phase jumps), like you do. These are very likely ionospheric. If you do observe them only in ascending data, but not in descending data that is because ascending data is acquired at dusk (23 GMT) when there are lots of solar radiation interacting with the ionosphere, while descending data is acquired just before the sunrise (09 GMT) when there is less solar radiation and the ionospheric TEC is smaller. It is the same reason why ascending data is more turbulent than descending data, at least for South America.

In terms of corrections you can do several things. For individual interferograms the following three flags in the topsApp.py input file take care of both the dispersive phase that results in a long wavelength ramp and the phase jumps between the bursts after the ESD correction

<property name="do ionosphere correction">True</property>
    <property name="apply ionosphere correction">True</property>
<property name="consider burst properties in ionosphere computation">True</property>

The first two flags are for the dispersive phase while the last one is for the phase jumps

If you use the TOPS stack processor with the flag for the ionospheric correction, it only corrects for the dispersive phase, not the phase jumps. Therefore, in Liang et al 2019 in Northern Chile they processed the data with topsApp.py instead of the stack processor (Cunren and Piyush, please correct me if I'm wrong).

Since not all the corrections are implemented in all the workflows, in Northern Chile there are so much data that we discard SLCs that result in interefograms with clear discontinuities between bursts after ESD. We are interested in secular rates of small features like salar deformation, so discarding let's say 1 out 2 SLCs does not result in a huge change in the deformation rates. This is clearly not the most rigorous way to do it, but it works for us. If you are interested in let's say interseismic strain from the megathrust coupling, this approach to select the data might not be satisfactory.

Best,
Francisco

[SofiViotto]

Hi @CunrenLiang, @piyushrpt and @fdelgadodelapuente !

Thanks for your feedback. Apologies for the delay; I had to reprocess the interferograms in one of the areas using the SRTM DEM (prepared through ISCE2), and the results were the same as before: some interferograms exhibit phase jumps, similar to those observed using the Copernicus DEM. As @fdelgadodelapuente noted, we have also connected this issue with the ionosphere, as there seems to be no other explanation. This remains a significant problem with the ascending track. To recap:

Sentinel Data: Track No. 76, Ascending pass, IW1 located in the dry central Andes in northwestern Argentina.
Time Span / Total Scenes: 2016-2022 / 151 scenes
IPF Versions: >=2.62 and above
Processor: ISCE2 topsStack
Alignment: Geometric + ESD
Number of Bursts Processed: 10
Orbits Quality: Checked and okay
Errors During Processing: No errors were observed during processing. The stacks have been processed multiple times with different DEMs (SRTM or Copernicus).
Coherence of the Pairs: Good to excellent. For example, pairs 240 days apart can still have coherence >= 0.77.
Coherence at the Burst Overlap Area During ESD: Good, with enough points.

Our current strategy, as pointed out by @fdelgadodelapuente, is to remove dates with multiple phase jumps and generate a reduced stack with as few phase jumps as possible. Is there any additional advice on how to detect these dates properly at an early stage? Perhaps you, @fdelgadodelapuente, might have some suggestions.

Best,
Sofia

[fdelgadodelapuente]

Hi Sofía,

For the moment the graduate students manually survey all the thousands of unfiltered interferograms and discard those with phase discotinuities. They do not have the technical skills to develop a better way to do this, but in the future we will have to sort this out.

Best,

[SofiViotto]

Hi @fdelgadodelapuente,
Thank you for your feedback. If I understand correctly, you only discard the interferograms (or dates prone to phase jumps), and you do not re-run the network?

Thanks again
Best,
Sofia

[fdelgadodelapuente]

Hi Sofia,

Yes, that's what I do. Re-running the network means several additional weeks of processing time, so we skip that.

Francisco