Full Terms & Conditions of access and use can be found athttp://www.tandfonline.com/action/journalInformation?journalCode=tcag20

Download by: [University of Nebraska, Lincoln] Date: 14 June 2016, At: 01:25

Cartography and Geographic Information Science

ISSN: 1523-0406 (Print) 1545-0465 (Online) Journal homepage: http://www.tandfonline.com/loi/tcag20

Deriving incline values for street networks fromvoluntarily collected GPS traces

Steffen John, Stefan Hahmann, Adam Rousell, Marc-O. Löwner & AlexanderZipf

To cite this article: Steffen John, Stefan Hahmann, Adam Rousell, Marc-O. Löwner & AlexanderZipf (2016): Deriving incline values for street networks from voluntarily collected GPS traces,Cartography and Geographic Information Science

To link to this article: http://dx.doi.org/10.1080/15230406.2016.1190300

Published online: 08 Jun 2016.

Submit your article to this journal

Article views: 24

View related articles

View Crossmark data

Deriving incline values for street networks from voluntarily collected GPS tracesSteffen Johna,b, Stefan Hahmann a, Adam Rousella, Marc-O. Löwnerb,c and Alexander Zipfa

aGIScience Group, Institute of Geography, Heidelberg University, Germany; bInstitute of Geodesy and Geoinformation Science, TechnischeUniversität Berlin, Germany; cInstitute of Geodesy and Photogrammetry, Technische Universität Braunschweig, Germany

ABSTRACTWhen producing optimal routes through an environment, considering the incline of surfaces canbe of great benefit in a number of use cases. For instance, steep segments need to be avoided forenergy-efficient routes and for routes that are suitable for mobility-restricted people. Such inclineinformation may be derived from digital elevation models (DEMs). However, the correspondingdata capturing methods (e.g. airborne LiDAR, photogrammetry, and terrestrial surveying) areexpensive. Current low-cost and open-licensed DEM (e.g. Shuttle Radar Topography Mission[SRTM] and Advanced Spaceborne Thermal Emission and Reflection Radiometer [ASTER]) gener-ally do not have sufficient horizontal resolution or vertical accuracy, and lack a global coverage.Therefore, we have investigated an alternative low-cost approach which derives street inclinevalues from GPS traces that have been voluntarily collected by the OpenStreetMap contributors.Despite the poor absolute accuracy of this data, the relative accuracy of traces seems to besufficient enough to compute incline values with reasonable accuracy. A validation shows thatthe accuracy of incline values calculated from GPS traces slightly outperforms incline valuesderived from SRTM-1 DEM, though results depend on how many traces per street segment areused for computation.

ARTICLE HISTORYReceived 29 September2015Accepted 12 May 2016

KEYWORDSVolunteered GeographicInformation; GPS; incline;OpenStreetMap

Introduction

Common routing and navigation systems such asGoogle Maps1 or Here2 currently do not considerdata about elevation or incline when computing routes.Initially, these services were designed primarily for car-based navigation, where incline information in mostuse cases is not a major concern. However, there arealso many routing scenarios where incline is an impor-tant factor. For cyclists, pedestrians, and mobility-restricted people such as wheelchair users or peoplewith walking aids, the inclines encountered within aplanned route are of high relevance. For instance, themaximum incline a wheelchair user can climb is gen-erally between 3% and 8% for manual wheelchairs andup to 10% for electric ones (Menkens et al. 2011).Cyclists may either prefer mountainous routes fortraining or flat routes when commuting. Furthermore,energy-efficient routing benefits from incline informa-tion. Electric-powered vehicles such as electric cars orwheelchairs have an increased energy demand whengoing uphill and a limited battery capacity. This is aparticular problem as charging stations remain rare.Thus, routing services that use information about theincline of possible routes may be used to predict therequired energy demand more accurately and may even

compute the most efficient route in terms of powerconsumption (cf. Franke et al. 2012).

Elevation data may be used to derive incline valueswithin a road network (Schilling et al. 2009). However,the most common sources of elevation suffer from oneor more of the following problems: (1) they are tooexpensive due to the highly specialized and costly sen-sors involved in data acquisition (satellite missions suchas TanDEM-X, airborne LiDAR/photogrammetry, andterrestrial surveying), (2) they are not globally available(e.g. regional open governmental data sets), and (3) theydo not have sufficient horizontal resolution or verticalaccuracy (e.g. Shuttle Radar Topography Mission[SRTM] and Advanced Spaceborne Thermal Emissionand Reflection Radiometer [ASTER]).

Therefore, we investigated whether volunteered geo-graphic information (VGI) may serve as an additional,or even alternative, source of information for low-costapproaches to compute incline. Particularly we focusedon voluntarily collected GPS traces. Due to the rapiddevelopment of mobile devices with integrated GPSreceivers, such traces can easily be recorded on alarge scale. The derived incline information will bevalidated using a high-resolution LiDAR-based DEM,in order to test the feasibility of the approach.

CONTACT Stefan Hahmann hahmann@uni-heidelberg.de

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE, 2016http://dx.doi.org/10.1080/15230406.2016.1190300

© 2016 Cartography and Geographic Information Society

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

Furthermore, we compared the achieved results toincline values derived from SRTM-1, which currentlyis one of the best freely available global DEMs in termsof resolution and accuracy. This comparison will pro-vide some insight as to whether crowdsourced GPSdata collection already have the potential to substitutecostly sensors for the acquisition of inclineinformation.

This contribution is organized as follows. The fol-lowing section provides an overview and related work.The “Methodology” section describes the methodologyof deriving incline values from GPS traces while resultsare given and discussed in the “Results and discussion”section. The conclusion of this article can be found in“Conclusion” section.

Background and related work

The GPS

The availability of Global Navigation Satellite Systems(GNSS) to end users is a necessary precondition toallow crowdsourced collection of position data. Themost widely used GNSS is generally considered as theGPS, which is operated by the US Department ofDefense. In its beginning, the accuracy was degradedfor civilian use, known as Selective Availability (SA). Inthe year 2000, SA was switched off, which now enablessufficient accuracy for many standard applications inthe private sector, such as navigation and location-based services (Hofmann-Wellenhof, Lichtenegger,and Wasle 2008).

Current mobile devices that are equipped with low-cost GPS receivers have a horizontal accuracy of 5–10 m and a vertical accuracy of up to 25 m (Liu et al.2014). The relatively poor vertical accuracy is explainedby the constellation of satellites (cf. Langley 1999). Infact, this poor vertical accuracy limits the potential ofGPS measurements to derive elevation data. However,in the case of incline computation, this accuracy is notnecessarily a problem as long as the vertical error ofadjacent points is relatively stable. This is because asimilar vertical error would be present in neighboringpoints, and thus, there would not be a differentialinconsistency within the incline computation.

Volunteered Geographic Information (VGI)

The term “Volunteered Geographic Information” wasintroduced by Goodchild (2007). It describes a specialcase of user-generated content (UGC). The latter termemerged in the mid-1990s and describes content of anytype in the Internet which is produced by the user

