externalDEMNoDataValue can greatly change performance

I originally noted this effect in a post about SNAP/S1TBX v8 performance.

Different values of externalDEMNoDataValue affect the performance of both v7 and v8. It is very strange that the DEM no data value can affect the performance so much. I have run many tests to convince myself!

This is the graph, and I am setting the externalDEMNoDataValue the same for both Terrain-Correction and Terrain-Flattening.

externalDEMNoDataValue =  0.0      real 12 min, 350 min CPU
externalDEMNoDataValue = -9999.0,  real 27 min, 550 min CPU
externalDEMNoDataValue = -32768,   real 37 min, 532 min CPU

externalDEMNoDataValue =  0.0      real 2.5 min, 36 min CPU
externalDEMNoDataValue = -9999.0,  real 3 min, 47 min CPU
externalDEMNoDataValue = -32768,   real 6 min, 83 min CPU

You can see the great difference in performance between v7 and v8 here, but that is not the subject of this post. The intent here is to just show the relative difference between different externalDEMNoDataValue, and that both v7 and v8 are affected.
And the other oddity: v8 with -9999 does use a little more CPU than -32768 on the couple tests.

This should be checked @lveci @jun_lu @marpet .

are you using the same dem file? or you have 3 different dem files?

Good question. I am using the same external DEM for all tests, which does not contain any fill: ie, no 0, -9999, or -32768. That was a point that was not clear in my post. Thank you @traktor.

Thank you for reporting the problem. A ticket ([SITBX-894] externalDEMNoDataValue can greatly change performance - JIRA) has been created to track the problem. We will look into it

1 Like

IMH the 0.0 value is not suitable since it is reflection of the real situation on ground and here the question should be is what ‘no-data’ value is most appropriate to be used in SNAP.

The no-data value is constantly causing some problems since years. I’ve been wondering what technological solution would solve it once and for all. A binary mask instead of a value perhaps?

I suggest the “most appropriate” no-data values are the standards: -9999, and -32768. Both have been used on standard (int16) DEM products. Although now that some DEMs are not integer, that may not be appropriate?

Why do we need a DEM no-data value? Most DEMs are complete and are void-filled.

The DEM no-data value just needs to be other than 0.0 since that is a valid elevation. We do not want a performance hit when using other than 0.0