Using StampsExport with an external dem


I’ve noticed that StampsExport tries to download SRTM data, at least when it’s run through gpt. For example, if I run gpt StampsExport in a linux terminal while the internet connection is turned off I get:

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: Connection timed out

From looking at the source code in github I guess that it uses SRTM to make the files for the ‘dem’ output folder. This is inconvenient for me because a) when I process interferograms using an external DEM I don’t want to use SRTM at all and b) in general I’d like to minimise how much data my processing downloads.

Does anyone have any recommendations for how to get StampsExport to use my external DEM instead?

This question has already been brought up here but I don’t think it got resolved so forgive me for opening a new thread.



Hi @eaeo. I’ve come across the same problem as you, when using an external DEM and using StampsExport through gpt. Did you manage to solve the problem? Thank you.

Hello, no, I also reported it here Snap 7 hangs on macos but no solution yet.

Please make sure that you update the location of SRTM 3 data as described here: SRTM ZIP-files are corrupted or not found

Thanks for the suggestion. This issue is about using an external DEM. We don’t want to use SRTM at all but, at least last time I checked, StampsExport still tries to use SRTM.

1 Like

I understood that. It makes little sense. We are currently investigating this, but if the problem can be solved by updating the SRTM 3Sec source, it should be worth a try, right?

1 Like

Oh I see, thanks. I assume that the new SRTM location will still require internet access but it’s worth a try, hopefully it’ll help @rdelpo

1 Like

I agree, it’s a problem in general that the operator wants internet connection

1 Like

Dear both. Thank you for your messages. Changing the SRTM source has solved the problem. However, now I wonder, which DEM is carried over to StaMPS, the External DEM (which I used for corregistration and topographic phase removal) or the SRTM 3Sec? Thank you.

legit question, especially because the StaMPS export should not require a DEM in general. We are looking into that.

For all who still struggle, please make sure that, after changing the server link to SRTM 3Sec data in the aux file, also delete zip files inside the user directory (user.snap\aux\dem\SRTM 3Sec) where zip files are stored (e.g. Once you delete all of them, especially the ones which are only 1 KB large, SNAP will re-download all tiles required for the processing of an product, and the process should finish as usual.

1 Like

problem occurs during projected dem generation, which is hardcoded to ‘SRTM 3Sec’. And this issue is not resolved “re-installing SNAP 8 and installing all updates”

thank you for pointing it out. @jun_lu can you please check this?

We will look into the issue. A JIRA ticket ( has been created to track the issue.

1 Like

Is this a quick fix for Stamps_Export? I just tried it and it does not seem work…

Hi ABraun. I am not giving up. Any idea where to find the zip files in Linux? I have not tried deleting them yet.

it is inside your home folder under /.snap/auxdata/Orbits

Also an update for S2TBX was released yesterday which fixed problems related to GPT. Please make sure to install all updates as well. Since last update gpt execution never finishes


Thank you for the quick-fix.
For those of us who are not familiar with Java - can we have a more detailed explanation please?

Thank you

Have you already tried the first suggestion (without compiling) by replacing the outdated server link? SRTM ZIP-files are corrupted or not found - #46 by ABraun

This should have been fixed by a clean update of SNAP but in some cases this link was not correctly updated.

Since the computer I work on is always offline, I don’t see a reason to fix a server link.
I wanted to try the quick-fix suggested by @traktor but I don’t know how to deal with Java files.
Therefore, the GPT option unfortunately is not an option. I say ‘unfortunately’ since it run much faster that the Snap (GUI) Export StaMPS tool, like 30 time faster. I though it must have something to do with the memory usage configurations but it seems that Snap is well configured by me. :man_shrugging:
However, I made sure that the ‘…auxdata/dem/SRTM 3Sec’ folder is empty and I managed to run successfully the Snap (GUI) Export StaMPS tool, and it even created a dem/projected_dem.rslc file. So I concludes that the GUI can do the work, even though it takes like forever to finish it…

unpack .jar as zip archive, replace class file in unpacked folder, compress to zip, rename to .jar, replace original file