(Bauer 2010) of respective web services. The phenom-enon of VGI has also been referred to as “crowdsourcinggeospatial information” by Heipke (2010) and Ramm,Topf, and Chilton (2011). Sui (2008) describes therecent development as the “wikification of GIS” andpoints out that the actors and methods for collectinggeographic information have changed. While previouslyonly experts like surveyors or cartographers acquiredand processed geodata, today there is a large group ofmostly untrained people who are also acquiring andprocessing this kind of data without any financial com-pensation. Budhathoki, Bruce, and Nedovic-Budic(2008) refer to this phenomenon of a melting borderbetween users and producers of geodata with the term“produser” of geodata. Due to its nature, VGI is typicallyheterogeneous in terms of accuracy and coverage (Sesteret al. 2014). Depending on the number and motivationof contributors, some regions may be covered with moredata and thus may be more complete than others.

Different forms of VGI acquisition can be differen-tiated. For instance, Sester et al. (2014) distinguishbetween participatory and opportunistic acquisition ofVGI. While the participatory acquisition happensintentionally and is dedicated to a certain purpose,opportunistic data collection is a process where a usermore or less unconsciously collects relevant data. Here,we present research on data of the latter category, sincethe analyzed GPS data has not been acquired for thespecific purpose under investigation, i.e. the computa-tion of road incline.

Figure 1 shows an example of the VGI data set thatwe use for our research. It can be seen that there is ahigher density of available information than is con-tained in the SRTM-1 DEM (horizontal resolution = 1″~ 30 m, indicated by the grid lines) in the same region.Particularly beneficial for our approach is that manyGPS track points are located along streets, which isexactly where the information for street incline com-putation is needed. However, it may also be seen thatthe density of measurements is not the same for allstreets and at times can be quite poor.

OpenStreetMap (OSM)

The OSM project was founded in 2004 and can be seenas the most-popular VGI project (Haklay and Weber2008). Three main methods of data acquisition may bedistinguished: (1) digitizing based on previouslyrecorded GPS traces, (2) digitizing based on satelliteor aerial imagery, and (3) data donations of companiesas well as open data provided by public agencies. It hasbeen shown that the quality and completeness is vary-ing for OSM data (e.g. Neis, Zielstra, and Zipf 2012).

2 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

Nevertheless, the OSM data set can be used for variousapplications – cf., e.g., Neis and Zielstra (2014b) andArsanjani et al. (2015) for an overview. The OSMdatabase stores both the map features and the user-generated GPS traces. These GPS traces are stored as acollection of files in the GPS Exchange format (GPX).

Currently, street incline values are assigned to therespective features using key-value pairs (tags) as isdone for any semantic information in the project.According to the project documentation, the key issupposed to be “incline” and the corresponding value isideally the actual incline value given in percent or degree.3

If a street geometry does not have a constant incline,the geometry should be split at the location of inclinechange.

Information regarding the incline of ways is scarcein the OSM data set and when it is present, it is inmany cases not very specific. Only 0.2% of the highwayfeatures in OSM have an “incline” tag, while the major-ity of these tags (~75%) only specify “up” or “down.”For the remaining 25%, which is only 0.05% of allhighway features, the incline is mainly given as a per-centage or degree. However, it has also been found thatnon-numeric incline values (such as “moderate” or“extremely steep”) have been found. This may be dueto several reasons. On the one hand, the contributorsare often not too concerned with tags which will not bedisplayed on the map. On the other hand, inclinevalues cannot simply be digitized from GPS traces oraerial imagery like other features. They need to beestimated on-site with the help of tools such as inclin-ometers or gyroscopes, which can now be found builtinto common smartphone models.

3D routing

One particular use case that would benefit from theavailability of incline information for the complete streetnetwork is that of 3D route computation. As a 3D rout-ing scenario, Müller et al. (2010), Neis and Zielstra(2014a), and Weyrer, Hochmair, and Paulus (2014)investigated routing algorithms that meet the require-ments of mobility-restricted people. Beside this use case,incline is also relevant for route computation of electric-powered vehicles. One of the reasons why people are stillskeptical about such vehicles is the poor prediction ofdistance range before a charge of the power source isrequired (Bachofer 2011). In order to improve this pre-diction, it is important to generate an accurate estimationof the energy consumption. In that calculation, incline isan important factor. Franke et al. (2012) introduced arouting algorithm that computes the most energy-effi-cient route and also provided the total energy consump-tion. To calculate the incline information, a high-resolution DEM acquired from LiDAR measurementswas used. However, many other approaches in 3D rout-ing (cf., e.g., Kono et al. 2008; Sachenbacher et al. 2011;Schilling et al. 2009) make use of different DEMs with ahorizontal resolution of 90 m (i.e. SRTM, ASTER).

Extraction of street attributes from user-generatedmovement trajectories

Extracting street information out of user-generatedGPS traces, as we do in this article, has already beeninvestigated by several researchers. However, the focusof these studies was mainly on deriving semantic

Figure 1. Depending on the street, 0 to many GPS track points fall into one square of 1″ × 1″ equivalent to horizontal resolution ofSRTM-1. Due to the projection, the grid is rectangular, not square (Basemap: OSM).

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 3

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

information, and at the time of writing, no literaturewas found that made use of user-generated GPS tracesfor generating incline values. van Winden (2014) pro-posed several algorithms to automatically derive differ-ent road attributes from GPS traces, such as thedirection of the road (one or two way), speed limit,or number of lanes. He used GPS trajectories acquiredfrom 800 people within a certain time span.Furthermore, Zhang, Thiemann, and Sester (2010)used GPS traces from OSM to derive street attributessuch as the number of lanes as well as turning restric-tion and tried to automatically correct the street’s cen-terline. They discovered that motorways are covered by30–80 corresponding traces, whereas streets withincities in average have less than 20 corresponding traces.Minor streets especially in residential areas often onlyhave only a few or no corresponding traces.

Common elevation data sources

Digital elevation models (DEMs) are a common sourceof elevation data. DEMs may be distinguished intodigital surface models (DSMs) and digital terrain mod-els (DTMs), depending on if they are representing theEarth’s surface including objects on it (e.g. buildingand trees = DSM) or not (=DTM). A very high accu-racy and resolution can be achieved using airbornetechniques, such as laser detection and ranging(LiDAR) or photogrammetry. However, these methodsare expensive and thus not globally applicable.

Spaceborne satellite missions may gather elevationinformation at global scale. Examples are the “ShuttleRadar Topography Mission” (SRTM, Farr et al. 2007),the “Advanced Spaceborne Thermal Emission andReflection Radiometer” (ASTER, Abrams et al. 2010),and “TerraSAR-X add-on for Digital ElevationMeasurement” (TanDEM-X). The data of the latterone has been used to derive a global DTM with 4 mvertical accuracy and 12 m horizontal resolution. It isglobally available but comes with license costs and isthus not feasible for low-cost use cases.4 The SRTMDSM and ASTER DSM are open-licensed; however,their horizontal resolution is only 30 m and theirvertical accuracy only 6.2 m (SRTM, cf. Farr et al.2007), 4.0 m (SRTM, Gesch et al. 2012), and 9 m(ASTER, Meyer 2011; Gesch et al. 2012), respectively.Whereas in flat areas, these inaccuracies may level out,for areas that include relatively quick elevation changessuch as hilly and mountainous regions, this data mightnot be sufficient to derive the incline of streets with anacceptable accuracy. Also, in forested and residentialareas, these data sets might not be sufficient, since by

their nature as DSMs, they represent the elevation,including buildings, trees, and other objects.

