I have the same problem.
I tried to down-grade the SNAP version but it didn’t help.
Following.
To control the GUI procedure I used this tutorial “https://www.youtube.com/watch?v=6rtFvKJIPIQ&t=720s” and found that I have an Error (stopped the procedure) in the phase of BackGeocoding. In addition, I used such a method on another PC and have the same problem.
The procedure steps are as follows,
1- Split
2-Orbit
3-BackGeocoding
and so on
It is stooped on computing raster data on Back Geocoding procedure.
yes, because of the current SRTM error. SRTM ZIP-files are corrupted or not found
Please select SRTM 1Sec HGT (AutoDownload) instead, the error will be fixed with the next update.
I tried with mentioned DEM but had same problem. In addition, My snap Version is 7.
the problem is not related to the SNAP version, because the server location of the SRTM data has changed.
It was reported that a clean re-install of SNAP (including deleting the user configuration data) solved this error.
Do you exactly mean I have to uninstall my snap and reinstall considering deleting the user configuration data in the installation part?
yes, this should fix the issue
Thank you for your help,
My problem on the Back Geocoding with Snap did not solve with reinstallation while it is solved by
Now I had an Ifg file.
When I started to finalize Stamps export the procedure is stopped on 4% .
I think it is my main problem considering my first question about the fourth step in the snap to stamps procedure. This means stamps Export doesn’t work in GUI as well.
I also tried with a newly installed Snap on Windows, The same problem occurred. I think there is a mistake in Datacenter or ESA server???
an explanation on this problem (and a manual solution) is given here:
Thank you so much for your prompt help and consideration. My problem to generate Ifg is solved. now I have an excellent Ifg file. I started to export the project to Stamps using Snap to Stamps from ~Interferometric/PSI/SBAS. The command will start and it will be stopped at 4 percent. I used a Different version of snaps. In addition, as I explained before I had the snap to stamps problem in phase 4.
This is now my main problem.
here we are all at the same problem.
@mdelgado Do you have an idea why the StaMPS export from SNAP (and in snap2stamps) does not finish?
@jun_lu Have changes been applied to this operator lately?
Which version of SNAP is using?
With snap v6 the operation works perfectly, despite the fact of creating a target.dim target.data in the folder where the script is called
Months ago I got a snap 8 snapshot where the operator was not working as it should , but I hope they solved it. I cannot confirm as I have not tried yet
As far as we know, no modifications have been made to this operator recently. We are looking into this issue now.
Dear Abron,
Thank you so much for your kind collaboration. The problem is solved as soon as I manually changed the SRTM 3Sec to 1 sec considering this post (SRTM ZIP-files are corrupted or not found).
Thank you again for your and your team collaboration in my problem-solving.
Mr. Delgado, is it possible to run the scripts in small batches for a 113 image S-1a image dataset? If so, would I only need to keep one set of each output in /diff0 and /rslc for the master image (and does it matter if they are produced before or after the rest of the dataset)?
e.g. step 8) in How to prepare Sentinel-1 images stack for PSI/SBAS in SNAP
what do you mean in small batches? in groups of 10? sure…
Data will have different name so that they can join /merge in the folders automatically without issues
I confirm that this is related to the mentioned change of the location of SRTM 3Sec data.
Even if you have used another DEM during the interferogram formation (for topographic phase removal) SNAP still wants to access the SRTM 3Sec database in the StaMPS export, and the export will fail or stop to proceed.
So if you encounter the problem during the StaMPS export, please update the URL of SRTM 3Sec and delete old and incomplete files as described in this post until this is fixed by an update:
1 Like
5-7 images per batch. As for the second question, I was wondering more (specifically with respect to the .par and .rslc files for the master image, which seem to be updated with every run of the export scripts), does it make a difference if I process the entire data set, and then transfer the master image’s files, rather than transferring them at the start (before the rest of the data set has been proceeded?
Pardon the convoluted phrasings! I’m really just wondering if the PSInSAR results will be affected.
Similarly, at your convenience of course, if you could comment on this issue it would be much appreciated!