Error Retrieving DEM for Terrain Correction Snappy Python

Hello,
So i am doing terrain correction using snappy python, when it’s on the process of retrieving dem i got error,
This how the code:

parameters = HashMap()
  parameters.put('demResamplingMethod', 'NEAREST_NEIGHBOUR')
  parameters.put('imgResamplingMethod', 'NEAREST_NEIGHBOUR')
  parameters.put('demName', 'SRTM 3Sec')
  parameters.put('pixelSpacingInMeter', 30.0)
  parameters.put('sourceBands', 'Sigma0_' + polarization)
  
  terrain = output + date + "_corrected_" + polarization
  target_2 = GPF.createProduct("Terrain-Correction", parameters, target_0)
  ProductIO.writeProduct(target_2, terrain, 'GeoTIFF-BigTIFF')

and here the error line:

INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_58_14.zip

WARNING: org.esa.snap.core.dataop.dem.ElevationFile: http error:http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_58_14.zip on http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_58_14.zip

WARNING: org.esa.s1tbx.sar.gpf.geometric.RangeDopplerGeocodingOp: Terrain-Correction$1679C8206DC error: no valid output was produced. Please verify the DEM

I also tried to use dem manually but still got error, so i replace parameter code

dempath = "dem.tif"
parameters.put('demName', dempath)

error line:
The DEM 'dem.tif' is not supported.

Thank You

[Solve external DEM]
For the last part i come to solve the problem as i see further into the documentation on ‘gpt -h’ as you can use parameter:
parameters.put('externalDEMFile', 'dempath')

The question I have now are:
When running the script, it seems it still tries to auto download DEM which still gives error as a pointed out. I assume when it failed to download DEM, the external DEM will be used.
So, can I skip the process of auto download DEM and just use the external DEM instead?

Thank You

The download service of SRTM data from CGIAR CSI has been updated in November.
The the download location of srtm_58_14 is
http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_58_14.zip

It might work if you change the URL in the snap.auxdata.properties file. It is located in the etc folder of the SNAP installation directory.
DEM.srtm3GeoTiffDEM_HTTP = http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/
to
DEM.srtm3GeoTiffDEM_HTTP = http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/

3 Likes

With gpt at least, changing this config parameter to the new SRTM URL works fine - downloads now work on first try.

Hi,

I’m using the WriteOP operator to write some products in GeoTIFF format after terrain correction. Yesterday everything was running fine, withouth modifying the snap.auxdata.properties file, with my script output being:

INFO: org.esa.snap.core.gpf.common.WriteOp: Start writing product Subset_S1B_IW_GRDH_1SDV_20190614T055037_20190614T055102_016688_01F67F_D492_Cal_TC to /home/developer01/PycharmProjects/S1preprocessing/Output/s1b-iw-grd-vv-20190614t055037-20190614t055102-016688-01f67f-001.tif
INFO: org.esa.snap.core.dataop.dem.ElevationFile: http retrieving http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_37_03.zip
WARNING: org.esa.snap.core.dataop.dem.ElevationFile: http error:http://srtm.csi.cgiar.org/srt-zip/srtm_v41/srtm_data_geotiff/srtm_37_03.zip on http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_37_03.zip

Writing TIFFs was very quick with subset IW GRD images (10 to 40 seconds), but as I was testing some changes in the script, it started to get slower and slower: first over 100s per TIFF, then over 300s, until it got stuck completely.
Clicking the URL http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_V41/SRTM_Data_GeoTiff/srtm_37_03.zip opened a page saying “Content not found” in Spanish, instead of a direct download.

However, changing the URL in the properties file with the one found in this topic fixed it and now it seems to work fine again. I can’t compare the current download & writing speed with yesterday’s, since I won’t be able to access that workstation for the next few days, but it seems reasonably fast even on a VM running on my laptop.

If the legit URL for downloading DEMs changed in Nov’18, does anyone have any idea on why the product writing ended succesfully with the old one?