I just realized it was a version posted above on April '19 by mdelgado, so I’m assuming the version I downloaded with StaMPS is up-to-date. However, I just swapped them out again- the error is the same (Step 1, Patch 2).
Actually, the one from mdelgado should solve some of the errors in step 1, even though it is from 2019.
Waht happens when you select another number of patches?
“more images lead to a more robust selection of stable scatterers and therefore less variation in temporal analyses. But for single master approaches, longer time series also lead to less persistent scatterers.”
dear Mr. Andreas Braun
first of all, i want to study landsubsidence in my area for 4 years time periode (2016-2020), i am planning to use sentinel 1 SLC data, i had tested the psi in StaMPS using small number of images,
and now i want to use monster stacks of data (>100 images of SLC, from 2016 to 2020 using one orbit data with temporal resolution of 12 days ) , so i have made 10 stacks of corregistred data (with each stack containing 12 slave and 1 master image), and now i currently in inteferogram formation step (which is taking so much time)
my questions are :
-
what is the best optimal number of image for persistent scatterer interferometry for 4 years period of time ? lot of people are suggesting for > 20 images of SLC sentinel 1 data for PSI to become optimal, but i could not find explanation about relation with the number of suggesting image with time periode, could it be > 20 images for one years , or if i want to study for four years, i could also use 20 images from 2017 to - 2020 ? (so i dont need to use large number of images (>100))
-
my interferogram formation step is taking so much time (approximately 7 hours for each stack), is it normal ?
thank you,
best regards
and i am truly sorry if there was questions similiar like mine and have been asked before since i coudnot find it
to 1: The number of images is always a compromise. On the one hand you need images which cover the entire period, so the longer the observed time the more images you need. On the other hand, with images at intervals of 12 days you end up with 120 images for 4 years. Which is quite much. So maybe you can use images at intervals of 36 days and will have around 40 images.
However, your study area defines how well this works. If you observe natural landscapes, the temporal baseline between the reference and the support images should not exceed a certain level (for PSI). So if you have 4 years and the reference image is located in the middle of that time, the time between the reference and the support images ranges up to two years which will probably not give you reliable phase information any longer. Things are more stable in urban areas.
Stacks of 12 images don’t make much sense to me, because these are still prone to much noise and phase instability. So you mght consider splitting your observed period into two or three individual parts, each covering two year with images every 24 days (30 images per stack) and process them individually in StaMPS. This will also speed up the processing and still give you the chance to plot temporal displacements.
I see some technical challenges of creating small stacks and adding them to one large time series before the StaMPS processing. I have never done it myself, but can imagine that there are some points where this might fail to produce the correct input data structure required by StaMPS.
To 2: Have you defined a spatial subset in the configuration file? This should speed up the interferogram processing (12 images should not take so long). Also, please make sure you have installed the latest updates, because SNAP needs a DEM to remove the topographic phase in this step which caused timeouts lately. With the most recent updates this has been fixed.
dear Mr. Andreas Braun
thank you for your consideration answer, i thought that as well, looks like i wll divide my time period just like your suggestion,
“To 2: Have you defined a spatial subset in the configuration file? This should speed up the interferogram processing (12 images should not take so long). Also, please make sure you have installed the latest updates, because SNAP needs a DEM to remove the topographic phase in this step which caused timeouts lately. With the most recent updates this has been fixed.”
pardon me, but in the tutorial i have read, if i am not mistaken the spatial subset could only be done after the interferogram formation, and deburst, or maybe i have missunderstanding regarding this ? i am using snap on windows, and will process it further on Linux for the psi
best regards
that’s true. My point only applies if you use the snap2stamps python scripts to preprocess the data, but based on your information you do not use it - sorry for the confusion.
oh i see, nevertheless, i am really grateful for your considerration advise,
thank you Mr. Andreas Braun,
hope you have a good day
best regards
1 Like
3 x 2 patches produces an identical error to the one in previous image (where I used 2 x 2 patches). Any other ideas of what could be wrong?
not really, sorry. Struggling with StaMPS errors myself at the moment and can’t find where the data is not as it should.
Hi everyone,
I have a question for you. My area of interest is between two different IW (IW1 and IW2) of the same image, both master and slaves. Do you know a way to put togheter IW1 and IW2 during the pre-processing in SNAP? I’d like to avoid having to do the entire PS SNAP+StaMPS processing for IW1 and then for IW2 individually.
I have already tried the SliceAssembly tool but the resulting product includes only one of the two IW.
Thank you in advance!
Can we use GRD data to avoid debust?
no, interferometry needs SLC data
1 Like
Dear all,
I was wondering if keeping INSAR_master_date or changing it to, for example, INSAR_20020305 makes any difference?
In previous STaMPS processing, I didn’t notice it and I kept INSAR_master_date as it was. I completed it and everything seemed ok.
Could you be so kind to solve this doubt? Also, could you kindly tell me what can happen if the folder is named INSAR_master_date instead of INSAR_20020305, for instance?
Thank you very much
usually, you replace “master_date” by the actual date of the reference image. I’m not sure if it makes a difference at later stages, but I’ll stick to this convention whenever possible.
1 Like
For high accuracy i increased the goldstain filtering value 0.8 to 0.9 but It’s giving below error. please check it once.
setparm(‘unwrap_gold_alpha’,‘y’)
SETPARM: unwrap_gold_alpha = ysetparm(‘unwrap_gold_alpha’,‘0.9’)
SETPARM: unwrap_gold_alpha = 0.9stamps(6,6)
STAMPS: ########################################
STAMPS: ####### StaMPS/MTI Version 4.0b6 #######
STAMPS: ####### Beta version, Jun 2018 #######
STAMPS: ########################################
STAMPS: Will process current directory only
STAMPS: ########################################
STAMPS: ################ Step 6 ################
STAMPS: ########################################
STAMPS: Directory is INSAR_20180630
PS_UNWRAP: Starting
Phase-unwrapping…
GETPARM: small_baseline_flag=‘n’
GETPARM: unwrap_patch_phase=‘n’
GETPARM: scla_deramp=‘y’
GETPARM: subtr_tropo=‘n’
GETPARM: tropo_method=‘a_l’
GETPARM: drop_ifg_index=
GETPARM: unwrap_hold_good_values=‘n’
PS_UNWRAP: Code to hold good values skipped
subtracting scla and master aoe…
GETPARM: unwrap_time_win=730
GETPARM: unwrap_method=‘3D’
GETPARM: unwrap_grid_size=200
GETPARM: unwrap_gold_n_win=32
GETPARM: unwrap_prefilter_flag=‘y’
GETPARM: unwrap_gold_alpha=‘0.9’
GETPARM: unwrap_la_error_flag=‘y’
GETPARM: unwrap_spatial_cost_func_flag=‘n’
GETPARM: max_topo_err=20
GETPARM: lambda=0.0554658
PS_UNWRAP: n_trial_wraps=0.207767
Resampling phase to grid…
Number of interferograms : 29
Number of points per ifg : 670722
Error using .^
Matrix dimensions must agree.
Error in wrap_filt (line 71)
H=H.^alpha;
Error in uw_grid_wrapped (line 140)
[ph_this_gold,ph_this_low]=wrap_filt(ph_grid,prefilt_win,gold_alpha,[],lowfilt_flag);
Error in uw_3d (line 155)
uw_grid_wrapped(ph,xy,options.grid_size,options.prefilt_win,options.goldfilt_flag,options.lowfilt_flag,options.gold_alpha,options.ph_uw_predef);
Error in ps_unwrap (line 235)
[ph_uw_some,msd_some]=uw_3d(ph_w(:,unwrap_ifg_index),ps.xy,day,ifgday_ix(unwrap_ifg_index,:),ps.bperp(unwrap_ifg_index),options);
Error in stamps (line 504)
ps_unwrap
Is it correct that the process has now been reported as working with Ubuntu 20.04 and the latest version of SNAP?
I initially downgraded to Ubuntu 18.04 and SNAP v6 because I read that there were issues with 20.04 (which I presume have been resolved).
Have your issues with StaMPS persisted?
the issue was related to sea surface pixels which were somehow not treated correctly. Applications of purely land areas work as usual.
Oh ok, so in my case, would that mean changing to a region without lakes (which are not small relative to the ROI)?