Location coordinates shift after processing ascending and descending passes

I processed two SLC IW products from different passes (ascending/descending, consecutive days): apply orbit file > thermal noise removal > calibration > TOPSAR deburst > subset (WKT) > multilook > update geo reference (SRTM 1sec or 3sec).

After Range Doppler Terrain Correction, using either bilinear interpolation or cubic convolution and SRTM1sec or 3sec, there is a shift in longitude for about 170m between the same location at the diferent passes, at aproximate latitude 40º North.

The swath are IW1 for the two products:

The SNAP version is v2.0 beta 7, Linux64 (Ubuntu 14.04) with 24GB RAM.

My objective is to coregister two different passes (ascending/descending) after topographic correction. Is that possible without using manual GCP generation and a warp/resample operation? How can I solve that shift?

Thank you very much.


After exporting the two orthorectified images and comparing with aerial orthophotos, the descending image is displaced 55m/75m to east, the ascending image is displaced 55m/75m to west.

With multiple near dates coregistered averaged stacks for each pass, the behaviour is the same.

I’m starting to think this is inherent to the oblique sensor view, but I’ll appreciate any input.


Does this displacement affect uniformly all the pixels in the images, or only some of the pixels?

I tested all the area corners and at different heights, from 5m to 420m mean sea level height. Also, I already test to split and only use the IW1 sub-swath, update geo reference and Range Doppler Terrain Correction with an 10m resolution internal DEM, generated from 1:25.000 topographic data. The 130m - 160m East/ West displacement between ascending and descending passes is still observed and it seems systematic.

I downloaded and observed two descending/ascending GRDH products and the displacement is also there.

Later today, I’ll test the GCP generation and use in SNAP.

FWIW I have georeferenced the same location on the two SLC images above, and I am getting the same geographical coordinates in both images (to within a handful of metres, which is good enough as I have selected the location only approximately). Google Earth has the same coordinate for that location (again to within a handful of metres). I am definitely not seeing errors of >100m.
The location I am testing is on the coastline. I am not using S1TBX for this. I am reading the orbit state vectors annotated in the products and using the height of that location above WGS84 (~54m).

I don’t know how S1TBX does the geometric corrections, or whether any of the steps in your processing chain could be introducing the systematic displacement.

Until now I already tested with/without TOPSAR Split, with/without subset with coordinates in WKT format, with/without multilook, exporting directly to Geotiff and comparing in an external application or visually comparing in SNAP: the resulting ascending image is displaced west, the descending image is displaced east.

Do you see this displacement also on GRD-images, or only with SLCs?

I downloaded the same swaths in GRDH to see if it was only on my side, and yeah, the displacement is also there.

After creating and attaching GCP Geo-Coding in GCP Manager menu for two processed images, Range Doppler Terrain Correction doesn’t show any improvement to correct the displacement between descending and ascending passes.

With atached GCP Geo-Coding, on Create Stack operator, I have the exception CreateStack: java.lang.NullPointerException.

With atached GCP Geo-Coding, when running Radiometric Terrain-Flattening, I have this exception:

