CrowdPath: A Framework for Next Generation Routing Services using Volunteered Geographic Information

Transcription

1 CrowdPath: A Framework for Next Generation Routing Services using Volunteered Geographic Information Abdeltawab M. Hendawi, Eugene Sturm, Dev Oliver, Shashi Shekhar hendawi@cs.umn.edu, sturm049@umn.edu, oliver@cs.umn.edu, shekhar@cs.umn.edu Department of Computer Science and Engineering, University of Minnesota, Minneapolis, MN 55455, USA Abstract. Our proposed system CrowdPath is based on the hypothesis that people know their commute area better than conventional routing services that use traditional digital roadmaps and shortest path algorithms. The knowledge and experiences of drivers reflected in volunteered commute routes may provide better routes. By leveraging such available volunteered geographic information (VGI), our goal is to investigate next-generation routing services to further reduce travel time, fuel consumption, and improve navigation. Previous related work summarizes GPS tracks into a landmark graph which is used for answering routing queries. In contrast, CrowdPath directly queries a collection of map-matched GPS tracks to recommend paths from a source location to a destination. Our evaluation using real GPS tracks illustrates the promise of CrowdPath in significantly reducing travel time compared to routes from common routing providers. In the future, CrowdPath may be extended to adapt route recommendations by start time and provide safe paths using volunteered crime and accident reports. 1 INTRODUCTION Given a source location, a destination, and a user preference function (e.g., minimize travel time, fuel consumption), routing services provide a set of paths from source to destination that optimizes the user preference function. Examples of routing services include in-car GPS devices, web-based applications, cellphones, etc. The proliferation of volunteered geographic information (VGI) such as GPS tracks donated by individuals via forums such as OpenStreetMap [3] has created an opportunity for providing next generation routing services. Next-generation routing is important for critical societal applications such as further reducing fuel consumption, commute time, and traffic congestion, as well as improving navigation. Preliminary evidence for the transformative potential of next-generation routing includes the experience of UPS, which saves millions of gallons of fuel by simply avoiding left turns [2]. Such turn modeling information (as well as traffic light synchronization, slowdowns at curves) may be gleaned from the volunteered commute routes of individuals. This problem is challenging because accurate modeling of driving conditions such as traffic delays, potholes, traffic light synchronization, and weather conditions, is very difficult. Accurate modeling of user behavior and recent changes in maps is also challenging.

2 Fig. 1. The CrowdPath System Architecture Previous related work summarizes GPS tracks into a landmark graph which is used for answering routing queries. For example, T-Drive [4] considers GPS tracks for taxis where the tracks are sampled every five minutes. This approach is able to offer rush hour vs non rush hour routing services for high cab-traffic areas. Edges in the landmark graph correspond to a sequence of segments in the roadmap used to pose routing queries. In contrast, the proposed CrowdPath system directly queries a collection of mapmatched GPS tracks to recommend paths from a source location to a destination. Crowd- Path is based on the hypothesis that people know their commute area better than conventional routing services that use traditional digital roadmaps and shortest path algorithms. In fact, individuals examine many paths using alternate preference functions (e.g., minimize travel time, minimize fuel consumption, avoid potholes, scenic routes) from their home to work until they find their favorite ones. This may be seen in the way some people do not completely follow directions given by routing providers in certain nearby areas where they have more experience. Based on this observation, CrowdPath collects volunteered GPS tracks for people s daily trips from different sources such as OpenStreetMap [3]. These tracks are analyzed to extract only the valid ones that do not contain unreasonable behavior such as speed limit violations, e.g., speeds above 90 miles per hour on highways. The travel time and distance costs of all possible sub-trip combinations inferred from the valid tracks are compared to the ones recommended by routing providers. Scope and Outline: A comparison with T-Drive and shortest path algorithms is limited to a conceptual discussion. A detailed comparison is outside the scope of this work. We assume that GPS commute routes are donated and issues such as privacy are beyond the scope of the present research. These limitations may be investigated in future work. 2 SYSTEM OVERVIEW System Architecture: The architecture of the CrowdPath system is given in Figure 1. CrowdPath has three main types of data sources, namely, public GPS traces, routing providers, and risk reports. The system has three main components, namely, the attributed time aggregated graph (ATAG) data structure, the Data Analysis and Maintenance module, and the Query Processing module. This section discusses the data sources and system components.

3 Fig. 2. Attributed Time Aggregated Graph (ATAG) Data Sources: The proposed framework relies on data extracted from three main sources. (1) Public GPS Traces. Our main source of volunteered data is OpenStreeMap (OSM) which allows the download of volunteered GPS traces filtered by areas of interest. We use a tool provided on the OSM wiki called JOSM which allows us to view OSM data and collect the GPS traces for a specified area. For example, in Minneapolis, Minnesota, USA, we found about 326 GPS tracks consisting of hundreds of thousands of GPS points. (2) Routing Services. This data source accesses three major mapping and routing services, namely, Google Maps, Bing Maps, and MapQuest to extract direction, distance cost, and travel time cost for their recommended paths between the start and end points of a user trip. The data is accessed by sending http requests to each provider to get the recommended path between start and end points. The time and distance costs are then obtained from the returned path. (3) Risk Reports. The final data source contains data about car accidents and crime linked to their locations and times during the day. This source will be included in future versions with more routing preference functions. ATAG Data Structure: To save all the data in a way that allows us to compute the shortest path from a given source location to a destination, we introduce the attribute time aggregated graph (ATAG). Potentially ATAG may be used to support other preference routing functions, e.g., less fuel consumption, less car accidents, less pollution, or paths with more services. This graph data structure is an adapted version of the existing time aggregated graph (TAG) [1] in which intersections are represented as nodes and roads as edges, and each edge can have multiple weights. The existing TAG graph carries values for only one feature or attribute such as travel time cost. By contrast, each edge in the ATAG data structure can have more than one attribute, e.g., distance, time, risk; for each edge, we store multiple weights in different time slots. Figure 2 illustrates the idea of storing multiple attributes for each single edge in the ATAG data structure. As can be seen in the figure, each edge has three different attributes (i.e., distance, travel time, and risk) and each attribute can have either one value like the distance attribute or many values like the travel time attribute which has values in ten different time instances. The edge between (N 1,N 3 ) has a weight of one distance unit for all times of the day, four units for travel time starting at the sixth time slot (weights for travel time do not exist during the first five time slots), and four units for risk starting on the first time slot of the day. The main difference between ATAG and the landmark graph [4] is that the latter summarizes GPS tracks into the main road segments. In contrast, ATAG directly maps the GPS tracks to their equivalent road edges in the underlying road network graph. Also, the advantage of introducing ATAG over the traditional time-series

