I had set the insar_processor to ‘gamma’ (checked it), and i replaced the matlab and shell scripts to the new one (checked it). I had to be edit the ps_load_initial_gamma file at line 180 and 183, i added the ‘-v7.3’ parameter, because of a well known file save issue.
The Stamps export didn’t drop any error or warning, and i got all off the data and dir that was described before in this topic (dem, diff, geo, rslc). I’m just copied to a new dir, which is the input of the mt_prep_gamma. The structure of the input dir:
dem: contains 2 files (rslc and par), from one of the stamps output dir (chosed randomly, becauseall of the same)
diff0: contains 24 base, 24 diff and 24 par files (i had 24 stacks).
geo: contains 6 files, 20160519.lat, 20160519.lon, 20160519.lat.par, 20160519.lon.par, elevation_dem.rdc, elevation_dem.rdc.par (20160519 is the master date).
rslc: contains 25 rslc and 25 par files (i had 25 images).
Maybe something went wrong, when i copied the Stamps outputs (geo directory)?
I ran the whole STAMPS process under terminal, without GUI, so i didn’t checked the results after the steps. Next time i will run from mt_prep_gamma to stamps(8,8), step by step, and i will check the outputs in matlab.
(if there is a better topic for my problem, please let me know )
You should had checked the log information coming out from the mt_prep_gamma command.
What you show there is seems that the lat/lon were not considered… even if then inside MATLAB you got some coordinates. Stilll which are those values 1.0 and 0.00 ??? Are those coordinates matching with your AOI?
Just wondering…
For what you said I am not sure the mt_prep_gamma got the right values for those coordinates.
Btw, had you used the mt_prep_gamma after modifying the gamma format to read? Please use the mt_prep_snap which is provided with the latest stamps version available on github.
I have retreated my data by playing with weeding parameters and dropping noisy interferograms.
But I still face the same problem with an important dispersion in my time series.
You simply place all slave zip files into a slave folder, create a master folder where you apply orbit files and TOPS Split and then the scripts do the rest for you including the export. I was able to get nice results with it.
Oh yeah, I have read that, it really helps to process quicker your data.
But, from what I understood, the only difference in the processing chain is the “enhance spectral diversity” step.
Else if, it seems that I have exactly done the same path.
Well, the dispersion comes from the APS of the slaves.
I have compared SNAP derived interferograms with StaMPS and other software and results were similar. With Sentinel-1 the issue comes on the APS, which should be taken carefully into account.
No, I did not.
I assumed there was no effect because my area of study is flat, South Alsatian plane, and small, less than 50 km per 50 km.
So, yes, may be this assumption is not right.
But, I did not applied the ESD step, what is the impact of missing this step?
The Netherlands is also really flat, but atmosphere believe me affects the results.
That means, atmosphere only can be neglected if the area covers few Km2 (1km x 1km or 2km x 2km) or big deformation is expected (Earthquake events, or huge subsidence expected)
From my personal experience atmosphere matters, mainly when deformation to measure is small. If you measure deformation in the Mexico city center, atmosphere effects can be neglected.
It happened to me when I used the old way (using SNAP GUI). Now I’m using the snap2stamps pack made by @mdelgado and the latlon and dem inputs are always ok!
Regards
I am a freshman at SNAP&StaMPS. I have learned a lot from here, thank you all.
I successfully ran mt_prep_snap by cygwin64 (using a modified version provided by someone else on the web). But after running mt_prep_snap, the matlab automatically jumped out, said ""Warning: Name is nonexistent or not a directory: \StaMPS-4.1-beta\matlab:
I am also stuck here with no two similar bands. How did you overcome the challenge?
When exporting to STAMPS “The product … already contains a band named…”
I had this once because I mixed up a step in the preparation. As I properly did all steps again (only use one polarization to go sure), it worked. I don’t know where it came from but if you stick to the presented order, it shouldn’t happen.
Thank ou for the response. Let me repeat because I actually created the subsets as the second step meaning I mixed up the steps. I will give the feedback let me repeat.
)