org.esa.snap.framework.gpf.OperatorException: Terrain-Flattening: java.lang.NullPointerException
at org.esa.snap.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:385)
at org.esa.s1tbx.sar.gpf.geometric.TerrainFlatteningOp.initialize(TerrainFlatteningOp.java:173)
at org.esa.snap.framework.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:500)
at org.esa.snap.framework.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:279)
at org.esa.snap.framework.gpf.Operator.getTargetProduct(Operator.java:350)
at org.esa.snap.framework.gpf.GPF.createProductNS(GPF.java:311)
at org.esa.snap.framework.gpf.GPF.createProduct(GPF.java:286)
at org.esa.snap.framework.gpf.GPF.createProduct(GPF.java:265)
at org.esa.snap.graphbuilder.rcp.dialogs.SingleOperatorDialog.createTargetProduct(SingleOperatorDialog.java:168)
[catch] at org.esa.snap.graphbuilder.rcp.dialogs.SingleOperatorDialog.onApply(SingleOperatorDialog.java:283)
at org.esa.snap.framework.ui.AbstractDialog.lambda$initUI$8(AbstractDialog.java:494)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
at java.awt.Component.processMouseEvent(Component.java:6535)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6300)
at java.awt.Container.processEvent(Container.java:2236)
at java.awt.Component.dispatchEventImpl(Component.java:4891)
at java.awt.Container.dispatchEventImpl(Container.java:2294)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
at java.awt.Container.dispatchEventImpl(Container.java:2280)
at java.awt.Window.dispatchEventImpl(Window.java:2750)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:731)
at java.awt.EventQueue$4.run(EventQueue.java:729)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I should already wrote about the cell resolution. I’m using a multilooked 13m resolution Ground Range square pixel, for all the operations.

We’re looking into this.

1 Like

I was comparing the results of Range Doppler Terrain Correction with an internal 10m DEM, including local incidence angles outputs, between a descending and an ascending pass, near dates, testing the attachment/detachment of GCP Geocoding in the operation. I noted that the local incidence angles, for the different passes, were aligned! The backscatter for the two passes display the previous observed displacement, with or without GCP Geocoding.

This can be part of the explanation for the artifacts that appear at very steep terrain ridges and streams/valleys, on Radiometric Terrain Flattening, as observed in this post:

1 Like

The problem was caused by the DEM position and should be fixed now

After building SNAP and S1TBX from the source, to test if the last code alterations were already solving some problems, I was having the same east-west displacement for the different passes.

So, I tested if the cause of the east-west displacement wasn’t the Geoid height difference. I used the EGM2008 data available here:

After resampled the Global 2.5 Minute Geoid Undulations to my internal DEM resolution (10m), Lat Long coordinates WGS84 datum, I added the undulation to calculate the ellipsoid height.

I used the internal Geoid height DEM in Radiometric Terrain Flattening and Range Doppler Terrain Correction, with good results. The location difference between the ascending and descending pass was 1cell-2cell/14m-28m. Also, multilooking after Radiometric Terrain Flattening and before Range Doppler Terrain Correction, gave good results.

In short words, the operators and positioning are using Geoid heights in calculations.

Later, I’ll install again Beta 7 and test if using the Geoid height will give the same results.

I only now read this report: https://senbox.atlassian.net/browse/SITBX-24

The external DEMs specifications and the ellipsoid height use should be more explicit.
@lveci please implement the option to add the EGM to external DEMs.

1 Like

I had suspected that this might be the cause of the asc. vs. desc. shifts in easting. Glad to see that this will hopefully be fixed soon.

Hi, i think my case would be also relating to this topic, just to inform i would like to post what i faced

i have processed number of SLC data, where the process steps are taken as
Thermal noise removal > Calibration > deburst > Multilook > Speckle Filter > Terrain Flattening > Terrain Correction

i have used:

now, for all of the data except for the last 20151120 data, it works out okay without any shifting problems
but when i process with the 20151120 data i figured out that there were a kind of shifting to the west direction, kind of more shrinked compared to the other data.

here is example data scene (zoomed) from 20151027:

here is the 20151120 scene overlapped with the 20151027 data:

it is kind of shifted south west. i have used the collocation module and figured out fitting it to the other scenes
but just to show, this is what happened after the process

i noticed that the coverage of the observed scene has changed more into north area, i dont know if that changes made such shifting to it


Did you use restituted or precise orbits?


for the data other than 20151027 and 20151120, i remember using sentinel precise orbits (thanks for reminding me !)
but i did not apply orbit file to those two. even though, the 20151027 didn’t have a problem with the previous date data. it was only the 20151120 showed shifting

ill try to see if orbit file makes changes to the final result for other data sets

KOT, what version of the software are you using? I’m downloading you data now and will look into it.