Hi, I have been using this code to preprocess S1 data: https://github.com/wajuqi/Sentinel-1-preprocessing-using-Snappy/blob/master/s1_preprocessing.py , but I keep getting the following error.
I can’t understand why it doesn’t retrieve correctly when the link (http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_46_12.zip) works fine.
Any suggestions would be most helpful, thanks!
Yes, this is strange.
Are you still using SNAP6?
In SNAP 7 the default download location should be
http://cgiar-csi-srtm.openterrain.org.s3.amazonaws.com/source/
You can modify the default location in the snap.auxdata.properties file which is located in the etc folder in the installation directory.
Thanks for your response Marco!
Yes, this is SNAP 7, and even with the default download location it still doesn’t seem to be working:
Would you have any other suggestions?
Many thanks 
@lveci Hi Luis, I was wondering if you had any time to investigate this?
Could your server be down perhaps? As I am also receiving a “Connection timed out” error and have thoroughly looked into this on my side.
Any help would be much appreciated, thanks.
This seems like a persistent problem that I keep seeing on this forum and I can’t seem to figure it out either.
In order for the preprocessing to be successful, I have to manually download the Elevation File myself - I’m even using GPT now - I would greatly appreciate if there was a solution for this that you could share or if there is something that I should be trying out.
I have followed the RUS Copernicus Tutorials for GPT, but I still get this same issue pop up!
Many thanks,
Anglina
Unfortunately, we rely on the external server which provides the SRTM data.
We know that it is sometimes slow or not responding but this is out of our control.
The best work around this issue is to download it manually and modify the snap.auxdata.properties file in <INSTALL_DIR>\etc according to the download location.
Thanks for the clarification @marpet
The download location looks correct (same as stated in our earlier conversations).
I am still confused however about the external server. The SRTM data seems to always download when using the SNAP GUI, and whenever using snappy/GPT I’ve had to download manually which defeats the point of any automating - would you have any advice on next steps in an aim to automate S1 preprocessing?
Any advice would be much appreciated.
Same problem here as of today (Tuesday 23 Feb 2021), using SNAP v7.0 and GPT for processing.
An example is
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_59_17.zip
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: error in opening zip file
which is going in a forever-loop and hamper further processing.
No idea what the problem is. Was working fine earlier this week.
This is answered in this FAQ entry:
A process related to digital elevation models is taking forever to finish
With the SNAP 8 and the latest updates (v8.0.3) you should also have no issues any more. There it is automatically fixed.
Dear Marco
I have updated to SNAP v.8 and all the associated updates, but somehow the problem is not fixed and the reason is that, using GPT, it is pointed towards a directory that does not exist.
Therefore the file cannot be downloaded, and this is independently of the file I am processing it seems (in bod characters - if you copy/paste it in a browser, it goes nowhere):
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving **http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/**srtm_59_17.zip
I am using UNIX.
However, if I process the same file using the same graph via the GUI (both on my Windows machine with SNAP v.7 or UNIX with SNAP v.8 GUI), it works.
(It does not make sense to me either, I agree).
Is there something that has changed with GPT?
Just because a browser cannot open the path it doesn’t meant that it doesn’t exist.
Please have a look at the “Alternative 2” solution and try the provided url for a test.
I was able to download it via the browser (MS Edge):
Yes, thinks have changed a bit, but only for the referenced issue above.
The URL you are using is not a default one, right. You have made changes to the auxdata property file?
The fix for the issue [SNAP-1383] SRTM download URL not working - JIRA (atlassian.net) seems to break the URL http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF.
I don’t know where this URL is coming from. The check when to switch to update URL needs to be stricter. @lveci Can you make an update for this or maybe clarify this situation?
David, the changes mentioned in the FAQ entry above should work as a work around for you. Set
DEM.srtm3GeoTiffDEM_HTTP = http://skywatch-auxdata.s3-us-west-2.amazonaws.com/dem/SRTM90/tiff/
Dear Marco and Andreas
Thank you very much for your prompt and very valuable support. This is greatly appreciated.
The issue is now fully resolved, thanks to the detailed posts.
Wishing you both a good end of the week,
David
