German version

Flattening water areas in DEMs

When remotely sensed elevation data (especially SRTM and ASTER GDEM) is used for Geo-Visualization purposes this leads to a number of problems that can be widely observed in maps. Most of these issues are related to mismatches between the elevation data and other data used for producing the map. I here want to show how some of these problems can be addressed.

The problem of water surfaces in elevation models

Water surfaces in nature have a very special relationship with the terrain topography that can be described by a simple set of rules:

  • Waterbodies without significant waterflow (i.e. lakes) have a near perfectly flat and horizontal surface.
  • Such waterbodies are always fully surrounded by terrain with elevations at least as high as the water level except for the points of outflow.
  • Flowing water always takes the steepest path downward at any point in the terrain.

In reality the forces of nature modify both the terrain and the waterbodies to comply with these rules. When maps are produced using independent data sets for both the terrain and waterbodies these rules are often broken quite visibly leading to obvious errors in the map. A few examples from current web maps:

Cyclemap example dianacht topo example Google Maps example
Lake in Cycle Map Lake in dianacht topo Lake and river in Google Maps
OpenTopoMap example Geofabik Topo example 4umaps example
Lake and river in OpenTopoMap Lake in Geofabik Topo Lake in 4umaps

As can be seen the most common problem is contour lines intersecting lakes (violating the first rule above). While other problems are nearly always related to some kind of accuracy issues this particular problem is unavoidable when using remotely sensed data without post processing. I will here introduce a method to process the elevation data to flatten lake surfaces and ensure contour lines do not intersect them.

Flattening water surfaces

It is fairly straight away to set all DEM data points of a lake to a known lake elevation. This will however often violate the second rule in the list above and will also frequently generate artificial cliffs at the lake shores. For good results the second rule needs to be enforced through elevation changes as well and the modifications need to be tapered off to avoid unnaturally steep features. The program used for that can be found on github.

Another application of this technique despite production of better 2D maps, in fact my primary motivation to develop it, is explicit rendering of water surfaces in 3d views. Therefore I illustrate the results here in 3D using the region around Lake Léman as example:

original DEM without flattening
original DEM without flattening

DEM with flattened water areas
DEM with flattened water areas

with water surfaces
with water surfaces

geometry detail
geometry detail

The flattening tool also generates a POV-Ray mesh for the lake surfaces. Note these are huge files, often lager than the actual DEM and in practical use there are some accuracy issues. If you render flat terrain without the need for the lakes to properly follow the earth curvature a simple polygon based on the original lake data will usually be the better solution.

Here an example of the same area using the flattened DEM and the water meshes for a 3d view with proper reflection on the lakes.

3d view example of Lake Léman

And the same perspective with only the lakes:

And finally an example of contour line renderings (generated using gdal_contour) based on the processed DEM:

Before processing After processing

Note the contours can still intersect the water surfaces due to the limited resolution of the DEM raster. To fully avoid this you would have to modify the water polygon. Combining with relief shading and contour labels then looks like this (Link on the image opens the same area in the OpenCycleMap):

A sample data set for the Lake Léman area is available for download. The base DEM for this is a merge from SRTM and ASTER GDEM and has not been optimized for contour line rendering.

Consistency check as a byproduct

By changing the elevation data based on the waterbody geometries we assume the waterbody data is exact while the elevation data is less so. In reality both data sets have a limited accuracy and even more the error bounds of the elevation data are usually quite precisely known while the waterbody data is often of much more varying reliability. How much the elevation of the DEM needs to be changed during flattening is therefore a useful hint for possible errors in the waterbody data. My tool produces a list of points where the error exceeds a certain threshold. The results of this can be seen for parts of Europe in this map.

How about the rivers?

You might have noticed i have not talked about the third rule in the list above. For the lakes we know they have a constant elevation which very much simplifies the whole process. For the rivers the elevation profile is not known and modifying the DEM is therefore much more difficult. Without a consistent river network with known flow structure this would be very difficult and i have written about the problem of producing such from the Openstreetmap data in a separate text.

Christoph Hormann, September 2013

Visitor comments:

no comments yet.

Leave a comment
You have to enable Javascript to be able to write comments.
human verification Please enter the code you can see in the image on the left to verify you are a human and not a spamming script.
* * Required field
Information about you
will not be made public
will be displayed with your posting
Your comment (no HTML)


If you want to send a private message to the author of this website you can do so via Email.

The comments will be reviewed before they are added to the site. So you might need to wait some time until your entry turns up.

Please note this comment function is intended for commenting on the text and images, not for discussing political or religious views. Comments with no relation to the content of this site will not be approved.