Alternatively to DEMs, the incline may also bederived using terrestrial measurement methods, suchas differential GPS or satellite-based augmentation sys-tems (Han and Rizos 1999; Boucher 2013). However,those methods are very costly and therefore not applic-able to larger areas or for low-cost use cases.

Map matching

A necessary precondition to attach information derivedfrom GPS traces to corresponding street segments is theprocess of linking the traces to the street segments. Thisprocess is generally known as mapmatching (e.g. Marchal,Hackney, and Axhausen 2005; Quddus, Ochieng, andNoland 2007). In navigation applications, these algorithmsare used to predict the user’s location within a street net-work. An example of a GPS traces and correspondingmatched street segments is shown in Figure 2.Mapmatch-ing is a challenging task if GPS data has insufficient accu-racy. In these cases, several street segments are eligible asbeing the one that is being traveled.

Map matching algorithms can be categorized intodifferent groups: geometric, topological, probabilistic,and other advanced algorithms (Quddus, Ochieng, andNoland 2007). For all approaches, it is assumed that thecarrier of the GPS device is traveling on a street that iscontained in the street network. Geometric approachesare generally faster in processing and easier to imple-ment, since they simply compare the distances betweentwo points, two curves, or a point and curve (e.g.White, Bernstein, and Kornhauser 2000). In additionto the distance between a GPS trace and street segment,

Figure 2. Map matching. The GPS trace (blue) is snapped tothe street network (red) (Map: OSM).

4 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

topological algorithms further consider the topologicalrelationship (e.g. touching and disjoint) between thesegments of a street network (e.g. Quddus et al. 2003).In probabilistic approaches (e.g. Ochieng, Noland, andQuddus 2003), the error ellipse of GPS track point isused to find intersecting street segments, which serveas matching candidates. Advanced algorithms use addi-tional techniques such as Kalman filtering or othermathematical models (e.g. Krakiwsky, Harris, andWong 1988).

Methodology

Pilot region

The pilot region of our study is an area aroundHeidelberg in the southwest of Germany. Figure 3shows the extent of the region, which is 497 km2 insize. It is characterized by mountainous and forestedareas in the east as well as flat urban areas and farm-land in the west. This mixture makes the area particu-larly suited for this research, since it allowsdifferentiating the results between different land-useclasses and terrain characteristics.

Input data

Crowdsourced GPS tracesThere are several platforms and applications that enableusers to collect GPS traces for different purposes. In OSM,GPS traces are collected to support mapping. Besides that,there are sport tracking apps for smartphones (e.g. Strava5

and Runkeeper6) which track routes to provide statisticsabout the user’s training (average speed and elevationprofile). On platforms such as komoot7 or Gpsies,8 GPStraces can be recorded or uploaded to share and recom-mend routes with other users.

Mobile devices often have integrated low-cost GPSreceivers (Heipke 2010). Usually, the elevation mea-surement is derived directly from the GPS signal orfrom an additionally built-in barometer. Some applica-tions also derive elevation information from DEMs, e.g.Runkeeper and Strava, while sometimes the exactsource of the information remains unclear. Moreover,the devices deal differently with the vertical datum.While some devices record the ellipsoidal height (alsodue to misconfiguration) above the reference ellipsoiddefined by the World Geodetic System 84 (WGS 84),others internally transform the measured ellipsoidal

Figure 3. Pilot region Heidelberg/Germany (Map: OSM).

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 5

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

height from WGS 84 datum to mean sea level (MSL)using a geoid model. The GPS traces that we use forour study were taken from the OSM project. In general,these GPX files neither contain information about theelevation datum nor about the sensor. Thus, elevationdata acquisition remains largely a black box. However,for this study, we assume an internal transformation toMSL for the majority of tracks.

The OSM GPS data contains more than 2.5 billiontrack points all over the world, collected by thou-sands of users. However, the majority can be foundin Europe (cf. Figure 4)9. A dump of all GPX files isavailable for download10 with the latest version ofthis file dating from April 2013. Within our pilotregion, 4194 GPS traces have been identified. About86% (3606) of them also contain elevation informa-tion. Given the density of the GPS track pointswithin the pilot region (over 2 million), and theregion’s size of 497 km2, this would theoreticallyresult in a resolution of 1 point every 15 × 15 mgrid square, assuming an even distribution of theGPS measurements.

Street networkThe main purpose of computing the incline in this studyis to allow the enrichment of a street network with thederived data. For simplicity, we chose to use the OSMstreet network as test data set. We have extracted all

features of the OSM data set which are tagged as “high-way,” leading to a total of over 57,000 features with alength of 5336 km. Table 1 shows the classification of thestreet segments and their share within the pilot region.

Additional input dataIn order to analyze dependencies of our results todifferent land use classes, we extract this informationfrom the OSM data set using the corresponding tags.11

In our study area, the mapping of land use within OSMis relatively complete. Where small gaps occur in the

Figure 4. Screenshot of a grid map, showing the number of GPS points per grid cell.

Table 1. Values of highway tag and their share of length inpercent.

Value Verbal descriptionaShare in

%

Track Agricultural, forestry streets 44Residential Streets within residential areas 18Path Mainly hiking trails and small paths 9Footway For pedestrians only 7Secondary Country road of second priority 4Tertiary Country road of third priority 3Cycleway For cyclists only 3living_street Streets, where pedestrians have priority over

cars2

Motorway Equivalent to autobahn 3Unclassified Roads with minor priority than tertiary 3Primary Country road with highest priority 1Othersb 3

ahttp://wiki.openstreetmap.org/wiki/Map_Features#Highway, checked on27 May 2015.

btrunk, motorway_link, pedestrian, trunk_link, secondary_link, primary_-link, road, tertiary_link.

6 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

data set, we have buffered the existing land-use poly-gons to complete the coverage. Whereas rural areassuch as farmlands and allotments are characterized byfields and mainly low buildings, residential or commer-cial areas often have taller buildings and urban canyons(Langley 1999) where multipath and shadowing effectsare more likely to occur. This may affect the GPSaccuracy and consequently the accuracy of derivedincline information.

As a reference data set for validating a high-resolu-tion DTM is used, the DTM was derived from officialairborne LiDAR measurements and represents the ter-rain, excluding buildings and vegetation. The DTMcovers the entire pilot region with a horizontal resolu-tion of 1 m and a vertical accuracy of 0.5 m. In addition,the SRTM-1 DEM12 has been used to calculate inclinevalues and to compare them to the results derived fromthe GPS measurements. This will indicate whether ourapproach can generate more accurate results than thosecontained in current openly available data sets.

Workflow and implementation

OverviewThe process of deriving incline values consists of multi-ple steps (cf. Figure 5). First of all, the GPS data and thestreet network are imported into a database. This stephas the option to filter GPS data contained within aspecific bounding box and to skip data which does notcontain elevation information. After this preprocessingstep, both input data sets are linked to each other viamap matching techniques. This is a necessary precon-dition to performing the sequential calculation of anincline value for each segment within the street net-work. Finally, we validate our results. In the followingsections, we describe each of these steps.13

Import and preprocessingWe imported both street network and GPS traces into acommon database as this simplifies all followingremaining steps. Prior to writing the GPS traces tothe database, we check if two conditions are met: (1)

an individual trace needs to contain elevation informa-tion and (2) the trace needs to intersect the specifiedbounding box.14 All GPS traces are stored as 3D line-strings in the database.

