SRTM ZIP-files are corrupted or not found

have you tried SRTM 1Sec instead?
You can also try this: Gpt sentinel-1 back-geocoding error

This solved my issue, thank you for the quick response and have a great Christmas.

1 Like


This issue occurred because the location of SRTM 3Sec (AutoDownload) has changed, so SNAP is no longer able to retrieve it during Terrain Correction, Back Geocoding, Topographic Phase Removal ect.

As a solution:

  • switch to SRTM 1Sec HGT (AutoDownload) or
  • change the location of the data as described here

This will be fixed with the next SNAP update, so please keep your version updated (Help > Search for Updates)

1 Like

I have updated snap version where there looks to be the new directory for the strm but am now getting the following error.

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: java.lang.reflect.InvocationTargetException
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: java.lang.reflect.InvocationTargetException

Same problem here. Our python script returns:

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: error in opening zip file

The SRTM 3 Sec data are no longer located at the cgiar-csi server, so SNAP can no longer access them. This affects

  • Range Doppler Terrain Correction
  • S1 BackGeocoding
  • Topographic Phase Removal
  • Orthorectification
    as long as SRTM 3Sec (AutoDownload) is selected.

A new location has already been implemented, but the latest update does not yet cover all cases.
To go sure, please test one of the suggestions below unil this is covered by the next update.


Please update SNAP (Help > Check for updates), the latest update (8.0.3) fixes the error.

Work around

Select SRTM 1Sec HGT (AutoDownload) as DEM instead.

Manual solution (no longer required)

  1. Go to your SNAP installation directory (e.g. C:\Program Files\snap) and go inside the ect folder where you find the file
  2. Open it with a text editor (maybe needs administrator privilleges) and go to line 27 which defines the location of SRTM 3Sec data. Change it from
    DEM.srtm3GeoTiffDEM_HTTP =
    DEM.srtm3GeoTiffDEM_HTTP =
  3. Save the file and restart SNAP.

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.


Thank you for sharing this solution.
I am using SNAP 7.0 and this solution worked without the wildcard * at the end of the line.


1 Like

thank you, the * was not intentionally placed there, I removed it.

This is still affecting many people who have reported issues in this forum. I know from experience that there are many more who don’t report the issue and may flail around with re-installs, trying different OS’s, adding memory, etc. Some non-reporters will look to documents such as the FAQ, so it could help to add an entry on what to check when a job takes too long.

Some questions:

  1. How do you check whether a workflow other than Terrain Correction, Back Geocoding, or Topographic Phase Removal uses SRTM 3sec files?

  2. what does SNAP do with invalid .zip archives? (The ~/.snap/auxdata/dem/SRTM 3sec folders on one system I checked contained many invalid .zip files. )

  3. should users take steps to remove invalid .zip archives?


these are very good suggestions, thank you. I hoped that this can be resolved within a small update and is fixed within the next days, but depending on the response of the developers we might take more action to guide users which struggle. A temporary FAQ entry is a good idea!

I created a FAQ entry here: A process related to digital elevation models is taking forever to finish

Did I miss a crucial point?

Excellent FAQ entry. Hopefully it will reduce the stream of forum posts on the topic as well as reaching some who won’t post for various reasons like lack of confidence when writing in English.

Thank you for your support.

I did the same methods, but the changes are not saved.
Can you help?
thank you

2021-01-24 12_55_30-snap.auxdata - WordPad

@shahin.jafari75 Please check here:

I tried both, but it still didn’t work.

can you please specify what exactly did not work? Were you able to change the file? Have you tried SRTM 1Sec instead? What happens?

If SNAP somehow tracks which DEM’s have been requested separately from the actual files on disk then treating the files as an external DEM might be required. If there is no tracking, there might be an issue with ownership and permissions of files transferred from another system.

just wanted to highlight that the latest update fixes this problem.

Please still make sure that no incomplete files are left in the aux directory.

Hi Andreas,
I was trying to reproduce the RUS Copernicus webinar on SNAP2StaMPS – Data preparation for StaMPS PSI processing with SNAP.

I was able to follow all of the steps of SNAP2StaMPS workflow except the last one, which is StaMPS export. I have tried to run the scripts using both SNAP version 8 and 6 but got the same result.

Searching the forum, I though it was an issue with the SRTM dem. So, following your recommendations, I changed, and emptied SRTM 3Sec folder. But that does not work either.

Could you please have a look at it suggest what am I missing here?

I am attaching the python script, graph, configuration files for your reference. Note that I was using the High Performance Computing (HPC) facility of University of Newcastle, Australia. I have access to 6 CPUs and 46GB of RAM.

Thanks in advance for your support.

Best regards,
Palash (14.0 KB)