Snap2stamps vs. manual processing + StaMPS

This is okay (to a certain degree), because PS InSAR will throw away most of the pixels and only continue with those with a stable phase information. Please have a look at these slides which compare a traditional interferogram with PS InSAR phase analysis: Persistent Scatterer InSAR and StaMPS

Coherence cannot be increased technically, it all depends on the amount of vegetation and other surfaces which cause decorrelation.

i’d say so, yes. Most of the interferograms show the same pattern which indicates that the remaining PS are largely free of noise. The interferograms which strongly differ from the rest are probably affected by atmospheric phase contributions, but as long as these are not imposing wrong patterns in the overall result, it should be fine. You can also identify outliers in the time series plots quite well.

Good job!

Thanks for your good and clear explanation, but how can I identify outliers in the time series plots quite well? I do installed Train package, how can use it for improving noise effects?

I have never used TRAIN, sorry.

You can plot time series if selected point with the ts option. If one date systematically differs from the temporal trend, it’s probably because of atmospheric disturbance.

I’ll look into that, thank you!

It seems my patches (9) are incomplete after running mt_prep_snap; they only contain 10 items each and no psver.mat file (as described here SNAP - StaMPS Workflow Documentation).

No errors messages appear (other than the initial ‘matlab: command not found’, which, if I’ve not misunderstood the above, is harmless).

I’m unsure if this could an issue similar to the one discussed here How to prepare Sentinel-1 images stack for PSI/SBAS in SNAP because my pscands.1.ij files do not result empty.

I’m not sure whether this would help either… https://groups.google.com/g/mainsar/c/iuje3LSAOfg/m/IISJQ0z6KAMJ

What do you think??

Hard to tell. I would proceed as long as you don’t get an error message

I did not- however, after running stamps in Matlab, I receive this message during step 3,
"Warning: Not enough random phase pixels to set gamma threshold - using default threshold of 0.3
In ps_select (line 184)
In stamps (line 356) "

And at then at the end:

"Index exceeds the number of array elements (0).

Error in llh2local (line 41)
dlambda=llh(1,z)-origin(1);

Error in ps_merge_patches (line 485)
xy=llh2local(lonlat’,ll0)*1000;

Error in stamps (line 473)
ps_merge_patches"

I set the ‘density_rand’ parameter to 50, and then 90, but still got the same errors.

Apparently none of the PS candidates are being selected, although step 2 consistently indicates multiple tens of thousands of candidates.

I’ve tried using setparm(‘percent_rand’, 60) instead of density,
and setparm(‘filter_grid_size’, 10), as suggested here Linux Installation using StaMPS and S-1 data - the error persists.

My study area (2 bursts) does contain lake areas- however, it is surrounded by densely urbanized regions on all sides except the north:

LONMIN=-97.1843
LATMIN=33.0559
LONMAX=-96.2829
LATMAX=33.3571

I’ve also noticed that in some patch folders the file pscands.1.ij.int are much smaller (few hundred kB) and they have what appears to be an erroneous icon (black rectangle), whereas the rest are ~2 Mb in size and they have a white sheet icon.

Assuming the interferograms are correct, to what else could this be related?

that is not an error. It just means that the preselection of PS candidates was quite well so that there are not many pixels with random phase.

However, this is an error - but I am not sure what it means. How large are your patches and what overlap did you select?

They vary in size, but most are just under 1 gb, a few are < 150 mb, and they all contain 29 items. I used the default 50/200 (range/azimuth) overlap settings

if one patch is smaller than 200 pixels, it might be a problem. But I am not sure if this is the case here. Maybe you run mt_prep_snap again with only 6 patches (3 2)

Same results with 6 patches (tried the same parameter settings as above again).

Would continuing to reduce the number of patches do anything at this point?

I’ve also been considering re-processing using 3 or 4 bursts, although I had hoped to process this dataset to all the way through to obtain preliminary results. Could that potentially resolve this?

if 9 or 6 make no difference, I’m afraid this is not the reason for the error, but it could be worth a try with 4 patches (2 2) and less overlap (20 100) to go 100% sure. I was suspecting that the overlap is larger than one patch located at the edge.

The results are the same; after adjusting the density parameters (density_rand = 90) and applying setparm(‘filter_grid_size’, 10) Matlab seemed stuck on step 2 (my hard drive even went to sleep), so I reset filter_grid_size and kept the same density- step 3 continued to select 0 PS for all four patches.

Any other possible solutions? Is it at all likely at this point I’ll need to re-process with more bursts?

This so far is the most I’ve been able to find, in the mainsar group:

I checked the ps_select.m. I noticed that the raison causing this problem is the “ok_ix” is empty, which means the “percent_rand” values are all bigger than “max_percent_rand” value. one thing not normal is that the “percent_rand” values are too big like hundreds , thousands, which make it impossible to get through this no matter what “max_percent_rand” value we set.

this"percent_rand" values are depending on the “Nr”. does anyone know what kinds of Nr is correct and what is not?

what is the source of this problem?

thank you

Yu

https://groups.google.com/g/mainsar/c/JPibrQx4yB8/m/rXPEPwMjKh8J[ps_select.m|attachment]

ps_select.m (15.2 KB)

That doesn’t seem to be the case as far as I can tell, but I’ve uploaded my ps_select.m just in case.

This is saying the key!
Please check all interferograms as you may have some of them not successfully written or corrupted.

I have checked many throughout the dataset (not all, but I will now), examined RGB and elevation images- nothing so far has seemed erroneous. What sorts of indicators should we look for?
.

Hi @danm

I had the same error yesterday. I don’t know why this fixed it, but it occurred with (3 2) and (3 3) patches, but when I changed it to (2 2) it worked. I also made small adjustments to the amplitude dispersion threshold when calling mt_prep_snap, but I don’t think this was the reason.
So I guess it is somehow related to the size of the patches, but I cannot tell exactly.

Should reprocessing with more bursts resolve this then?

I used 3 bursts in my example and haven’t changed it while trying.

So depending on how large your exported rasters are, you could try

  • using only two patches (2 1) or (1 2)
  • transpose the patches (2 3) instead of (3 2)

Had you used the mt_prep_snap or mt_prep_gamma?

can you paste the calam.out file?

I would expect that either input data is corrupt or wrongly interpret or NaNs or 0s values in lat/lon bands.
If non of them, maybe partial ifgs or empty ones.