You have both backslashes and frontslashes in the same paths, which cannot work.
1 Like
yes, absolutely right, thank you
I didn’t pay attention to that, thanks.
Hello everyone,
This is a new topic for me and there are some facts that I can’t understand clearly. I hope someone can help me to clarify some doubts. Very thanks and sorry for the number of questions.
1- Precision and accuracy:
Which precision (in terms of mm) and accuracy is reachable by using Sentinel-1 in SNAP+STAMPS workflow?
I processed 55 Sentinel 1 image. However, I can’t assess properly the accuracy of the displacement timesheets. I’m investigating the PSInSAR (snap + stamps) feasibility also for infrastructure monitoring and the precision and accuracy of the displacement is a key aspect.
2- Reference point:
have the displacement timesheet the same spatial reference point?
I’m quite confused about the meaning of the spatial reference point. I’m not sure how it is handled in the workflow: does the reference point change in each scene? do timesheet are refereed against a reference point? If the reference point change throughout scenes, has each timesheet a different reference point?
If possible, I’ll be glad if someone can indicate some references or documents about this aspect.
3- wavelength and velocity of displacement:
How do the sensor’s wavelength and target velocity influence displacement detection?
As I understand the precision of displacement detection depends on the sensor’s wavelength. Also the speed of the target displacement influences detection: if the target moves too fast we cant detect properly the displacement. It is correct?
Also, If possible, it will be great if someone can indicate some references or documents about these aspects.
4- PS position in pixel:
Where the PSs is positioned in the pixel? in the centre of the pixel?
5- Post-processing information:
After stampsexport, an excel file is provided. The third column is probably the elevation. However, I can’t understand properly which reference system in the scene is taken and which datum it is referring to. Also maybe i can obtain other informations, so the question is: by processing one orbit’s data (A or D), which more information I can obtain about displacement direction (for example incidence angle, director cosines, ect)?
Thanks for reading. I hope that someone can help me to better understand these aspects.
My best,
Othmane.
Happy to see you are using snap+stamps. Not sure you use snap2stamps (NEW RELEASE COMING SOON)
Regarding
- I believe you can find many paper publications in the literature talking exactly about it.
Again, what you are able to reach on your processing depends quite a lot on how you processed the data, how strongly is affected by atmospheric artifacts (dense clouds, humidity, etc)
Literature says that accuracy is usually <2mm/yr on the average LOS velocity.
questions to you:
- had you used a reliable reference point?
- had you applied any atmospherical phase screen removal (APS) using GACOS, TRAIN, GNSS information etc? This may help you to reduce APS signal mixed with the deformation one.
Remember that the final phase contribution after DInSAR processing is : defo+atmo+noise
The more you are able to reduce atmo and noise the more accurate/precise deformation you will get.
-
reference point is fixed for all the ifgs if you set it using StaMPS values for that. Otherwise it does a scene averaging to be used as a reference
-
from t1 to t2 the deformation should be such that the unwrapping process is able to follow. Differences between fringes = wavelenght/2. So the relationship is clear.
Very high speed deformation will not be able to be measured using PSInSAR, but other techniques such as Pixel Offset Tracking or similar. -
PS locations are not corrected in StaMPS so they provide (I guess) pixel center.
I have seen some work on their correction but the authors had not shared the scripts with the community. -
please ask on its proper thread. StaMPS Visualizer maybe?
I hope it helps!
Best,
5 Likes
Great news!
1 Like
Hello @mdelgado and very thanks for your responses! 
Currently, I’m using PSInSAR workflow that uses WSL in windows.
-
had you used a reliable reference point?
I follow the guide provided in the “PSI using SNAP-STaMPS workflow in Windows Subsystem for Linux (WSL)” thread; so I didn’t set any parameter about the reference point. Which is the best way to choose it? also, is available in this forum a tutorial on how to set properly the reference point? -
had you applied any atmospherical phase screen removal (APS) using GACOS, TRAIN, GNSS information etc?
No, I follow the guide provided in “PSI using SNAP-STaMPS workflow in Windows Subsystem for Linux (WSL)” thread. Have you any suggestions about it?
Very thanks again, my best,
Othmane.
I would suggest you to read the original User Manuals of the software you use.
Just remember that in the forum some subjects may not be covered.
Regarding
-
ref point: requires either the availability of GNSS station with a PS point near that location or a good understanding to get a PS located in a stable point (geodetic point) or over a rock area for which you may have the knowledge to be stable (specific in-situ knowledge)
-
APS removal: the good answer is always it depends. As it seems you are learning I suggest you to test them all and then verify which works better for your specific use case and study area.
I suggest you dig a bit and find the best approach that you will be familiar with.
Personally, I found it easier to apply TRAIN on linear atmo-topo phase relationship on AOIs containing large topography range difference (> 1km), but this may not solve all APS on the scenes.
I hope this helps.
Best,
2 Likes
Very thanks for your precious feedback and for your time @mdelgado,
I already start investigating these aspects of the workflow. If I reach some interesting results I will write in the forum.
My best,
Othmane.
I will try to use a different DEM downloaded manually as you have mentioned
But I highly believe the atmospheric signal to be the main reason of having topography-like pattern and very noisy time series plot like this.
I have used TRAIN’s linear approach which you have mentioned in this paper https://www.researchgate.net/publication/327253039_ESA_SNAP_-_StaMPS_Integrated_processing_for_Sentinel-1_Persistent_Scatterer_Interferometry
but unfortunately the noise persisted, so what may I do?
Have you tried using other correction models?
@mdelgado I recently finished my thesis using stamps in which i got good results, one problem I faced is the discontinuation of python 2 and having to use older versions of linux so, is there any chance of getting an update this year that solves these problems?
Happy to heard you managed to successfully SNAP2StaMPS. The problem you mentioned is being address 
but thanks for letting us know anyway.
1 Like
The problem always emerges with the last patch no matter how many patches I try the different values of da, What else can I do? the interferograms look noisy but they are complete, no signs of dark or empty data
I can only ask you which are the sizes of the files located inside that PATCH_12
@jun_lu :sorry to bother you ,how can I chang the default DEM to SRTM 1Sec HGT in order to get a better result of coregistration regarding Snap2stamps package
Sorry for delayed answer as I have repeated preprocessing with a slightly smaller subset areas making sure the AOI boundaries are still inside the pre-splitted bursts and I still have got the same error eventually. The size of the patches are as following
PATCH_1 >> 6.9 Gb
PATCH_2 >> 8.3 Gb
PATCH_3 >>8.3 Gb
PATCH_4 >>6.6 Gb
PATCH_5 >>7.1 Gb
PATCH_6 >>8.0 Gb
PATCH_7 >>6.2 Gb
PATCH_8 >>3.5 Gb
PATCH_9 >>3.0 Gb
PATCH_10 >>2.4 Gb
PATCH_11 >>283 Mb
PATCH_12 >>18 Mb
I have doubts that the inclusion of a water body inside the study area may have been causing that error but I have tried a different, older and time series with significantly lesser number of interferograms and it never had that error. Here’s what the AOI looks like
I have plotted some patches and realized the approximate location of Patch 12, it contains mostly water. what is I completely ignore this patch and continue further steps and see if any further error occurs? does ignoring a patch cause any problems after merging, I mean, the AOI would no longer be square/rectagular, so would this missing part disrupt the path-following phase unwrapping process?
Patch 11 example of one interferogram
patch 10
patch 9
Did anyone try snap2stamps module with snap9?which xml script should modified ,help me please!
You need to modify certain lines in one of the following graph files
coreg_ifg_computation.xml (if you’re going use the entire area of the pre-split bursts)
coreg_ifg_computation_subset.xml (if you are going to subset AOI from the bursts during the interferogram creation step)
you will replace line 49 with two additional lines as explained in this screenshot
here’s what you will do
Explanation in details is found here
OK,thanks very much! the changed scripts just like snap7,I’ll have a try and feedback soon