SRTM ZIP-files are corrupted or not found

I merged all topics dealing with this error.

1 Like

And orbit files are also affected:

WARNING: org.esa.s1tbx.sar.gpf.orbits.ApplyOrbitFileOp: error in opening zip file
WARNING: org.esa.s1tbx.sar.gpf.orbits.ApplyOrbitFileOp: ApplyOrbit ignoring error and continuing: java.util.zip.ZipException: error in opening zip file

Apparently, everything in snap that downloads a zip fails (it creates a corrupt zip file).

2 Likes

Hello,
I would like to know if these issues are related with downloads made on 3 or 4 December nights, when STEP server was upgraded and restarted or if this still happens with downloads made today.
Thank you for this clarification.

FYI: It seems things have been fixed now. Preprocessing (including apply orbit file and download of EGM96 zip) works ok again here. Did not test the srtm tiles, as we’ve cached those ourselves to not hammer esa’s servers too much. Thanks for the fix!

2 Likes

@vincentschut thank you for you feedback!

A post was merged into an existing topic: Snap Error in opening zip file

2´ ago I was processing Sentinel-1 GRD products using SRTM 1sec HGT and running!, but when I use SRTM 3sec GHT it doesn´t run. I am not sure if my results are good :grin:

Interesting, I have the same issue with ACE30 and GETASSE30. Orbit file downloads without issue though. No issues are present in desktop SNAP

Hallo @ABraun, I am facing the same problem. I am doing an urban footprint with SLC-Product so I am creating the Terrain Corrected image to use for computing the coherence. I am using the ESA Tutorial with the steps: split-orb-cal-deb-ML and finally the TC. I was trying with SRTM 1sec and also as default SRTM 3sec and all the process stops by writing ~20% and doesn’t want to finish the processing at all. Last time it worked was Monday or Tuesday. Then suddenly this bug.
I was using SNAP v8 and v7 for Windows because I thought going to the previous version would be a temporal solution… but no. And also today I switched on my another laptop with the versions for Linux and same story.
Is it possible the issue comes from some SNAP update by ESA? Can’t be it worked fine with same data with same settings and after Monday/Tuesday it suddenly isn’t.
Would be really nice to find out the solution for this problem as soon as possible. Thanks in advance. Greetings.

This happened after the release of SNAP 8, but something has changed - maybe the access to the SRTM data. @mengdahl @lveci
We are currently looking into this.

3 Likes

Hello, I am still experiencing this issue, do you have an ETA on resolution? Thanks.

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

Important

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 http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/srtm_36_02.zip
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_36_02.zip
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: java.lang.reflect.InvocationTargetException
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/srtm_36_02.zip
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_36_02.zip
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 http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/srtm_44_18.zip
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.

Solution

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 snap.auxdata.properties
  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 = http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/
    to
    DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/
  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.

5 Likes

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.

Cheers,
Andrea

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?

2 Likes