Problem in the last part of snap to stamps

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"

This indicates you have not selected VV for all products in the TOPS Split step

Thank you for your kind help. It was fully true. I solved the problem.

I am using esa snap 8.0. srtm is set to 1sec hgt. But StaMPS export i

s 38% left.

could it be that some SRTM 1Sec tiles were not correctly downloaded? Please check in the aux/dem folder and remove all zip files in there and restart.

thank you for your attention. Should I delete these files?

only the ones inside SRTM 1Sec HGT.

Then make sure you are working with SNAP 8 and have installed the latest updates.

A backgeocoding and interferogram generation also make use of SRTM data, you can restart the processing from there, if you want to go sure. This has at least solved it for all users.

software is up to date. I did all of what you said, but it didn’t happen again. part of the percent does not progress. this problem has existed for the past 10 days. it wasn’t there before

yes, this somehow coincides with the change of SRTM 3Sec data.
Can you please also modify the file as suggested in the second option and try again? Although it is not actively used, SNAP might try to access SRTM 3Sec data or check if these are available.

thank you worked. I was just using my question “srtm 1”. In the last part, I made a stamp export as “srtm 3”. is it okay

thank you for reporting. This is important for our understanding of the error source.

@jun_lu Do you have an explanation why the export works with the new SRTM 3Sec link while it does not re-download the source at all?

This could be a disk space or memory issue manifesting itself in strange ways. When you run the stamps export with the 1 sec DEM, what are your drives and memory usage like? If it’s using up all of your RAM, try closing out applications that you don’t need running while performing the operation.