S1tbx auxdata settings (avoid autodownload)

Hi,

How can I force snap to not automatically download the DEM (during terrain correction) and use the DEM dataset that is already available in some other directory?
It worked with the older version of S1TBX by changing the DEM path in “~\S1TBX\config\s1tbx.auxdata.config” file. I tried the same procedure with “~\snap\etc\snap.auxdata.properties” file, but still it is trying to download data from http://srtm.csi.cgiar.org/ . Is this hard coded?!

For dem tiles which exist in your auxdata folder, it shouldn’t try to download new tiles. With SRTM, there are tiles missing usually in the ocean. The software doesn’t know if it really exists or not so it tries to find it online. If it’s not found then it truly doesn’t exist. We should use a look up table for all these ‘non existant’ tiles.

It is ok if the software downloads the missing files but how can one change the DEM directory where the toolbox is searching for the aux data? If you run the toolbox for mass data processing within a cluster, it will download the required DEM in a fixed directory (C:\Users\username.snap\auxdata\dem…) at each node again and again for each scene which is completely inefficient. As I understood, the software should check the “DEM.srtm3GeoTiffDEMDataPath” field in “~\S1TBX\config\s1tbx.auxdata.config” file for the DEM data. This was working in earlier versions but apparently either there is a bug in snap 4.0 or you disabled this by intention.

I’ll look into it. It did used to work that way.

On multiple nodes, you should reuse the whole .snap folder

Edit the file SNAPInstallFolder\etc\snap.conf and change the line
default_userdir="${installer:sys.userHome}/.snap"
to
default_userdir = your_new_path

1 Like

so it means setting individual directories for DEM, orbit files,… in snap.auxdata.properties is not working anymore in this version?

The backgeocoding step in IW SLC coregistration fails to advance because it continues to look for a non-existing SRTM tile:

http://step.esa.int/auxdata/dem/SRTMGL1/N52E003.SRTMGL1.hgt.zip

(indeed non-existing, because in the North Sea). I started a gpt batch late Friday and discovered this morning that it did not work.

I will create a dummy tile in .snap to be able to continue, but this is a somewhat silly issue. Instead of using a LUT with missing tiles, the program should check whether the URL exists, and assume zero height if is does not.

It throws these errors now:

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://step.esa.int/auxdata/dem/SRTMGL1/N52E003.SRTMGL1.hgt.zip
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: Connection refused

which is not correct (it is not a connection refused exception).

Guido

Correction: I seem to have a proxy problem as well. Backgeoding also fails for valid tiles, bacause of Connection refused.

So, additional question is how to get gpt to work correctly with a proxy installed? I have $http_proxy and $https_proxy defined, but snap/gpt does not seem to read these environment variables. In snap, I have to explicitly include them in the WWW settings. But how should this be done for gpt??

Guido

Thanks Guido. We’ll investigate the issue.

Is it possible to switch off autodownload? I get the same error even for tiles that are already in ~/.snap/auxdata/dem/SRTM\ 1Sec\ HGT/

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://step.esa.int/auxdata/dem/SRTMGL1/N46E007.SRTMGL1.hgt.zip
SEVERE: org.esa.snap.core.dataop.dem.ElevationFile: Connection refused

I am also having similar problems.
My SNAP installation runs on a server behind an internet proxy. Updating SNAP works just fine suggesting it is using the server’s proxy settings. Downloading ancillary data however is not possible (connection refused).
I tried downloading the data myself so that SNAP can just use the files, but this doesn’t work either because of this issue here.
Any news on this?

1 Like

I have the same problem, even with 7.0 version.
Do you know hav to avoid auto download when SRTM data are already on the local disk ?

Hi, I’m having a similar problem.
I’m trying to apply the orbit file and get the error message below –
“Error: [Nodeld: Apply-Orbit-File] sun.security.validator.ValidatorException:PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target due to PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:unable to find valid certification path to requested target.”
this seems to be similar to problems discussed in step forum many times. I believe the answer is to copy the orbit files to my workstation and redirected the retrieval to the workstation. I am not a programmer so tried using information from forum discussions. I redirected the AuxDataPath and OrbitFiles path in the snap.auxdata file, reassigned the snap user directory (-Dsnap.userdir=NewPath) and copied the orbit files http://step.esa.int/auxdata/orbits/Sentinel-1/POEORB to the NewDirectory keeping the directory structure. unfortunately, the error persists. I am doing something incorrectly. are there straightforward instructions that I can follow? thanks