Once imported, some preprocessing steps are per-formed on the data.15 A trace may be interrupted dueto the loss of the GPS signal (e.g. when passing atunnel) which causes missing points within a track.Consequently, we do not have any elevation informa-tion along these sections. Therefore, we do not includethem in the incline computation. The respective inter-ruptions can often be identified through a long dis-tance between two consecutive track points. The tracesare split if the distance between two adjacent points ina trace is exceeding a certain threshold. This is aniterative process and an individual trace may be splitin multiple parts. The threshold values are chosen to be300 m for the maximum distance between consecutivepoints as proposed by Zhang, Thiemann, and Sester(2010).

After splitting, the elevation data within each tracesegment is smoothed to reduce the high-frequencynoise. For this step, a weighted moving average filterhas been applied. The following set of weights W hasbeen used for the window:

W ¼ 0:1; 0:125; 0:15; 0:25; 0:15; 0:125; 0:1f gThe smoothed elevation value of a point is calculated asfollows:

e�n ¼X7m¼1

enþ m�4ð Þ � wm� �

wheree� = smoothed elevation,e = original elevation of data points,w = weights, andn = number of track point.For the first and last three values of each trace, we

only use the available adjacent values for the calcula-tion of the weighted average. Figure 6 shows an eleva-tion profile of a GPS trace and its smoothedrepresentation. For comparison, the elevation profile

Figure 5. Process of deriving incline information out of user-contributed GPS traces.

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 7

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

of the corresponding path derived from the referenceDTM is also depicted. It may be seen that the GPSmeasurements show a rather constant offset.

The segmentation of streets within data sets isusually defined by semantics (e.g. street name) andnot according to the characteristics of the terrain.Therefore, a street segment may span several valleysand peaks, which leads to wrong incline estimation dueto a single incline being assigned to the segment as awhole. To reduce this effect, streets within our data setare split into segments at the intersection points withother streets. We do not further split the street seg-ments into smaller pieces as this would lead to only afew corresponding GPS points for each segment andwould consequently lower the accuracy of incline esti-mation. Instead, an average incline for each segmentbetween street intersections is stored.

Map matchingIn order to link GPS traces with corresponding streetsegments, we apply a simplified version of the mapmatching approach described by Zhang, Thiemann,

and Sester (2010).16 The algorithm consists of threesteps (cf. Figure 7).

(1) The street segment is buffered and all traces areselected as matching candidates which intersectthis buffer (Figure 7(a)). We used a buffer size of50 m.

(2) Profile lines for each node of the street segmentare computed which are perpendicular to thesegment and centered at the node (Figure 8(b)). We choose the length of these lines to be30 m, considering the horizontal accuracy of theGPS measurement and the width of typicalstreets. If a GPS trace intersects most of theprofile lines, it is considered to be a matchingtrace.

(3) Profile lines that are (not) intersected by a can-didate trace are counted. All candidate tracesthat intersect at least 70% of the perpendicularlines are considered as matched traces(Figure 7c). A lower threshold would result ina higher matching rate at the cost of more falsepositives, particularly for streets that only havetwo nodes. A higher threshold would be toorestrictive, considering the inaccuracies of GPSand the remaining positional errors of the streetsegments.

We skip the detection of lanes and directions of streetsthat is also described by Zhang, Thiemann, and Sester(2010), since this is not relevant for our use case.

Calculation of inclineThe incline values are calculated for each street seg-ment individually. The entire process is shown inFigure 8 and will be explained in the followingsection.17

Figure 6. Elevation profile of GPS raw data, smoothed andcompared with LiDAR DTM.

Figure 7. The map matching process: (a) Select candidate traces using a buffer (light green) around the street (dark green); (b)create profile lines (blue) perpendicular to the street; (c) select traces (red) that intersect with at least 70% of the profile lines.

8 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

For each street segment, the matched preprocessedGPS traces are selected. Since a trace usually spansmultiple street segments, the traces need to be clippedin order to only use relevant elevation information forthe segment in question. To clip the GPS traces, we usea buffer around the street with a size of 30 m (cf.Figure 9).

For each of the clipped traces, the incline (it) iscalculated by averaging the incline values (ip) of con-secutive GPS track segments. Since the distancebetween the track points is not equal, ip is weightedaccording to the distance and normalized with the fulllength of the trace. The calculation may be expressedusing following formula:

it ¼Xn�1

m¼1

ipdm;mþ1

l

� �¼Xn�1

m¼1

emþ1 � emdm;mþ1

� �dm;mþ1

l

� �;

whereit = incline of GPS trace segment in percent,ip = incline of two consecutive GPS track points in

percent,

Figure 8. Workflow for calculating incline values for a street network.

Figure 9. Clipping of corresponding GPS traces using the bufferof the street segment.

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 9

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

n = number of track points,e = elevation of track point,d = horizontal distance between two track

points, andl = horizontal length of GPS trace segment.In OSM, the street segments are directed from the

first node of the segment to the last node.Consequently, it has to be checked whether the GPStrace was recorded in the same or the opposite direc-tion of the street. This is done by a comparison of theaverage bearing of the street segment and the GPStrace. If the difference in bearing (α) is greater than acertain threshold, it is assumed that the GPS tracefollows the opposite direction and the calculatedincline value is inverted. Based on tests with individualsamples, we have chosen a threshold of 40°.

The next step is to average all incline values com-puted from the individual traces (it) to get a value thatrepresents the incline of the street segment (is). Sincethe length of the trace may vary, the average isweighted based on the length of each trace. The follow-ing formula has been used for averaging the inclinevalues of the individual traces:

is ¼Xka¼1

ita� � laPk

a¼1 la

!;

whereis = incline of street segment in percent,it = incline of GPS trace in percent,k = number of corresponding traces, andl = horizontal length of trace.In order to evaluate the results, we also compute the

incline for each street segment using the given DTMs.For this purpose, the elevation values within the DTMsalong the street segments are determined with a

sampling distance of 3 m. These values are used tocompute elevation differences, which subsequentlyallow computing an average incline for each streetsegment.

Results and discussion

Analysis of elevation data of crowdsourced GPStraces

We use a total of 3606 GPS traces comprising of overtwo million track points within our pilot region ofHeidelberg (cf. Figure 10)18. We evaluate the accuracyof this input data using a high-resolution DTM. Thereare two aspects relating to the accuracy of the data: (1)the absolute error of the elevation measurements com-pared to this DTM and (2) the relative accuracy. Thelatter refers to the error of the differences of elevationbetween two adjacent points. It has to be noted that thehorizontal inaccuracies of the GPS points influence thisevaluation, since especially in mountainous areas anerror in horizontal positioning also leads to an erro-neous elevation value picked from the reference dataset. Furthermore, the high-resolution DTM used forevaluation suffers from some inaccuracies as it reflectsthe actual terrain of the earth and consequently doesnot contain all structures on the earth’s surface, such asbuildings, trees, or bridges. This leads to errors, parti-cularly in the case of bridges, where ground elevation isinterpolated. Besides elevation accuracy, we also evalu-ate the GPS traces in terms of coverage and density.

Absolute elevation accuracyFor the assessment of the absolute elevation accuracyof the GPS measurements, we compute the root-mean-square-error (RMSE) on the data set as a whole and

Figure 10. Visualization of GPS track points, color coded according to elevation (green = low, red = high).

10 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

then the errors on the GPS measurements classified bythe land-cover area that they fall into (cf. Table 2):

