SRTM 1 Sec HGT DEM won't autodownload

I am attempting to geometrically terrain correct some radar imagery from various locations around the world. I would like to use the SRTM 1 Arc second DEMs, and preferrably the ones that autodownload so I don’t have to go around and collect them all. I select the SRTM 1Sec HGT (Autodownload) for my Range-Doppler Terrain correction, but the RTC is only done for a small portion of my test radar image near the Red Sea. From what I understand, the SRTM 1 Sec DEMs should be available from ±50 latitude, well within my regions of interest.

Is this failure to autodownload the DEMs common?
Is there a way to correct it?
If not, what is the easiest way to incorporate my own DEMs? As individual tiles? As one giant mosaic?

I am running SNAP 5.0.8.

1 Like

Recently I encountered SRTM download problems from http://step.esa.int/auxdata/dem/SRTMGL1:

SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: Server returned HTTP response code: 403 for URL: http://step.esa.int/auxdata/dem/SRTMGL1/

It seems to be an user access problem (error 403) to http://step.esa.int/auxdata/dem/SRTMGL1, and also other folders in http://step.esa.int/auxdata (I got errors for downloading orbit data as well).

Downloading 3" SRTM tiles works without problems, as these tiles are downloaded from a different source (srtm.csi.cgiar.org)
It is not clear why ESA changed access to their SRTM 1" HGT and orbit directories. A work-around is downloading 1" SRTM tiles yourself and put them somewhere, nevertheless autodownload will be preferred.

The version of SNAP, I am using 6.0.1 and tested also older versions, did not make any difference, the ESA server is the bottleneck I suspect.

1 Like

Yes, you are right. There are at the moment problems with the server, but we already working on it.
The server is suffering from unusual high workload.
We do our best to fix this soon.

Hi @marpet . Thank you for looking into this issue. It seems that whilst the servers were under load, the Terrain Correction module would continue to request data from the SRTM server on a loop. These requests seemed to be continuous and did not time out automatically if the data was not available, presumably continuing forever.

I have simulated this behaviour by turning off the internet to my machine and attempted to process a product where the SRTM tiles are not available in the local cache. Please see the attached video demonstrating the real-time frequency of server requests.

We were unaware of this behaviour over the weekend, and did not know that the processing chain would continue to do this. This seems to have caused our Amazon node to be reported for a suspected DDOS attack on the ESA server during this time, probably related to the frequency of requests created by SNAP.

I am querying whether this module of SNAP will be updated to better handle failed requests from the server if not successful after a certain period of time, or number of attempts. It might also be beneficial if there was more of a longer delay between requests, so as not to overload the SRTM server in times of high demand.

Otherwise, I am wondering if there are any other steps that we can take to ensure that the processing does not simply wait indefinitely for the SRTM to become available in case of future server downtime, and to reduce the load this might cause on the ESA systems.

===
EDIT:
I have discovered that the Terrain Correction procedure will contact the tile server, regardless of whether or not the tile already exists in the local cache. This is presumably to checksum the local file against the one on the server, to re-download if necessary.

Can you please confirm that this is the expected behaviour, as the processing will still halt if the external server is down, even if the tiles are available on the machine?

Hi Marpet,
It seems there is a problem in downloading (Auto download) SRTM 3Sec in SNAP, Range Doppler Terrain Correction. If yes, which way do you suggest to solve my problem? I have to done my work soon.

Thanks,

It seems to be working fine. You’ll need to be more specific with your problem.

SRTM 3sec should download from a new location with update 6.0.6

Hi

I installed 6.06 and it still does not seem to be working since my interferograms are full purple. I’m using the same graph processing chain that I used previously and it was working then. There are also no error messages indicating where exactly the error is.

I also have this problem where when I’m connected to a network the graph freezes until I disconnect from the network click Run and then quickly switch my wifi back on since the SRTM 3 sec needs to be autodownloaded.

After installing 6.06 I decided to check for updates to see if anything else was released but I continually get the Connection Reset error?
Please assist. Thank you.

Hi All, Despite all posts I have read, I have the newest version and all, but my SRTM 1Sec HGT (AutoDownload) doesn’t work, it downloads 1Kb zip files, and even if I manually download them and placed the zips in , also place the content renaming with the name of the zip, it does not work.
Might it be because I also get an error when I test my COnnection? I do not use VPN and opened a port 443 or similar… I am wondering why It still fails on my machine with the latest update
Help would be appreciated as this is stopping me from doing my work

Hi All,
We tried debugging this SRTM issue and found that this is a certificate issue on sever side.

The issue can be replicated using the following step:

Error:
wget SRTMGL1/N56W131.SRTMGL1.hgt.zip

–2023-06-24 19:23:24-- N56W131.SRTMGL1.hgt.zip
Resolving step.esa.int (step.esa.int)… 37.252.127.80
Connecting to step.esa.int (step.esa.int)|37.252.127.80|:80… connected.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: N56W131.SRTMGL1.hgt.zip [following]
–2023-06-24 19:23:24-- SRTMGL1/N56W131.SRTMGL1.hgt.zip
Connecting to step.esa.int (step.esa.int)|37.252.127.80|:443… connected.
ERROR: cannot verify step.esa.int’s certificate, issued by ‘CN=R3,O=Let’s Encrypt,C=US’:
Unable to locally verify the issuer’s authority.
To connect to step.esa.int insecurely, use `–no-check-certificate’.

One Way to Resolve this is to set the following flag in wget:
wget --no-check-certificate link_2_File_N56W131.SRTMGL1.hgt.zip

the above command will work and SRTM will be downloaded.

I believe this can be resolved from the server side, instead of changing the snap code.

1 Like

There are currently some problems with the server, which we are already working on.
We’re trying our best to solve the problem quickly.

Hello,
The problem has been fixed. Could you please take a moment to let us know if you are still experiencing any further issues?

Thank you!

Hi Diana, I appreciate you guys are working on it.
But the software is stuck in downloading the files, and then downloading them over and over.
I have posted a screenshot below of the .snap\auxdata\dem\SRTM 1Sec HGT folder.
As you can see in the screenshot I snipped the moment where the file seems to be downloaded, but then it quickly turns to 0KB, and both the files do this over and over in a loop. Since I know where the files are downloaded from, I tried to put the files and also their content in the folder but it overwrites them and starts the endless loop. By the way clearing the folder doesn’t fix it, just so you guys know, thank you.

Hi @Relor91,
Do you still have this problem? After checking the logs, I think your actions overlapped one of the last maintenance tasks performed on the server.

Hi Diana, yes I do still have exactly the same problem.
I have attached again another screenshot, adding the WWW options. I wanted to also add that the connection test fails (I am not using a VPN just to clarify), I have tried all combinations of “Web Browser”, also using No Proxy. Maybe this is where the problem lies? Maybe I need to open some doors? Maybe Use a manual proxy?
Thanks again for looking at this

Hi Diana, sorry but also changing my IP produces the same error:
My IP now ends with .19, yet the same error…
PS: I have used my mobile as an hotspot, so it keeps changing IP, yet they are all different from 0.

@diana_harosa, snap is working perfectly now for us, thanks for helping.

I fixed it. And it had nothing to do with my PC or my Connection. I did uninstall and re install the software multiple times, but it only worked when I didn’t install any extra Sentinel toolboxes, I only installed Sentinel 1 toolbox and then it worked… So it is a Software problem
Cheers