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:
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_gis.html
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:
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:
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
thanks
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.
Was there a solution of this problem? I get the same effects after terrain correction in some orbits.
MMS
in my case i used the collocation module and adjusted with a reference scene
I think I have a similar problem, I am processing GRDH files with Calibration > Terrain-Flattening > Terrain Correction. When I compare the output of this processing to images processed using Sarscape in EVNI as well as Sentinel 2 imagery these images or off by about 8 pixels SW. Originally I was using an external DEM that was MSL and tried the process again with another external DEM that was ellipsoid. The processed images was still off by about 8 pixels and even matched up the MSL DEM. Can’t figure out why this is happening. The images processed with the 2 different DEMs should show some variation but there isn’t
Which version of the software are you using and what are the products involved?
I’m using version 3.0 and using Sentinel 1A GRDH files.