RMSE ¼ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiPn

i¼1 eiGPS � eiDTMð Þ2n

s;

whereeGPS = GPS elevation measurement of the GPS point,eDTM = elevation value derived from the DTM at the

location of the GPS point, andn = total number of GPS points.The RMSE, i.e. the square root of the mean of the

squared residuals, is a common measure of differencein spatial analyses. In our case, it provides a measure ofthe differences between GPS and DTM elevationvalues. For the calculation of the RMSE, only 90% ofthe residuals have been used whereas 10% have beenexcluded as severe outliers. Possible reasons for theseoutliers may be wrongly calibrated (in the case ofbarometric measurements) or misconfigured devices,or values that may not have been recorded on theEarth’s surface (e.g. in an airplane).

With 27 m, the overall RMSE is slightly worse than15–20 m as found out in previous studies (Liu et al.

2014; Zhang, Thiemann, and Sester 2010). A possiblereason may be that crowdsourced traces are prone tobe recorded under heterogeneous conditions.Furthermore, the diversity of devices and the unknowngeodetic datum degrade the accuracy.

We observe that track points in forests seem to bemore accurate than track points in the land-use classes“grass” and “allotments.” This contradicts our expecta-tions (due to a more visible sky generally leading tobetter GPS signals) and may be explained with thesample sizes of GPS track points. “Forest” is one ofthe land-use classes with the most GPS track points,whereas “allotments” and “grass” have only a few andthus might be more influenced by outliers.

Figure 11 depicts a histogram of the differences inelevation between the GPS and DTM data sets. It canbe seen that there is a peak and a normal distributionaround 0 m. In addition to that, however, there is also asecond peak and a second normal distribution around48 m. This may be explained by devices that haverecorded ellipsoidal elevation values according to theWGS 84 ellipsoid. The geoid undulation in region ofHeidelberg is equivalent to this offset of 48 m.19 Ingeneral, we can assume that the majority of the GPSelevation measurements have been recorded accordingto the geoid.

Relative elevation accuracyThe obtained absolute accuracy of 27 m within the GPSdata set appears to be very large, especially when com-pared to the vertical accuracy of the SRTM-1 DSM(6.2 m) which could also be used for low-costapproaches. However, since for the calculation ofincline only the difference in elevation of two adjacenttrack points is used, only the relative elevation accuracy

Table 2. Absolute elevation accuracy of crowd-sourced GPS track points, differentiated byland use class.Land-use class RMSE (m)

Allotments 35Commercial 34Grass 30Overall 27Residential 25Forest 22Industrial 22Farmland 21

Figure 11. Histogram with the differences of GPS and DTM elevation.

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 11

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

is of major concern. We evaluate this relative accuracyas follows: for each GPS track point, the difference ofelevation ΔhGPS to the next track point of the trace hasbeen calculated. This value, with regard to the distancebetween the points, reflects the actual incline of theterrain including the remaining noise of the GPS mea-surements after filtering. The difference of elevationΔhDTM was derived from the reference data (i.e. high-resolution DTM) and is the difference of elevationderived from the GPS measurements ΔhGPS. Thisresults in the GPS error eΔh:

eΔh ¼ ΔhGPS � ΔhDTM

We have computed eΔh for all track points. Toreduce the effect of severe outliers, we only use 90%of the values to compute the RMSE (as mentionedearlier). The results can be seen in Table 3 togetherwith the analysis of the impact of the relative elevationaccuracy on the incline error.

Coverage and densityIn order to get an idea of how many streets are coveredwith how many traces and how dense the GPS trackpoints are, we investigated coverage and density. Thecoverage is analyzed using the results of the mapmatching. It has to be noted that due to the n to mrelationship, GPS traces may be matched to more thanone street.

A large share of streets does not have any corre-sponding trace although many streets are covered withat least one trace in the pilot region. Streets with higherpriorities generally have more corresponding traces(e.g. motorway), whereas residential streets only havea few or even none (cf. Figure 12). Particularly, motor-ways are completely covered by at least 25 traces. Also,primary streets have 100% coverage with at least 5traces. Approximately 95% of the street types “second-ary,” “tertiary,” and “cycleways” are covered with atleast 1 trace and 80% with at least 5 traces. The lowestcoverage (40–60% with at least 1 trace) is observed forthe feature types “residential,” “footpath,” and “path.”In general, it can be said that streets of higher priority

have more matching GPS traces. Residential streets thatcan be used by bicycles perform as well as secondaryand tertiary streets. Paths that are dedicated to pedes-trians only are comparable to residential streets interms of trace coverage. However, this may even be aside effect of the matching algorithm, which assignstraces to both the residential street and the parallelfootpath due to their close proximity.

With regard to point density, we have analyzed theaverage distance between adjacent GPS track points forthe street type. While there is an average distance of14 m in the whole data set, we find that this distance ismuch higher for motorways (36 m) than for instancefor paths (8 m) and residential streets (10 m). Thus, itcan be concluded that the point density depends on theaverage speed of vehicles on the corresponding streettypes.

Analysis of incline values derived from GPS traces

We have computed incline values for the street net-work using the GPS traces and the method described insection “Calculation of incline”. If we consider all streetsegments that are covered by at least one trace, we cancompute incline values for a total length of 3064 km,which is equivalent to 57% of the complete street net-work of 5338 km in the pilot region.

Pre-evaluation processingA high-resolution DTM derived from airborne LiDARmeasurements has been used for evaluation. Thoughgenerally highly accurate, the use of this LiDAR dataset for the evaluation of our results is not without

Table 3. The relative elevation accuracy of crowdsourced GPStrack points and their impact on the calculation of incline.Land use RMSE eΔh (m) Average distance (m) ≙ incline error (%)

Overall 0.3 14 2.4Allotments 0.2 11 2.2Commercial 0.2 10 2.4Farmland 0.2 17 1.0Forest 0.5 11 4.3Grass 0.2 29 0.8Industrial 0.2 10 2.4Residential 0.3 10 2.7

Figure 12. The coverage with GPS traces for different streettypes.

12 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

issues. Figure 13 shows an example of a motorwayjunction with the underlying DTM. Here, the inclinederived from the DTM is calculated erroneously with avalue of 30%. Due to the characteristics of the pilotregion, streets with an incline of more than 20% arelikely to exist only rarely. However, for about 0.4% ofthe street segments, the DTM-derived incline valueshave been estimated as being above 20% and in somecases even above 100%. As these errors would influencethe results of the validation, we exclude street segmentsthat have an incline derived from the DTM ofabove 20%.

Likewise, we assume that street segments with anincline steeper than 35% do not exist in the pilotregion. Therefore, street segments with GPS-derivedincline values or SRTM-derived incline values ofabove 35% are also excluded from the evaluation.

Impact of relative elevation accuracy on incline errorIn section “Relative elevation accuracy”, we have alreadyintroduced how we analyze the relative elevation accu-racy of consecutive GPS measurements. In order toestimate the impact of the error eΔh on the actual inclinevalues, we have also calculated the average distancebetween two adjacent points (cf. Table 3). We dividethe error eΔh by this average distance to estimate theincline error that is caused by the relative elevationinaccuracy of adjacent GPS measurements. Overall, weestimate that the impact of the relative accuracy of theGPS elevation measurements on the computed inclinevalues results in an error of 2.4% incline. The smallestimpact is in areas of the land-use classes “grass” and“forest” with an error of equal or less than 1% incline. Inforested areas, an error of over 4% incline is estimatedbased on the relative accuracy assessment. All values

