Dear forum users,
within the cohrenece processing workflow we are facing odd (higher) values in one of the subswath. This issue arose after we changed the SNAP graph workflow from the original one, where we processed particular subswaths one by one, to the new one, where we process all subswaths together and merge them. This new workflow seemed to be more than 2times faster then the original.
I have tested the new SNAP graph in both snap6 and snap7, getting same results. Below I am attaching the screenshot to see the difference of coherence values and our SNAP graph.
Coherence odd values screenshot (the brighter subswath on the left)
SLC_to_Coherence_ALL_Swath_with_TC_WGS_hardcoded.xml (14.4 KB)
Any suggestions / comments would be appreciated. Thank you.
Dear forum users,
we were able to solve the issue by moving “Apply-Orbit-File” operation after the each “TOPSAR-Split”.
I’m facing a similar issue that you were dealing with. However, the solution that worked for you didn’t work for me. I also tried to preprocess each sub-swath individually, but still no luck. Are you aware of any possible workaround for this?
“Apply-Orbit-File” before vs after split, results in:
- One additional orbit vector being included in the split DIM file.
- “Total product size” being reported slightly larger in the split DIM file.
- The split .data/ files are identical.
Specifically in my test the IW2 split file has 46 orbit vectors when “Apply-Orbit-File” before split, and 45 orbit vectors with split first.
Using SNAP 8.0.9/S1TBX 8.0.6, there is no difference in coherence products when Apply-Orbit-File is used before or after TOPSAR-Split. I believe the subswath coherence mismatch is a limitation of S1TBX in low coherence areas, such as Amazon forest, around S10W065, in my example below, and coincidentally in @onalevka’s example around S11W053 above.
Coherence produced using GAMMA software does not have the subswath mismatch issue.