OpenTerrainModel

Note: All of the ideas discussed here are intended to be implemented in a separate OSM database. Please do not add any of the tags discussed here to objects in the main OSM database.

Open Terrain Model (OTM) is a proposed sister project to Open Street Map which implements a worldwide 3d terrain model stored in a vector format in an OSM API database (not the main database but an API instance running in a separate DB) which contains contour lines for elevation as well as other surface topology type information which may or may not be suitable in the normal OSM database (things like locations of cliffs/ridges, peaks, saddle points, local minima, etc). Although some of this is already mapped in the main OSM DB (and it can be left there and merged on the fly when necessary), other things like contour lines are not currently and probably should not be stored in the main OSM database. The idea is to develop a proper vector format way of storing the elevation model along with a frontend interface that can return elevation and surface topology information in a variety of formats which is generated on the fly by querying and processing data retrieved from both the OTM database as well as the main OSM database. This allows users to put in queries for elevation and related surface model data in a unified format of their choosing over any point in the world, or along a given path, or as a raster or vector result over a specified area (for example asking the server for hillshading over an area, or vector contour lines at 10 meter intervals suitable for rendering directly on a map).

A simple example would be to submit a request asking for a raster elevation file over a given bounding box subsampled at 1 meter horizontal resolution with floating point format for the raster values. The server would start by querying the OTM database to get the best currently available elevation contours for a given area, and then merging into that file a query for the same BBOX in the main OSM database to retrieve waterway, cliffs, peaks, lakes/coastline, railway lines, and other features that give hints about elevation. Then using this temporarily combined vector layer an algorithm starts with the raw contours interpolated to the given resolution and then refines this model by doing things like carving out streams and building up roadways and railways slightly to generate a "best guess" of the actual surface model before returning the final raster result.

In addition to simple elevation models like this which just represent the ground, a user would be able to ask for other kinds of terrain related data as well. For example, the user could ask for a raster map showing the height of obstructions over and above the base ground elevation to account for things like buildings, towers, forests, etc. This height map would be zero everywhere by default and positive where any tall obstruction exists, someone interested in the true height of the terrain can then go cell by cell and add this value to the terrain height to obtain the true obstruction height over that area (for example to compute how high an airplane would have to fly to miss the obstructions, or to compute how wind might flow through an area, etc). The terrain model will also account for the fact that our planet does not have a simple 2 dimensional surface, but rather there are things like lakes/rivers, where there is a surface height and a water surface height which is not necessarily level; there are also bridges where there are two or more solid surfaces (the ground and the surface of the bridge); and finally there are tunnels which allow someone to get "over" a mountain without actually having to walk up one side and down the other, but rather, to take some nice level or gently sloping route from one side to the other. All of these features are currently ignored by common elevation models such as SRTM, NED, or ASTER giving an incomplete picture of the actual surface topology, even though much of the data to correct for these things already is or could be mapped in a croudsourced way by the OSM community. Lastly, even the best available elevation data typically available has resolutions on the order of a few meters per pixel, whereas we can map things like a riverbank or a coastline to an accuracy of centimeters from GPS traces and satellite imagery allowing for interpolation to be much more accurate around these features when this information is taken into account, we can also precisely locate and measure the elevation of things like mountain peaks which are often "smoothed" out to some erroneous value by the sampling algorithms that make a rasterized elevation dataset out of the raw RADAR or LIDAR data that were actually measured.

The reason for creating such a sister project is twofold:

