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!
The stamps export in snap2stamps does not finish, i have change the SRTM 3sec location into
DEM.srtm3GeoTiffDEM_HTTP = http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/
I Also try
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/
But the problem persist , how did you solve it
Thanks.
are the SRTM data correctly included after interferogram formation?
Yes off course ,
can you please try if the problem persists with this alternative source of SRTM 3Sec?
DEM.srtm3GeoTiffDEM_HTTP = http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/
I am still not sure if the interferograms have to be recomputed as well…
I have tested this alternative source of SRTM 3Sec
And the export dont work too.
I haven’t any Error in my interferogrammes generation, I work with snap 6 that is the stable version
although this is probably not related to the version, I still recommend updating to SNAP 8 to exclude possible bugs which have been fixed in the meanwhile.
When did you process the interferograms?
Today I have processed my interferograms
can you please process them again using SRTM 1Sec (AutoDownload)?
This would help us narrow down if this has an effect on the StaMPS export.
I have reinstalled my snap v6 , I process again the interferogramms
and tested the alternative source of SRTM 3Sec with
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/
Finally it works. Thank you very much for your collaboration.
thank you for reporting. It is very strange, because it should not be related to the SNAP version at all. But probably reprocessing the interferograms with the new source has the desired effect.
Hello All,
It is very strange that I have found a new problem in Phase three in Snap-Stamps with the following error.
I controlled all the input data but received this error.
SNAP STDOUT:b"INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters\nSEVERE: org.esa.s2tbx.dataio.gdal.activator.GDALDistributionInstaller: The environment variable LD_LIBRARY_PATH does not contain the current folder ‘.’. Its value is ‘/usr/local/cuda/lib64:/usr/local/cuda/lib64:’.\nINFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.\nExecuting processing graph\nINFO: org.hsqldb.persist.Logger: dataFileCache open start\nSame polarization is expected.\n done.\n\nError: [NodeId: Back-Geocoding] Same polarization is expected.\n"