Issues applying (external) DEMs in SNAP

Dear all,

I have been reading trough several subjects related to using (external) DEMs in the SNAP/S1 toolbox, but none of the topics seem to provide solid answers. Therefore, I am posting my own overview of DEM issues.

My processing chain roughly involves the following steps:

read (2x, master & slave) - apply orbit (2x) - TOPSAR split (6x, 2 times 3 subbands) - back geocoding (3x, coregistration) - interferogram (3x) - TOPSAR deburst (3x) - TOPSAR merge - topographic correction - Goldstein filtering - write

I am using S1 data over Svalbard (without precise orbit data available).
The external DEM I have is a 20m DEM in WGS84, UTM 33N covering entire Svalbard. I tested a few different ones in different coordinate systems, but no luck.


  • When running a previously saved and reloaded xml file, the processing stops with this error:
    Back-Geocoding: computeSlavePixPos: java.lang.NullPointerException
  • Sometimes when Back-Geocoding using Aster GDEM the processing stops with this error: Empty region!
  • When entering an external DEM (in back-geocoding, remove topo-phase and geocoding), this error immediately shows up (and processing cannot be started): org.esa.snap.framework.gpf.graph.GraphException
  • Topographic phase is purple using Aster GDEM and is consequently useless.
  • Topographic phase removal with Aster GDEM sometimes gives the following error after approx. 75% processing: A problem occured during processing the target product processing. Type: OperatorException. Message: null.

It is possible to use an external DEM to do terrain correction (geocoding of SAR to map coordinates). However, the same DEM is not useful for other purposes.


  • Are these bugs (think so) or related to my DEM?
  • What are the desired input parameters for an external DEM (coordinate system, ellipsoid, coverage (more than 100% or can it partially cover the data?), other metadata)?
  • When is it most efficient to apply topographic phase correction? After merging of all 3 deburst subswaths or before merging?

Cheers, Jelte

1 Like

Thanks @lferreira, tried that (checked the DEMs for holes and coverage as well). I still get the error message listed above. No luck so far.

I deleted my post after read again what you wrote and test back-geocoding and topographic phase removal, with an external DEM. I also get the message “org.esa.snap.framework.gpf.graph.GraphException”… :slight_smile:


  1. I can confirm your issues. I tried my own DEM in different projections. I also loaded the DEM in snap (no problem) and exported it using different data formats (Geotiff, Envi, BEAM). No improvement at all. The external DEM option is not working at all.

  2. Another thing is that NaN is not accepted as valid no data value.

  3. When using GETASSE30 than a very strange looking topophase is created. I found that the GETASSE tiles are in little endian format. One needs to swap the data before it can be used.

  4. One work around using an external DEM is to replace SRTM or GETASSE or ASTER tiles by interpolating your DEM to the given tile lat/lon coverage and write it to auxdate/dem directory … It is some work but could be done.
    I tried it and it worked without error message, however the resulting interferogramm is not what I expected. I think there are also issues with the interformtrie or georeferencing tool.



Interesting work-around @vhelm, I will try that one. But this work-around should not be the way to go in the future.

So, a question to the developers/SNAP managers: are these issues going to be addressed anytime soon? Would be great to know in order to use on work-arounds for the time being or other software that can deal with external DEMs.


Yes, I this will be addressed, maybe @lveci can say something about the timeline. To help us to fix it it would be great if you send us the log file.
After you have experienced this error please have a look into the .snap folder inside your <USER_HOME> directory. There you will find the file messages.log inside var\log.
Inside this file there should be more information about this error. Please attach this file here.



Thanks @marpet. I saw the External DEM issue is listed on the issue tracker (senbox), great. Hereby the file that I found in .snap/system/var/log/ (I didn’t find any file in .snap/var/log/).
nfs000000003c6921df00000322.txt (80.3 KB)

I also added the screen output that I got during the same operation:
screen-output.txt (5.3 KB)

Let me know if you need more info.

Is there anything know about the timeline (it has been 1,5month since the issue was raised), @lveci?

I am still encountering this issue with SNAP 2.0.2, S1TBX 2.0.2.

Specifically, if I run ‘TOPSAR Coreg Interferogram graph’ and chose the ‘External DEM’ option for the ‘Back-Geocoding’ tab.

Terminal output attached.
external_dem_error.txt (3.1 KB)

I’m using the hole-filled DEM product from NASA LPDAAC:

I even tried moving the auto-downloaded DEM from ~/.snap/auxdata/dem/SRTM\ 3Sec/ to a different directory and selecting this as the external DEM and the same error shows up. Seems like a bug…

Hi friends,
I am facing same problem while using S1-TOPS co-registration module, my area in in Antarctic near Princess Astid Coast,
this area is not covered under SRTM and Aster data is not of good quality so i had to use RAMP-v2 200m DEM (in stereographic projection) of Antarctic,

but it gives error: Back-Geocoding: computeSlavePixPos:java.lang.NullPointerException
i have tried to change DEM to Aster 1s auto download, but still same error,

my SNAP is is latest version 3.0.0, Kindly help in solving this problem

Is this problem solved?
I have tried to use some external DEMs in different formats and I am having the same problems as the rest.

Eduardo Ramos.

I recently tried to use the external DEM and it worked. I resampled the DEM to be greater than the radar pixel and made the GeoTiff in WGS 84 and it worked.


The DEM you applied resampling had a worse pixel resolution than the IW images? I am trying to understand how the software works in this aspect because all the tries I have made failed :grin:

I have now been using the 12.5 Alos Palsar 12.5 m DEM with WGS 84 Datum and clipped it to my region of interest. Now it is working even without resampling. When I specify the cropped DEM, it gives me the result only to the extent of the cropped DEM. I have SNAP version3.0.


I have the dem in Tiff format mosaiced in ENVI.

Maybe that could be the solution to my problem, I’ll try it, thank you Karksita!!!

1 Like

Unfortunately nobody says a good answer. I tried with different DEM’s but is impossible. Only SRTM3. I used a big DEM to cover all the scene, I corrected the holes and I have used WGS84. My conclusion is not possible, I used it to calculate the phase to displacement but with the SRTM3 the motions are around 5 cm in 20 days. Something is wrong.

I have noticed that, with the new update for SNAP, the coregistration option is able to use external DEMs. However, after I made some tries with different DEMs that I have, I realised that this option only works with the DEMs the software downloads, unless I am making any type of mistakes. What are the requirements the external DEMs have to accomplish so they can work with the software? DEM size or type? pixel size? Anyone could help me please?

PD: if I take the DEM (for example SRTM 3 sec) downloaded by the software and I cropped it to my region in interest (the DEM bigger than the region of course) the coregistration procedure ends without generating an error but the resulting product is empty, like with no information.

Hola,I am new here.Same error ,when the progress bar excute till 75%. Which DEM choice ?THX


I am trying to use Finlands TM35FIN gridded dem in a WGS84 GEOtiff.
As the tif is almost 10G, I wonder if one issue is that snap is not supporting BigTiff GeoTiffs. At least not for writing them out from gpt!

I guess I’ll try to tile the dem into smaller sets, but I would need a little guidance on how they should be arranged so gpt gets to use them. On the command line one can only define one file, can this be a gdal virtual mosaic? well anyway there seems to be too little documentation on how an external DEM needs to be formatted!