• First to provide a way to gather, refine, and update publicly available elevation data as well as to allow it to be properly aligned and clipped to things in the OSM database (so lakes don't "climb" up mountains where only low res elevation data is available for example).
• And secondly to provide rich surface information about the terrain model which is not readily available from other sources in a worldwide consistent format. Things such as surface coverage (rock, grass, trees, etc), obstruction heights (for buildings, towers, bridges, etc), slope and surface roughness maps in raster format, etc, all in a variety of raster, vector, or 3d mesh formats, sub-sampled at a user specified resolution, and generated on the fly using the latest available elevation data and manually mapped objects in the main OSM database.

Although much of the underlying information that this system would provide can already be pieced together from existing sources (such as SRTM data for elevation, ASTER data for surface coverage, etc) there is not a single unified service to serve this data to user "on the fly" to people in a consistent worldwide format where preference is given to more detailed data where available or by making use of what is in the OSM database (for example where we have mapped landuse we often have it mapped at orders of magnitude higher resolution than typical landuse data is available at). This means that whenever you query the service you will get the most up to date and highest resolution data of that type available by combining together multiple different public domain datasources and the croudsourced info from OSM into a single unified picture of what the world actually looks like in reality. Finally, as users edit the underlying road and river data in the main OSM database, or edit the underlying contour data in the OTM database (by aligning contours from different elevation sources, or by updating for earthmoving projects like the construction of elevated roads or dams, or by deleting errors such as data spikes or "mole runs" in the elevation data from a given source, etc) a consistently better and better picture of the worlds surface can be developed. This also allows us to properly align and average multiple elevation sets to get nicer results, extend elevation models across the whole world (for example SRTM is only available to ~60 degrees north/south), and also to extend elevation models "down" under the surface of lakes or oceans by combining bathymetry data right into the same database (since water levels rise and fall arbitrarily and even the best available LIDAR data for elevation maps often has phony "flat" surface over lakes and oceans where the LIDAR just measured the water surface), or where the elevation data is incorrect since it measured the height of buildings or trees, rather than the actual ground height.

Implementation

The fundamental idea behind this project is that, although contour lines are a different way of storing elevation data than more traditional raster or mesh representations, they can be converted to the other storage methods relatively quickly while nicely preserving the actual height detail in a meaningful way. For an example of how effectively contour lines can be converted back into more traditional elevation models see this page on the GRASS GIS wiki. There they start with a relatively simple base contour layer of a valley with a river running along the bottom as well as a couple of built up roads in the area and turn it into a bunch of raster and/or mesh models displayed in a the GRASS 3d viewer. The different conversion modules all do a better or worse job at representing different parts of the area more effectively. The basic idea is to build an example infrastructure using a separate OSM API database storing the base contour lines, and build a simple web service frontend which calls a script that takes a request from the user and generates a result file based on their query. The script will perform overpass queries against both the OSM and OTM database instances to generate an "extract" of the contour lines and additional elevation related objects for the area of interest and the run it through one of the GRASS modules described on the page linked above to turn it into the format the user requested. After the initial infrastructure is in place to take requests from the user, run them through the GRASS system, and feed back the results to the user further work will begin on using other data from the main OSM database like peaks, rivers, roads, etc, to further augment the contours stored in the OTM database before they are rasterized. This means that people can improve the OTM elevation model in two ways, first by directly editing the contour data itself and secondly, by simply improving the normal OSM data in the main DB using the standard mapping methods. Any improvements to either dataset will then be automatically pushed through to the raster files returned to users of the system, allowing the elevation data to be easily improved in a croudsourced fashion.

Tags of interest

In addition to the raw contour data which is imported or created by users in the OTM database, the server will also perform queries to extract live data from the main OSM database that is of use in further refining the elevation or surface terrain model. The items queried from the main database fall into one of two categories:

• objects which give hints about the actual terrain elevation model such as rivers, streams, lakes, swamps, coastlines, ridges, peaks, cliffs, and other direct elevation information, and secondly...
• objects which alter the actual terrain elevation and add or subtract further height from that such as buildings, walls, towers, dams, trees, forests, elevated roads or railroad tracks, etc.

The two tables below represent lists of the first and second types of objects, respectively. Each table outlines the types of objects to be queried in the area of interest and what kind of information they can provide to the elevation model. These individual elevation hints will be turned into a set of contour lines which are superimposed on the existing contours in the OTM database to form the final contour set that gets passed to the GRASS GIS contour-to-raster routine.

Type(s)	Tag(s)	Hint Type	Description	Mathematical Description	Notes
	natural=peak natural=depression natural=saddle	Absolute r. r..	A mountain peak (local maxima), the lowest point in a valley or plain (a local minima), or a saddle point in the elevation dataset. If no ele=* tag is specified the peak only gives relative elevation information indicating that it is probably somewhat higher than the surrounding average terrain. With an ele=* tag the absolute elevation at the peak can be taken as exact with approximate elevations falling off nearby. There are two parameters to specify how "sharp" the peak is (how the elevation falls off as a function of distance from the peak). These parameters are the first and second derivatives at the point of the peak (herein referred to as r. for the first derivative and r.. for the second). The r. parameter would specify the linear falloff rate in a unitless quantity (for example meters down in elevation per meter distance away from the peak in horizontal distance), with the r.. parameter specified similarly (in units of something like meters down per meter hz per meter hz) to specify the "curvature" of the peak. These can actually be measured easily in the field with a standard GPS fix for the lat-lon position of the exact peak and with a few horizontal and vertical measurements near the peak to compute the slope and curvature of the surface. This offers the simplest thing that user can measure starting today with only something like a tape measure in addition to the normal surveying equipment since the r. and r.. values can be measured by a mapper even if they cannot measure the true elevation of the peak (which GPS does a poor job of).
	natural=cliff barrier=retaining_wall	Absolute r.	Cliff ways are drawn in OSM like coastlines with the higher elevation to the left of the line and the lower on the right. The cliff may have an ele=* tag which indicates either the top or bottom cliff elevation (how does this work?) as well as a height=* which specifies the relative elevation change "across" the cliff. For cliffs which rise or fall along their length the ele and height parameters can be put on the individual nodes instead of the way (where they would be taken as constant for the whole cliff). Additionally although it is not currently tagged you could also have some sort of vertical_angle=* which specifies the angle of the cliff face to indicate whether it is exactly vertical, or whether it is something like a retaining wall which is sloped back a few degrees from vertical to add structural stability.
	natural=ridge	Absolute r. r..	A ridgeline can have its elevation specified on the way if it is constant along its length or on the nodes if it varies, similar to how the tagging for cliffs works. Also, the perpendicular rate of elevation falloff can be measured and specified in the same way it can be for a peak. If this ridge profile is constant along the length of the ridge the derivative values can be put on the way, or individual measurements can be made at some or all of the nodes along the ridgeline and the values recorded there instead.
	waterway=river waterway=stream etc.	Absolute Relative r. r..	Rivers, streams, and other waterways are effectively the exact opposite of a ridgeline feature. They have some channel profile analogous to the first and second derivatives along a ridgeline, but additionally rivers often also have a riverbank associated with them as well. Having the riverbank mapped as well as the centerline allows for a lot of elevation information to be derived. First, the width of the area specified by the riverbank sets the channel width to carve into the surrounding terrain (for narrow or very regular waterways like canals this can also be tagged as a width=* on the centerline way). Second, the position of the centerline way can be used to indicate the path of the deepest channel in the river, allowing the interpolation algorithm to model asymmetric river channel profiles. Lastly the riverbank acts as a sort of pseudo contour line in the elevation dataset. The elevation of the two points on opposite sides of the river is almost exactly level (only varying a tiny amount due to currents in the water) and along the actual course of the river the riverbank will gradually move down in elevation with larger elevation drops for things like dams or waterfalls.
	natural=water landuse=reservoir natural=coastline etc.	Absolute Relative	The shores of lakes or coastlines and islands act identically to contour lines for most purposes. Like with rivers there may be some very small elevation deviation over long distances due to currents and tides, etc, but for the most part the shorelines should exactly follow the contour lines through that point.