within the other areas are in a range between 2.2% and2.7% incline. Thus, we can conclude that the relativeaccuracy of GPS elevation measurements depends onthe surrounding land-use class. Land-use classes char-acterized by less obstructing structures (e.g. buildingsand trees) perform better.

Comparison of GPS incline and high-resolution DTMinclineThe comparison of the inclines derived from GPStraces and the high-resolution DTM is realized by thecalculation of the incline differences. The result isexpressed as an incline error ei (unit = %). The follow-ing formula is used:

ei ¼ iGPS � iDTM ,

whereei = incline error in %,iGPS = incline, derived from GPS traces, andiDTM = incline, derived from DTM.Figure 14 shows the street network color coded by

the GPS incline error. Due to the incomplete coverageof GPS traces, the incline could not be calculated for allstreets within the network. It may be observed thatstreet segments having a medium or large error arenot equally distributed in this area. In the westernpart (flat terrain and mainly farmland) only a few andshort street segments with a high error have beenfound. However, more streets with a larger errorvalue have been detected in the eastern part, i.e. moun-tainous terrain and forest. This may be explained bythe decreased relative vertical accuracy of GPS trackpoints in forested areas (cf. Table 3).

A histogram with the distribution of the GPS inclineerrors, which is normally distributed around the mean

Figure 13. Erroneously calculated DTM incline due to irregularities of the LiDAR DTM.

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 13

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

of 0 m, is depicted in Figure 15. The distribution has astandard deviation of σ = 4.0. When recalculating thestandard deviation with only 95% of the data, it resultsin σ95% = 2.3% incline.

Table 4 shows the absolute length in kilometers ofthe street segments for which the incline was calculatedbelow the error, given in the first column. The thirdcolumn represents the resulting share of street seg-ments for which it was possible to derive the respectiveincline information in reference to the total length of3064 km where at least one trace was available.

There is a dependency between the number of GPStraces used for the calculation of the incline values andthe share of street segments for which the incline can

be derived with certain accuracy. Figure 16 shows thisdependency with the example of the share of streetsegments with an incline error of less than 2% incline.An increase of the threshold of the number of GPStraces used for the computation of the incline valuesresults in a higher share of correctly estimated inclinevalues. However, at the same time, the share of streetsegments that would be covered by this amount of GPStraces is decreasing. Thus, the incline computationusing voluntarily collected GPS traces is a trade-offbetween accuracy and coverage.

Comparison of GPS incline and SRTM inclineIn this section, we compare the incline derived from theGPS traces to the results derived from SRTM-1 DSM. Forthis purpose, we compute the errors of the SRTM incline

Figure 14. Visualization of the error of GPS incline (≥1 trace) in the pilot region. Street segments with no incline are shown in gray.(Basemap: OSM).

Figure 15. Histogram of the incline error in percent.

Table 4. The length of street segments for different inclineerror classes (>1 trace).Inclineerror em(%)

Absolute length of streetsegments (km)

Share of length of streetnetwork with GPS incline (%)

<1 1872 61<2 2370 77<3 2607 85<4 2731 89<5 2817 92

14 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

values analogously to the errors of the GPS incline values(cf. section “Comparison of GPS incline and high-resolu-tion DTM incline”). Table 5 shows that the GPS inclineperforms slightly better than the SRTM incline; however,the coverage is more complete with SRTM.

Table 6 shows the comparison of the standard devia-tions for both input data sources distinguished by land-use classes. They have been calculated using 95% of thedata to reduce the effect of outliers. The three columnscontain the standard deviation of the SRTM inclinecomputation σSRTM, the standard deviation of theGPS incline σGPS computation using street segmentscovered by at least one trace, and the standard devia-tion of GPS incline computation using street segments

with at least 5 GPS traces (σGPS 5T). The overall results(σSRTM = 3.1%, σGPS = 2.3%, and σGPS 5T = 1.6%) showthat from the GPS data, the incline values can becomputed with higher accuracy than using SRTM.This holds true for all land-use classes.

A possible reason for this result is that the SRTM-1DEM is a DSM, which means that all structures on theearth surface are represented in the data set. Due to thelow horizontal resolution of 30 m of SRTM, this DEMcontains many mixed pixels that do not only coverstreet segments, but also buildings and trees that arenext to these street segments. In contrast to this, theGPS track points are recorded on the earth surface, ormore precisely on a constant height above the ground(e.g. in a car or back pack). Moreover, the SRTM datain general suffers from a vertical accuracy of 6.2 m,which is a relatively large error in comparison to therelative accuracy of the GPS measurements with 0.6 mwithin the same distance of 30 m (0.3 m within 14 mdistance, cf. Table 3).

A final analysis was performed to evaluate the influ-ence of the type of terrain on the results. For this pur-pose, standard deviations achieved in flat areas (DTMincline <2%) and mountainous areas (DTM incline>5%) have been compared. As shown in Table 7, bothinput data sources perform better in flat areas. However,in mountainous regions, the GPS incline computationdoes not outperform the SRTM incline computationand, in fact, performs slightly worse.

Limitations of approachThere are some limitations to our approach that areinherent in our methodology. In the OpenStreetMap-Wiki,20 a convention regarding the incline of streets isgiven. When adding incline information to OSM-Ways, the street segment is supposed to be split atthe beginning and at the end of the inclined part andthe maximum incline shall be assigned as an attribute.However, in our approach, we only compute the aver-age incline per street segment. This results in erroneousincline estimations if a street segment spans parts withdifferent incline values. However, a modification of ourapproach to compute the maximum incline value ofstreet segment would be possible. Nevertheless, suchmodification would trigger the need for another eva-luation of the results.

Figure 16. The percentage of streets with an incline errorsmaller than 2% and their share with respect to the entirestreet network. Hundred percent is equivalent to the sum ofthe lengths of all street segments having at least the numberof matched GPS traces.

Table 5. Comparison of SRTM and GPS incline (with at leastone trace/five traces) in terms of amount of street network withan incline error smaller than 2%.

Data sourcePercentage of street network with incline

error smaller <2%Coverage

(%)

SRTM 73 100GPS, ≥1 trace 77 44GPS, ≥5 traces 86 18

Table 6. Comparison of the standard deviations of the inclineerror, overall, and differentiated by land-use classes.Land-use class σSRTM (%) σGPS (%) σGPS 5T (%)

Overall 3.1 2.3 1.6Forest 4.2 3.6 3.1Farmland 2.0 1.1 0.9Residential 2.8 2.1 1.5Commercial 2.9 1.6 1.5Allotments 2.6 1.7 1.3Grass 3.3 2.0 1.5Industrial 2.6 1.7 1.0

Table 7. Comparison of the standard deviations of the incline,overall, and differentiated by terrain classes.Terrain σSRTM (%) σGPS (%) σGPS 5T (%)

Overall 3.1 2.3 1.6Flat 2.5 1.4 1.0Mountainous 5.1 5.7 5.4

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 15

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

Conclusion

