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:

Lake in Cycle Map	Lake in dianacht topo	Lake and river in Google Maps
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

DEM with flattened water areas

with water surfaces

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.

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:

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