GPS data uploaded to the OpenStreetMap servers is a popular example of what is called Volunteered Geographic Information (VGI). The data has been (and is still) collected by the project contributors primarily to support mapping. As the inclusion of roads and paths in the map is a major goal of the project, the collected GPS data often follows such man made structures. It has already been shown that a set of GPS tracks following the same way can even be used to derive the centrelines of the respective ways (cf. e.g. [1], [2], [3], [4]).
Current feature extraction approaches focus on the horizontal coordinates contained within the GPS tracks. The reasons for that are that the horizontal information is sufficient for many purposes, GPS elevation measurement is less precise than horizontal measurements, and (particularly in the context of VGI) the elevation information is not always provided in GPS data collected by low-cost GPS receivers. However, there are scenarios such as route planning for bicycles, electric cars and wheelchairs where the vertical component of ways is very important. As we are currently working on route planning for people with limited mobility in the CAP4ACCESS project, this is a relevant topic for our group. Moreover, we want to continue some of our previous research in the area of 3D routing (cf. Schilling et al. 2008).
We therefore want to test whether the elevation information contained in the GPS tracks collected by the OpenStreetMap contributors can serve as a low-cost approach for deriving the incline of roads and paths. For this purpose, we have extracted GPS points from the regional extracts of the planet.gpx files (Many thanks to our student assistant Steffen John!).
A first analysis showed that in the Heidelberg region there are about 1,000 GPS tracks (using the 2013 planet.gpx dump). About 90% of the tracks in Baden-Württemberg (compared to e.g. only ~65% in Bremen) have elevation information. There are ~1,000,000 individual GPS points in Heidelberg. The bounding box that was applied has a size of ~200km². This means that on average there is one point per 200m² which equates to one point per 15m*15m (assuming the points would be evenly distributed). However, as can be seen in the visualisation, in practice the point density in the regions of our interest (i.e. in the proximity of at least some of the roads and paths) is much higher with the drawback of an otherwise low coverage.
The visualisation of the point cloud has been prepared using WebGL and the JavaScript library three.js – proceeding some of our earlier WebGL mapping efforts, e.g.: traffic flow visualisation for London, Twitter Point Clouds, webgl.uni-hd.de. As the performance depends on your machine and the speed of your internet connection, we have prepared different versions, including different numbers of points.
~100k points
~350k points
~1M points
(There may be some issues when using Firefox and Internet Explorer – we recommend Google Chrome for viewing)
