OpenStreetMap
The OSM dataset is a rich database of information about the world. Not only can the data be used to render beautiful and useful maps, it can also be used to do some nifty calculations in conjunction with other open datasets that exist. One such potential use is in cleaning up and improving elevation datasets such as the public domain SRTM or ASTER datasets. Both of these datasets offer elevation coverage over much of the world but they are limited in resolution (SRTM is 90 m per pixel, ASTER is 30 m per pixel).
Although these elevation datasets can be useful for very basic things like drawing 25 m contour lines on topographic maps, if you try to use these elevation models for more sophisticated things like drainage calculations, you will get very weird results due to a number of issues. First, almost no rivers are 30 m wide or more, so the river channel can’t be modeled at all. Second, noise in the elevation datasets often results in river valleys with “bumps” in the river that make it back up and flood large areas that in the real world would really flood because there is a stream draining the water out of the valley. Lastly, in many areas streams, drainage ditches, and other such things often run in close proximity to buildings and other such features. In these areas trying to fix the elevation to correctly predict drainage ends up changing the elevation of buildings as the pixels are so large the whole neighboorhood must be raised or lowered to make the drainage calculations work. The example shown below shows a couple of these issues, and other areas suffer from them in much more signifigant ways.
The original ASTER data at 30 m per pixel.
In order to fix the problems outlined above, and allow for other useful operations it is therefore worthwhile to upsample the horizontal resolution of these elevation datasets. The GRASS GIS system has tools like r.resamp and r.proj which can do things like cubic interpolation which provide nice smooth datasets at higher resolutions (in my example I am using 3 m per pixel, a 10 fold step up from the ASTER data I started with).
The data resampled to 3 m per pixel using r.proj with cubic interpolation.
This resampled data looks much more visually pleasing and if things like contour lines were computed from it they would be smoother, etc, but it still does not necessarily accurately reflect the drainage network topology for flood simulations. This is where the the OSM database comes in.
Because we map streams in OSM and because they are often traced from aerial imagery with resolution on the order of .1 meters per pixel, even very small streams and canals can be recorded with their exact position and shape accurately recorded. Furthermore, we can measure things like the width or depth of the waterway to further improve our data about the feature. This high precision stream path can then be “carved” into the higher resolution elevation model to allow the stream to cut through the small “bumps” intorduced by the cubic resampling. In the example below a 5 pixel wide (i.e. 15 meters wide) channel is cut into the dem everywhere there is a river or stream in OSM. The stream is first “leveled” by iterating over all the pixels in the stream and for each one setting it to the minimum of its own value or the 8 pixels surrounding it (the 3x3 neighborhood). During this leveling step if the pixel is on the stream centerline is is carved down 5 meters below the minimum neigborhood value, if it is along the edge of the stream it is only carved 2 meters below the minimum. Finally, after the carving is done the whole map is run over with a 5x5 neighborhood average to smooth out the river channel into something roughly U shaped to approximate a channel carved out by water, but still ensuring that the center of the channel will be free from major bumps that impede the flow of water in the flooding calculations. The result can be seen below, notice that not only can we now see the irrigation lines in the fields in the center of the image, we can also begin to see the rough cut in erosion pattern in the mountainous regions as well.
The final 3 m elevation model with the stream network from OSM carved into the surface.
The final result is quite nice, both visually and topographically. This is just a first step in this process to demonstrate the basic idea. I plan to do much more in terms of varying the width and depth profiles of the waterways to more accurately model the drainage system and I also want to look at integrating other sources of elevation data from the OSM database such as natural=water which shows a level contour line in the elevation profile at high resultion, natural=cliff and barrier=retaining_wall which indicate “jumps” in the elvelvation model, and also things like road and railway embankments, etc. The 3 m per pixel chosen is just small enough to nicely represent the width of a built up road or rail line or to represent roads “sunk” down a few inches from the surrounding grade due to things like curbs, etc. I hope to hear suggestions on other things from OSM I could use, or how the OSM data itself could be improved to better allow for these kinds of analyses.
EDIT: As requested in the comments below, here is the ‘difference’ calculated with r.mapcalc between the upsampled DEM and the carved DEM. The values in the “flats” i.e. anywhere that is not a river range from about -1 to 1 m and the river are as deep as 7 meters in the places where they cut through a “bump” caused by the cubic resampling process.
The “difference” between the 3 m DEM and the carved DEM.
-AndrewBuck
