Problem in the last part of snap to stamps

[zahra0729]

@CDE

http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

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?

[ABraun]

the export is somehow detached from the interferogram formation. The best solution is to install all updates and have SNAP update the sources.

[zahra0729]

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?

[zahra0729]

Hi dear, can I ask how did you solve the problem of libgfortran.3 in ubuntu18.04 after installing snap. v8?

[ABraun]

@zahra0729

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?

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.

[ABraun]

@zahra0729

Hi dear, can I ask how did you solve the problem of libgfortran.3 in ubuntu18.04 after installing snap. v8?

please also install libgfortran5 (Workflow between SNAP and StaMPS)

[zahra0729]

Thanks for your reply, I’ll try it.

[zahra0729]

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.

[ABraun]

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

[zahra0729]

Do you mean that this proposed link has been failed too? http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

[ABraun]

@zahra0729

Do you mean that this proposed link has been failed too?

no this should work. But any invalid file in the directory should be deleted after you have modified the aux file.

[zahra0729]

@zahra0729

http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

this link doesn’t work for me…so how can I force the stamps_export step to use srtm1 instead of srtm3?

[ABraun]

@zahra0729

this link doesn’t work for me…

you cannot open it in a web browser, but if you replace the line by
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

SNAP will find the data and download it.

@zahra0729

so how can I force the stamps_export step to use srtm1 instead of srtm3?

This is not possible without coding it on your own.

[zahra0729]

@ABraun

you cannot open it in a web browser, but if you replace the line by
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/

SNAP will find the data and download it.

I did it as you mentioned in your previous recommendations! but in ubuntu18.04 it works well and everything is ok…but in ubunu20.04 with the same data and same version of snap, the last part of analyses(stamps_export) doesn’t work.

[ABraun]

have you also checked for invalid files?

@ABraun

It has also been reported that deleting old DEMs downloaded into the user directory helped after changing the data source. This means to remove all files inside:
user\.snap\aux\dem\SRTM 3Sec
especially the ones which are only 1 KB. Otherwise, SNAP tries to re-use them in the future, but they are empty.

[zahra0729]

I do all of recommendation steps, but it still remains at 4th step of snap2stamps without any error and any progress!!

[zahra0729]

@CDE

http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/

Hi again dear ABraun… can we download the dem from any site such as http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/ and put it in the dem folder of the auxiliary file?

[suribabu]

It will take some time, You want to check whether it is running or not. For that just open working directory, then open INSAR_20170627 folder and it will contain Four folder (manily diff0 will contain each and every InSAR file like master_slave.diff)

[zahra0729]

i don’t want to check its running progress. I tried all suggested solutions but none of them work for me…so I downloaded dem of my study region then run stamps_export.py…it worked but I am not sure this solution is logical or not…

[mdelgado]

@ABraun @marpet

The main question still remains, why the StaMPS export module tries to download the dem again, even if the elevation band is already present in the inteferogram stack imported ?

Has this been changed in SNAP 8 or planned to change in SNAP 9?

For what I have seen even the StaMPS export tries to get the SRTM 3Sec anyway, despite the DEM employed during the TopoPhase Removal of the Interferogram operation.

If at least it would consider using the same DEM employed in the topophase removal, there would be no problem. However, currently the operator looks for a hardcoded DEM, i.e the SRTM 3Sec on a non-available server, which makes it never end.