Hey there. This might be a simple question and I believe I know the answer but I just wanted confirmation from the experts.
I created an unwrapped phase to displacement image in SNAP by coregistering 2 s1a images, creating an interferogram, correcting, unwrapping, and performing phase to displacement. The final product was exported to google earth as a kmz and is displayed on this post for your reference.
My question is: After range doppler correction why has all of the data disappeared from the valley in the image? I believe that the top of the slope on that mountain range prevented the radar from penetrating into the valley leading to inaccurate data for the valley. The range doppler correction moved the coordinates which were previously in the valley region to the top of the mountain where the data actually originated. Is this correct?
Could it just be a visualization glitch? I noticed a similar behaviour in Google Earth some time ago.
Please uncheck “Terrain” to see if the data was fully exported.
I unchecked terrain and the image did not change. However, I also used the same datasets to create a phase to elevation image and in this case the data in the valley was displayed. However, the elevations listed in the valley seem to be far off from the DEM which SNAP uses to do range doppler correction. This leads me to believe again that the radar did not penetrate into the valley but was possibly obstructed by the top of the slope? I am attaching the elevation images as well.
Can you please show an uncorrected intensity image of radar backcatter and one after terrain correction? The height differences of >2000 m could indeed indicate extreme radar shadow or foreshortening
Sure. I am not sure if you want the intensity image for one SLC image or for two images after coregistration. The attached images are for one SLC image before the landslide event. The image was deburst before a geometric correction was performed. Please let me know if you would like the image after coregistration instead! Thanks
Edit: Some more information for you. The landslide occurs in the top 2 bursts of the IW3 subswath in these images. IW3 is the subswath located on the right-hand side in the second and third images
I tried with a different pair, different orbit, for the same area from a year later (2022). Not only did the issue persist with this pair but it seems to be even more pronounced as is shown below.
I am also getting an error in SNAPHU. “Tile overlap is too small” I didn’t get this error with the previous image the first couple times I ran SNAPHU. Now there is this error for the new pair. I tried to go back and run the first pair of images (original post on this thread) and am still getting the same error. I believe I have run into this issue before and a fresh installation of SNAP seemed to temporarily fix the problem before the same issue pops up again after a couple tries…
I will reinstall SNAP again and see if this fixes the issue. However it doesn’t seem to affect the results. The tile overlap is too small error still gave the same results with the original pair of images. I also tried reducing the number of tile rows and columns from 10 to 4 each and still got the same error. Finally, I tried to use the most current version of SNAPHU instead of that which is pre-loaded into SNAP and still got the same error, with the same results as shown in the image above and in my first.
I deselected the No Value option as you pointed out for the image created after goldstein phase filtering. I then unwrapped it again and noticed the properties for No Value once again had to be deselected after unwrapping. Phase to displacement came out with the same result. I went back and looked at the phase after goldstein phase filtering and it didnt look at all like the image in the thread you linked. I downloaded two new datasets for a very flat area with no vegetation (sahara desert) and created an interferogram up to the goldstein filtering step. Shown below are my results from this process.
I just linked it to show where the no data value can be set, the data is surely different.
More importantly: do the missing areas persist when you disable 0 as no data just before?
Yes. I deselected the no data value box as was linked for the step after goldstein phase filtering and then exported, unwrapped, imported, and phase to displacement. The gaps in the data were still present.
Edit: I just tried it again with the new set of data over the sahara desert and the following are my results. Intensity and phase to displacement. The data shown on pixel info is for an area which did not print out on the terrain corrected image.
Wanted to provide an update since I believe I have found the solution to the problem.
It seems that increasing tile overlap (manipulating # of rows and columns had no effect) led to a longer processing time but a more complete image with no data gaps. It seems the issue was with snaphu input parameters the whole time. I am attaching to images to show improved results. The first with tile overlap input of 800 and the second with tile overlap input of 1000.
My follow up question: What exactly does tile overlap and number of tiles and columns mean in this situation? How can I figure out the optimal overlap for unwrapping?
