I think none of the time series (either before or after the incident) should contain image pairs which cover the collapse, because you will lose most of the PS. So you either take less images or create a subset which is large enough to be processed.
If you have a small AOI you can skip the tiling option in mt_prep_snap. Instead of 3 2 50 200 you can simply finish the command with 1 1 and no patch overlap.
Actually, after the mt_prep_snap I didn’t put none of these parametres. I added only the 0.42 after the file location ( as in the tutorial of @amirolinxa, where the actual value was 0.40). As for the AOI I have a square area with the size of a side of 40 km.
So you are suggesting to do the pre- process again without including the images after the collapse, maybe considering only the area over the bridge? so, i should follow this order: coregistration > subset> interferogram process. and then the mt_prep_snap with the command ending in 1 1 . ( pelase, correct me if I am wrong)
Definitely he was right. If ur aim is to show the preliminary movements before the sudden collapse, there would be no point to include the images after it. Furthermore, as Ab Braun mentioned it impose unnecessary decoralations on the analysis which results in losing more PS.
I understand what you are saying, and i agree with you. But how is it possible that I still do have some points in the bridge showing the deformation? According to what you are saying, I would expect no points at all over the bridge.
I sometimes even had points over water which were not weeded out because their phase was constant by pure chance.
If you did not enter any row/colum numbers (as you did) I think the script automatically only creates one patch.
And yes, I recommend to coregister, then make a subset and then create the interferograms. You can still leave some area around the bridge (helps to estimate phase contributions), but not necessarily the entire image.
.m files are text, does less /home/ikhelif/Downloads/StaMPS-v4.1-beta/matlab/ps_parms_initial.m display the file? No such file or directory messages can occur when some directory along the path ended up using Unicode “look-alike” characters, for example, ASCII “minus” and “dash” are the same, while Unicode can have different dashes: “em-dash”, “en-dash”, “minus”, etc.
if I understood you correctly, you are not dividing your data into patches. Patch 1 (the only one existing) therefore needs considerable time for processing.
Please add 2 3 at the end of your mt_prep_snap command to divide your data into 6 patches (3 rows, 2 colums). This should speed up the processing a bit.