SRTM 3Sec - that is the default, right?
yes, the default, but currently unavailable: SRTM ZIP-files are corrupted or not found
Please try switching to SRTM 1Sec HGT (AutoDownload) until the error is fixed.
1 Like
Hmm, ok. Do you know if that has been happening intermittently over the past couple of weeks? Or has it been continuous?
I wonder if the Stamp Export could be affected by the same issue (I processed the previous AOI last week).
actually, the stamps export should not be affected, because the DEM data is already part of the interferograms. But if the DEM was not written correctly at the interferogram creation step, it will not be exported.
This has happened a couple of days ago when the link to the SRTM 3Sec data had changed. It will be fixed with the next SNAP update, but so long, SRTM 1Sec is the only option.
Ok, and by âwill not be exportedâ, do you mean that neither the snap2stamps script nor the SNAP GUI will begin the export process? Or will they just run indefinitely?
Itâs strange because the coreg and ifg images for the first AOI (processed using snap2stamps) seem correct (I just canât seem to export them).
Can the snap2stamps scripts be modified to use SRTM 1Sec?
Iâve just tried both SRTM 1Sec HGT and Grid in TOPS+ESD Coregistration, and neither seems to work (I get the same âjava.lang.NullPointerExceptionâ error).
I really donât know, sorry. I can only report this:
What happens if you run the export for one pair and the corresponding interferogram?
Have you managed to correctly modify the coregistration xml to use the SRTM 1Sec instead?
Is it coreg_ifg2run, coreg_ifg_computation, or coreg_ifg_computation_subset that I would need to edit? Although currently I already see SRTM 1Sec in all of these (the following image is from coreg_ifg2run.xml):
If that is already entered, it should make use of the correct one, no need to change then.
Sorry to say this, but snap2stamps is a user-provided tool and ESA takes no warranty that it works under any circumstances. I canât think of a reason why it fails in this case.
Have you tried to coregister an image pair with BackGeocoding in the GUI for a test?
I understand of course!
Iâm currently downgrading from Ubuntu 20.04 to 18.04 (shouldâve done alreadyâŚ), as I realize there are issues peculiar to the former.
Iâll see whether that resolves anything.
Following a downgrade from Ubuntu 20.04 to 18.04 LTS, upgrading RAM to 32 gb, and using SNAP v6, snap2stamps has been fully executed.
After running mt_prep_snap, however, I received an initial message after the opener, âmatlab: permission denied,â and then the process continued- itâs still underway, but amplitude estimates have now been produced for all 114 images, as have their interferograms. Does that message indicate the results will be erroneous?
No actual error messages have appeared yet (3/9 patches processed). I went ahead and changed the matlab installation folder contentsâ permissions to read/write, hopefully that doesnât mess something up!
Good luck then! Itâs good to plot the intermediate results every now and then to check if the data look alright
This only means that you do not have matlab in the environmental variables which can be found from mt_prep_snap and a starting file will not be created.
However, this can be created within MATLAB while running stamps itself.
Ok- and could any resulting files have been affected?
Also, on a slightly unrelated matter, does the application of TRAIN to snap2stamps PSI make much difference, since only the master APS is estimated (data set of 114 images, including master)?
no.
TRAIN cannot be applied to snap2stamps.
TRAIN is applied together with StaMPS processing, not to snap2stamps. Please do not mixed terms,
TRAIN does not estimate only APS for the master image. I believe you are confused.
Please read TRAIN manual and tutorial so that you will see that TRAIN estimates APS for each of the images, and the different options for it.
Ok, yes- I seem to have misread this post
There seems to be an issue with this link, however
http://gmt.soest.hawaii.edu/gmt/gmt_download.html
Is there any other way to access that software?
can you try to get GMT5SAR?
I think they moved time ago the website.
I have found using google this repo, but not sure is the official one, you better check it:
After I run the python coreg_ifg_topsar py project.conf scripts, my interfergrams are very noisy and has low coherence. What ideas do you have for improving their coherence?In addition, my study area does not have Sentinel-B images.
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?