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:
S1A_IW_SLC__1SDV_20150307T064214_20150307T064242_004922_00625E_B9A3
S1A_IW_SLC__1SDV_20150308T182659_20150308T182726_004944_0062DB_F390
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?
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.
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.
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 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:
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.
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.
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.
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:
S1A_IW_SLC__1SSV_20141219T204259_20141219T204327_003793_004879_4929
S1A_IW_SLC__1SSV_20150112T204258_20150112T204326_004143_00505A_DA6E
S1A_IW_SLC__1SSV_20150313T204258_20150313T204325_005018_0064AB_41C6
S1A_IW_SLC__1SSV_20150418T204258_20150418T204325_005543_007169_C251
S1A_IW_SLC__1SSV_20150512T204259_20150512T204326_005893_00796F_DB0E
S1A_IW_SLC__1SSV_20150605T204301_20150605T204328_006243_0082A3_A8B3
S1A_IW_SLC__1SSV_20150723T204303_20150723T204330_006943_00965B_7C85
S1A_IW_SLC__1SSV_20150816T204304_20150816T204331_007293_00A009_5739
S1A_IW_SLC__1SSV_20150909T204305_20150909T204332_007643_00A994_2B73
S1A_IW_SLC__1SSV_20151027T204306_20151027T204333_008343_00BC63_DE97
S1A_IW_SLC__1SSV_20151120T204300_20151120T204327_008693_00C5E2_C43B
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:
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
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
