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.
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.
The problem was fixed when I changed the srtm 3 address. ram usage and hard disk usage were almost nonexistent
I can confirm that the problem with the StaMPS export is solved after re-installing SNAP 8 (including the removal of user configuration data) and installing all updates.
v.8. I just installed it. the problem has been resolved. thank you
Hi Mr. ABraun. I have a problem related to the last part of the snap2stamps-master package, In a virtual ubuntu_18.04 system when I run the last part (stamps_export.py) script, Nothing happens. It is worth mentioning that ifg creation step is done perfectly, and I also have changed the source link of srtm3 in accordance with the proposed link: http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/âŠ
so What could be the problem?
the export is somehow detached from the interferogram formation. The best solution is to install all updates and have SNAP update the sources.
thanks for your reply, I use the snap.7 in this system. but in another system (kubuntu_18.04) and with snap_6 I do same works and everything is OK. so I feel the problem is related to the virtual ubuntu system. what is your opinion?
Hi dear, can I ask how did you solve the problem of libgfortran.3 in ubuntu18.04 after installing snap. v8?
regardless of the operating system, I always recommend to use the latest version of SNAP.
If you want to work with previous versions for certain reasons youâre pretty much on your own, especially in combination with external tools (StaMPS, snap2stamps) which have been developed outside ESAâs area of influence.
Thanks for your reply, Iâll try it.
Hi dear Abraun, Is there a relation between snap2stamps scripts and the version of used ubuntu? I am using kubuntu20.04âŠand snap v_6, also I have changed the srtm3 download link to your proposed link, but analyzes have been stuck in the stamps_export stage without any progress.
The location of SRTM 3Sec has changed. This was solved with a recent update, but if you insist working with version 6, you can manually adjust it as described here: A process related to digital elevation models is taking forever to finish