Within our analysis of crowdsourced GPS traces, wehave discovered that the absolute accuracy of 27 m(RMSE) is worse than usual for low-cost GPS devices.This may be due to a mixture of (unknown) measure-ment methods (GPS measurement, barometric mea-surement, and elevation databases), misconfigured orwrongly calibrated devices, or due to a mixture of thevertical datum (WGS 84 ellipsoid, MSL). However,the relative accuracy, which is of importance forderiving incline values, has an RMSE value of 0.3 mwhich is sufficiently high. Hence, it is possible toderive incline values for street segments to a reason-able accuracy if the streets are covered with multipleGPS traces. In comparison to the SRTM-1 DSM, theGPS incline performs better in flat regions and equallyin mountainous region. However, the coverage is sig-nificantly lower since voluntarily collected GPS tracesare not available for a significant share of street seg-ments. This coverage may be increased if furthersources of user-generated GPS traces are taken intoaccount.

As a more general conclusion, we can say that theseresults show that today it is possible to achieve com-parable or even slightly better results for incline com-putation using recent VGI compared to data acquiredby a specialized research satellite 15 years ago (i.e. theSRTM satellite, 1999). Of course, also for VGI, weneed an operative satellite system, such as the GPSsatellites. However, this study underlines the potentialthat VGI can be used in cases that were not theprimary reason for the initial collection. In our case,this was the calculation of incline, but further usecases are easily imaginable, particularly consideringthe fact that the crowd of volunteers is continuing tocollect data.

We see a future research strand in the fusion ofopenly available DEMs, such as SRTM or open data,with the information of voluntarily collected GPS data.This could make use of the advantages of both dataacquisition approaches. Moreover, this could not onlyyield a more accurate and complete incline estimationfor street networks, but also create an improved globaland openly available DEM.

Notes

1. http://google.de/maps.2. http://here.com.3. http://wiki.openstreetmap.org/w/index.php?title=Key:

incline&oldid=1148320.4. http://www2.geo-airbusds.com/files/pmedia/public/

r5434_9_geo_022_worlddem_en_low.pdf.

5. https://www.strava.com/, accessed on 23/06/2015.6. http://runkeeper.com/, accessed on 23/06/2015.7. http://komoot.de/, accessed on 23/06/2015.8. http://gpsies.com/, accessed on 23/06/2015.9. Source of image: http://resultmaps.neis-one.org/

osmgps.html.10. gpx-planet-file, cf.: http://wiki.openstreetmap.org/

wiki/Planet.gpx, accessed on 07/08/2015.11. http://wiki.openstreetmap.org/w/index.php?title=

Map_Features&oldid=1178564.12. Available here: https://lta.cr.usgs.gov/SRTM1Arc.13. For a more detailed description of the workflow and

implementation, readers are advised to consult John(2015).

14. The tool for importing and filtering GPS traces isavailable at https://github.com/GIScience/osmgpxfilter.

15. The tool for preprocessing is available at https://github.com/GIScience/osmgpxpreprocessor.

16. Tool available at https://github.com/GIScience/osmgpxmapmatcher.

17. The tool for calculating the incline value is available athttps://github.com/GIScience/osmgpxinclinecalculator.

18. Screenshot taken from: http://cap4route.geog.uni-heidelberg.de/hd-osm-gps-webgl/hd-osm-gps-webgl.html, accessed on 20/07/2015.

19. Online geoid calculation: http://geographiclib.sourceforge.net/cgi-bin/GeoidEval, accessed on 20/07/2015.

20. http://wiki.openstreetmap.org/w/index.php?title=Key:incline&oldid=1148320.

Disclosure statement

No potential conflict of interest was reported by the authors.

Funding

A part of the research leading to these results has receivedfunding from the European Community’s SeventhFramework Programme [FP7/2007-2013] under grant agree-ment no. 612096 [CAP4Access].

ORCIDStefan Hahmann http://orcid.org/0000-0002-8145-7090

References

Abrams, M., B. Bailey, H. Tsu, and M. Hato. 2010. “TheASTER Global DEM.” Photogrammetric Engineering &Remote Sensing 76 (4): 344–348.

Arsanjani, J. J., A. Zipf, P. Mooney, and M. Helbich, eds.2015. OpenStreetMap in GIScience: Experiences, Research,and Applications. Lecture Notes in Geoinformation andCartography. Heidelberg: Springer.

Bachofer, F. 2011. “Einfluss der vertikalen Genauigkeit vonDGM aus das EcoRouting von Elektrofahrzeugen.” InAngewandte Geoinformatik 2011: Beiträge zum 23. AGIT-Symposium Salzburg, edited by J. Strobl, T. Blaschke, andG. Griesebner, 338–346. Berlin: Wichmann.

16 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

Bauer, C. A. 2010. “User Generated Content –UrheberrechtlicheZulässigkeit nutzergenerierter Medieninhalte.” InNutzergenerierte Inhalte als Gegenstand des Privatrechts, edi-ted by H. G. Ruse-Khan, N. Klass, and S. V. Lewinski, 1–42.Vol. 15. Berlin: Springer.

Boucher, C. 2013. “Fusion of GPS, OSM and DEM Data forEstimating Road Network Elevation.” In Fifth InternationalConference on Computational Intelligence, CommunicationSystems and Networks (CICSyN), 273–278. New York: IEEE.doi:10.1109/CICSYN.2013.27.

Budhathoki, N. R., B. C. Bruce, and Z. Nedovic-Budic. 2008.“Reconceptualizing the Role of the User of Spatial DataInfrastructure.” GeoJournal 72 (3–4): 149–160.doi:10.1007/s10708-008-9189-x.

Farr, T. G., P. A. Rosen, E. Caro, R. Crippen, R. Duren, S.Hensley, M. Kobrick, et al. 2007. “The Shuttle RadarTopography Mission.” Reviews of Geophysics 45 (2).doi:10.1029/2005RG000183.

Franke, D., D. Dzafic, D. Baumeister, and S. Kowalewski.2012. “Energieeffizientes Routing für Elektrorollstühle.”In 13. Aachener Kolloquium Mobilität und Stadt (AMUS/ACMOTE), 65–68. Aachen: RWTH Aachen. Accessed July21, 2015. http://publications.embedded.rwth-aachen.de/file/51

Gesch, D., M. Oimoen, Z. Zhang, D. Meyer, and J.Danielson. 2012. “Validation of the ASTER GlobalDigital Elevation Model Version 2 over theConterminous United States.” In International Archivesof the Photogrammetry, Remote Sensing, and SpatialInformation Science, XXXIX-B4, edited by M. Shortis andM. Madden, 281–286. Sydney: The ISPRS Foundation.doi:10.5194/isprsarchives-XXXIX-B4-281-2012.

Goodchild, M. F. 2007. “Citizens as Sensors: The World ofVolunteered Geography.” GeoJournal 69 (4): 211–221.doi:10.1007/s10708-007-9111-y.

Haklay, M., and P. Weber. 2008. “OpenStreetMap: User-Generated Street Maps.” IEEE Pervasive Computing 7 (4):12–18. doi:10.1109/MPRV.2008.80.

Han, S., and C. Rizos. 1999. “Road Slope Information fromGPS-Derived Trajectory Data.” Journal of SurveyingEngineering 125 (2): 59–68. doi:10.1061/(ASCE)0733-9453(1999)125:2(59).

Heipke, C. 2010. “Crowdsourcing Geospatial Data.” ISPRSJournal of Photogrammetry and Remote Sensing 65 (6):550–557. doi:10.1016/j.isprsjprs.2010.06.005.

