Snap tries to download dem that does not exist

Hi,

I am using srtm 1sec dems for pre processing sentinel 1 data and found that the toolbox hangs for a very long time trying to download this dem which does not exist: N51W007.SRTMGL1.hgt.zip

It is not in Index of /auxdata/dem/SRTMGL1 and I can also not find it in earth explorer: https://earthexplorer.usgs.gov/

I assume it is not a problem because this is just sea but why does snap hang there for so long?

This is the log messages.

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://step.esa.int/auxdata/dem/SRTMGL1/N51W007.SRTMGL1.hgt.zip
WARNING: org.esa.snap.core.dataop.dem.ElevationFile: http error:http://step.esa.int/auxdata/dem/SRTMGL1/N51W007.SRTMGL1.hgt.zip on http://step.esa.int/auxdata/dem/SRTMGL1/N51W007.SRTMGL1.hgt.zip

I can provide a script on how to reproduce this if anyone needs it.

Based on the error message, SNAP tries to access the old server location for DEMs.
Did you see this? FAQ: A process related to digital elevation models is taking forever to finish

Updating to SNAP 8.0.4 solves it.

It says there

Alternative 1: Select SRTM 1Sec (AutoDownload) instead whenever possible. These should work regardless of the location of SRTM 3Sec data.

This is exactly what I do here.

The url exists and the dems download just fine - except the ones that do not exist such as the one I mentioned N51W007.SRTMGL1.hgt.zip but also for example N54E001.SRTMGL1.hgt.zip and N55E001.SRTMGL1.hgt.zip . The location of the filename indicates that they are somewhere in the ocean and hence it makes sense that they do not exist.

My question is: should snap event try to download them if they contain no information? Also, if I read the logs correctly it can take snap up to 10 minutes to proceed when the file is not here. Is there a way to sped that up?

Also, I think the documentation is not correct and skywatch-auxdata bucket should be used as stated in the documentation event for srtm 3sec. Last time I checked it was not accessible which (amongst another issue) spawned this thread: 403 for skywatch-auxdata bucket

sorry, you are right. I mixed it up with the changed server of the orbit files…

I remember a similar case: SNAP searches non-existent SRTM tiles

Hm. OK thanks. Unfortunately I do not always know in advance which file will be used and creating them manually will be painful I think. Is there any way to speed up snap in case a dem is not there?

@jun_lu Could a flag “don’t fail if no elevation data is found” be added to the terrain correction module, similar as in “Apply Orbit”?