4 Fig. 3. The CrowdPath Main GUI (Best in color) graph [1] is that the former does not need to replicate the data which in turns saves storage and reduces I/O cost. Analysis and Maintenance Module: The main function of this module is to extract and store valid GPS tracks from the set of all tracks obtained. These valid tracks are made available to the query processor for answering routing queries. The analysis and maintenance module only extracts the tracks that do not violate certain validation checks (e.g., speed limit). The module then map matches the points inside each track to their corresponding nodes in ATAG. After that, the costs, e.g., travel time or distance, between each pair of points are used to update the weights of the equivalent edges at the same time slot of the day. Another potential technique is to store valid tracks as a whole and retrieve them without requiring further computation. This can be done using a three dimensional matrix (start, destination, time slot), however, the matrix will be sparse. Query Processing Module: The dynamic nature of the underlying road network is captured through ATAG where each edge could have multiple weights at different time slots of the day. Traditional shortest path algorithms that assume one weight for each edge are not suitable for answering routing queries in our dynamic graph. The main challenge here is to design efficient, valid, and expandable query processing algorithms to take into consideration the spatio-temporal aspects of the network while evaluating routing queries. An efficient algorithm reduces computation cost, a correct algorithm returns a valid path, and an expandable routing algorithm answers potential queries using the multiple attributes on edges in just one traversal, e.g., finding shortest paths with less fuel consumption. To this end, we leverage the SP-TAG algorithm [1] to find the optimal path between two nodes given a graph structure with multi-weight edges. 3 DEMONSTRATION The goal of this demonstration is to solicit audience feedback on how to improve the CrowdPath system to include other routing preference functions (e.g., fuel consumption, pollution, services on roads, potential coupons and sales, safety, etc.). We plan to prioritize these preference functions based on the feedback we get.

5 Our demonstration will include the following. First, the user can interact with the CrowdPath system to browse the available GPS-tracks and examine the structure of associated.gpx files (basic format for storing GPS tracks). The user is also able to examine the validation techniques we applied to the volunteered GPS-tracks to eliminate the tracks with issues (e.g., speed limit violations and topologically unreasonable tracks). The audience will see a sample of the valid tracks versus the invalid ones. In addition, we will present some of the GPS-tracks that are similar to the routes given by the conventional routing services and show how we do the analysis and comparison. Furthermore, we will present a coverage map to illustrate the distribution of the obtained volunteered GPS-tracks in different areas on the map. Moreover, the user is able to upload new GPS tracks from which the system extracts valid tracks and sub-tracks. Finally, the user can examine the main GUI of the CrowdPath system, Figure 3, to ask for a routing service by entering the start and destination locations, specified as latitude and longitude or as an exact address. The user will be able to compare the routes returned by conventional routing providers (blue line) and the route recommended based on the volunteered GPS tracks (red line) in terms of the total travel time and distance. For example, consider the start location 3308 California St NE, Minneapolis, MN 55418, USA and the destination University of Minnesota Transit way, St Paul, MN 55114, USA. A traditional routing service recommends a route that has a travel time of 19 minutes whereas the route recommended by CrowdPath has a travel time of 14 minutes. In this test case, the CrowdPath route is faster and saves about 26% of the total driving time, which may reduce fuel consumption and the impact on both the environment and traffic. 4 CONCLUSION In this demonstration paper we investigated the problem of next generation routing services using volunteered commute routes. This problem is important for critical societal applications such as further reducing travel time, and fuel consumption. We presented the CrowdPath system that is based on the hypothesis that people know their commute area better than conventional routing services that use traditional digital roadmaps and shortest path algorithms. CrowdPath directly queries a collection of map-matched GPS tracks to recommend paths from a source location to a destination. We presented an evaluation using real GPS tracks that demonstrates the promise of CrowdPath in significantly reducing travel time compared to routes from common routing providers. In future work, we plan to elaborate further on the system details (e.g., data structures and algorithms). We also plan to extend CrowdPath to adapt route recommendations by start time and provide safe paths using volunteered crime and accident reports. References 1. B. George, S. Kim, and S. Shekhar. Spatio-temporal network databases and routing algorithms: A summary of results. Advances in Spatial and Temporal Databases, J. Lovell. Left-hand-turn elimination. Dec OSM. Public GPS traces. Jan J. Yuan, Y. Zheng, C. Zhang, W. Xie, X. Xie, G. Sun, and Y. Huang. T-drive: driving directions based on taxi trajectories. In ACM SIGSPATIAL GIS, California, USA, Nov