Hofmann-Wellenhof, B., H. Lichtenegger, and E. Wasle.2008. GNSS - Global Navigation Satellite Systems: GPS,GLONASS, Galileo, and More. Vienna: Springer.

John, S. 2015. “Deriving incline for street networks fromvoluntarily collected GPS traces.” Master’s Thesis, TUBerlin. doi:10.14279/depositonce-5027.

Kono, T., T. Fushiki, K. Asada, and K. Nakano. 2008. “FuelConsumption Analysis and Prediction Model for ‘Eco’Route Search.” 15th World Congress on IntelligentTransport Systems and ITS America’s 2008 AnnualMeeting, New York, November 16–20.

Krakiwsky, E. J., C. B. Harris, and R. V. C. Wong. 1988. “AKalman Filter for IntegratingDeadReckoning,MapMatchingand GPS Positioning.” In IEEE PLANS ‘88, Position Locationand Navigation Symposium, Record. ‘Navigation into the 21stCentury’, 39–46. New York: IEEE. doi:10.1109/PLANS.1988.195464.

Langley, R. B. 1999. “Dilution of Precision.” GPS World 10(5): 52–59.

Liu, G., K. M. A. Hossain, M. Iwai, M. Ito, Y. Tobe, K. Sezaki,and D. Matekenya. 2014. “Beyond Horizontal LocationContext: Measuring Elevation Using Smartphone’sBarometer.” In Proceedings of the 2014 ACMInternational Joint Conference on Pervasive andUbiquitous Computing: Adjunct Publication, 459–468.New York: ACM. doi:10.1145/2638728.2641670.

Marchal, F., J. Hackney, and K. Axhausen. 2005. “EfficientMap Matching of Large Global Positioning System DataSets: Tests on Speed-Monitoring Experiment in Zürich.”Transportation Research Record: Journal of theTransportation Research Board 1935 (1): 93–100.doi:10.3141/1935-11.

Menkens, C., J. Sussmann, M. Al-Ali, E. Breitsameter, J.Frtunik, T. Nendel, and T. Schneiderbauer. 2011.“EasyWheel - A Mobile Social Navigation and SupportSystem for Wheelchair Users.” Eighth InternationalConference on Information Technology: New Generations(ITNG), 859–866. New York: IEEE. doi:10.1109/ITNG.2011.149.

Meyer, D. J. 2011. ASTER Global Digital Elevation ModelVersion 2 – Summary of Validation Results. Report.Washington: NASA. Accessed May 23, 2016. https://pubs.er.usgs.gov/publication/70005960

Müller, A., P. Neis, M. Auer, and A. Zipf. 2010. “EinRoutenplaner für Rollstuhlfahrer auf der Basis vonOpen-StreetMap-Daten - Konzeption, Realisierung undPerspektiven.” In Angewandte Geoinformatik 2010:Beiträge zum 22. AGIT-Symposium Salzburg, edited by J.Strobl, T. Blaschke, and G. Griesebner. Berlin:Wichmann.

Neis, P., D. Zielstra, and A. Zipf. 2012. “The Street NetworkEvolution of Crowdsourced Maps: OpenStreetMap inGermany 2007–2011.” Future Internet 4 (4): 1–21.doi:10.3390/fi4010001.

Neis, P., and D. Zielstra. 2014a. “Generation of a TailoredRouting Network for Disabled People Based onCollaboratively Collected Geodata.” Applied Geography47: 70–77. doi:10.1016/j.apgeog.2013.12.004.

Neis, P., and D. Zielstra. 2014b. “Recent Developments andFuture Trends in Volunteered Geographic InformationResearch: The Case of OpenStreetMap.” Future Internet6 (1): 76–106. doi:10.3390/fi6010076.

Ochieng, W. Y., R. B. Noland, and M. A. Quddus. 2003.“Map-Matching in Complex Urban Road Networks.”Brazilian Journal of Cartography 55 (2): 1–14. http://www.rbc.lsie.unb.br/index.php?journal=rbc&page=article&op=view&path%5B%5D=169&path%5B%5D=153.

Quddus, M. A., W. Y. Ochieng, and R. B. Noland. 2007.“Current Map-Matching Algorithms for TransportApplications: State-Of-The Art and Future ResearchDirections.” Transportation Research Part C: EmergingTechnologies 15 (5): 312–328. doi:10.1016/j.trc.2007.05.002.

Quddus, M. A., W. Y. Ochieng, L. Zhao, and R. B. Noland.2003. “A General Map Matching Algorithm for TransportTelematics Applications.” GPS Solutions 7 (3): 157–167.doi:10.1007/s10291-003-0069-z.

Ramm, F., J. Topf, and S. Chilton. 2011. Openstreetmap:Using and Enhancing the Free Map of the World. Englished. Cambridge: UIT Cambridge.

CARTOGRAPHY AND GEOGRAPHIC INFORMATION SCIENCE 17

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016

Sachenbacher, M., M. Leucker, A. Artmeier, and J.Haselmayr. 2011. “Efficient Energy-Optimal Routing forElectric Vehicles.” In Proceedings of the Twenty-FifthAAAI Conference on Artificial Intelligence, 1402–1407.Menlo Park, CA: AAAI Press.

Schilling, A., S. Lanig, P. Neis, and A. Zipf. 2009. “IntegratingTerrain Surface and Street Network for 3D Routing.” In3D Geo-Information Sciences, Lecture Notes inGeoinformation and Cartography, edited by J. Lee and S.Zlatanova, 109–126. Berlin: Springer.

Sester, M., J. J. Arsanjani, R. Klammer, D. Burghardt, and J.-H. Haunert. 2014. “Integrating and GeneralisingVolunteered Geographic Information.” In AbstractingGeographic Information in a Data Rich World, LectureNotes in Geoinformation and Cartography, edited by D.Burghardt, C. Duchêne, and W. Mackaness, 119–155.Cham, Switzerland: Springer International. doi:10.1007/978-3-319-00203-3_5.

Sui, D. Z. 2008. “TheWikification of GIS and Its Consequences:Or Angelina Jolie’s New Tattoo and the Future of GIS.”

Computers, Environment and Urban Systems 32 (1): 1–5.doi:10.1016/j.compenvurbsys.2007.12.001.

van Winden, K. 2014. “Automatically Deriving and UpdatingAttribute Road Data fromMovement Trajectories.”Master’sThesis, Delft University of Technology.

Weyrer, T., H. Hochmair, and G. Paulus. 2014. “IntermodalDoor-to-Door Routing for People with Physical Impairmentsin a Web-Based, Open-Source Platform.” TransportationResearch Record: Journal of the Transportation ResearchBoard 2469: 108–119. doi:10.3141/2469-12.

White, C. E., D. Bernstein, and A. L. Kornhauser. 2000.“Some Map Matching Algorithms for PersonalNavigation Assistants.” Transportation Research Part C:Emerging Technologies 8 (1–6): 91–108. doi:10.1016/S0968-090X(00)00026-7.

Zhang, L., F. Thiemann, andM. Sester. 2010. “Integration of GPSTraces with Road Map.” Proceedings of the SecondInternational Workshop on Computational TransportationScience, 17–22. New York: ACM. doi:10.1145/1899441.1899447.

18 S. JOHN ET AL.

Dow

nloa

ded

by [

Uni

vers

ity o

f N

ebra

ska,

Lin

coln

] at

01:

25 1

4 Ju

ne 2

016