Comparing Alternative Route Planning Techniques: A Comparative User Study on Melbourne, Dhaka and Copenhagen Road Networks
Lingxiao Li, Muhammad Aamir Cheema, Hua Lu, Mohammed Eunus Ali, Adel N. Toosi
CComparing Alternative Route Planning Techniques: AWeb-based Demonstration and User Study
Lingxiao Li ‡ , Muhammad Aamir Cheema ‡ , Hua Lu † , Mohammed Eunus Ali § , Adel N. Toosi ‡‡ Faculty of Information Technology, Monash University, Australia § Bangladesh University of Engineering and Technology, Bangladesh † Department of Computer Science, Aalborg University, Denmark ‡ { lingxiao.li, aamir.cheema, adel.n.toosi } @monash.edu, † [email protected], § [email protected] ABSTRACT
Due to the popularity of smartphones, cheap wireless net-works and availability of road network data, navigation ap-plications have become a part of our everyday life. Manymodern navigation systems and map-based services do notonly provide the fastest route from a source location s to atarget location t but also provide a few alternative routesto the users as more options to choose from. Consequently,computing alternative paths from a source s to a target t hasreceived significant research attention in the past few years.However, it is not clear which of the existing approaches gen-erates alternative paths of better quality because the qualityof these alternatives is mostly subjective. Motivated by this,in this paper, we present the first user study that comparesthe quality of the alternative routes generated by four ofthe most popular existing approaches including the routesprovided by Google Maps. We also present the details ofa web-based demo system that can be accessed using anyinternet enabled device and allows users to see the alterna-tive routes generated by the four approaches for any pairof source and target selected by the users. Our user studyshows that although the mean rating received by GoogleMaps is slightly lower than the mean ratings received bythe other three approaches, the results are not statisticallysignificant. We also discuss the limitations of this user studyand recommend the readers to interpret these results withcaution because certain factors beyond our control may haveaffected the participants’ ratings.
1. INTRODUCTION
Given a source location s and a target location t in agraph, a shortest path query (e.g.,see [13, 1]) returns thepath from s to t with the minimum total weight (e.g., traveltime, distance). The shortest path query is one of the mostfundamental queries in graphs and has applications in a widevariety of domains such as in road networks where a usermay issue the shortest path query to find a route to travelfrom one location to the other. Since the shortest path maynot always match a user’s traveling choices, modern map-based systems often provide several alternative routes sothat the user can choose a path that they find most suitable.It is critical for the effectiveness of the alternative routes thatthese routes are significantly different from each other andare meaningful (e.g., without unnecessary detours).Inspired by the importance of alternative routes, in thepast several years, a large body of research has focused oncomputing alternative routes [11, 2, 7, 3, 10, 9, 12]. In- tuitively, the alternative routes reported to the users mustbe meaningful/natural and significantly different from eachother. However, there is no agreed definition of what con-stitutes a set of “good” alternative routes. This is becausethe “goodness” of the alternative routes is mostly subjectiveand it is not trivial to define quantitative measures to eval-uate the quality of routes. This necessitates a user study tocompare the perceived quality of the alternative routes gen-erated by the existing techniques. Surprisingly, there doesnot exist any such systematic study that is concerns howusers perceive the quality of the routes provided by differ-ent techniques.To fill this gap, in this paper, we present the first userstudy that compares four popular techniques including GoogleMaps which is among the most widely used commercial so-lutions providing alternative routes. Specifically, we create aweb-based demo system that asks users to select source andtarget locations within the Melbourne Metropolitan area. Itthen displays up to 3 routes generated by the following fourtechniques: Google Maps, Plateaus [11, 2], Penalty [7, 3]and Dissimilaritys [10, 9, 12]. The users are asked to pro-vide a rating from 1-5 (higher the better) for each of thefour approaches.In total, we received 237 responses (156 from Melbourneresidents and 81 from non-residents). We show the meanrating and standard deviation for each of the four approachesfor different groups of respondents. Also, we show the meanrating based on the lengths of the routes (small routes,medium routes and long routes). The overall mean rat-ings for Google Maps, Plateau, Dissimilarity and Penaltyare 3 .
37, 3 .
63, 3 .
58 and 3 .
56, respectively. However, a one-way ANOVA test shows that the results are not statisticallysignificant. We remark that the data used by Google Maps to compute the alternative routes is different from the Open-StreetMap (OSM) data used by the other three approaches.We provide the details of how this may have impacted theparticipants’ ratings. We also list some other limitations ofthis user study that are beyond our control.The rest of the paper is organized as follows. In Section 2,we describe some of the most popular existing techniques tocompute alternative paths including the three approaches weuse in the user study. The details of our web-based demo Google Maps uses real-time and/or historical traffic datato compute the routes. This data is not made publicly avail-able. Therefore, we were unable to use Google Maps datafor all four approaches. Also, it is not possible to enforceGoogle Maps to generate alternative routes using the Open-StreetMap data.1 a r X i v : . [ c s . D B ] J un ystem are presented in Section 3. The details of our userstudy and its results are presented in Section 4. Some lim-itations of the user study are also discussed in Section 4.Section 5 concludes this paper.
2. RELATED WORK
Computing alternative routes has received significant re-search in the past decade or so [11, 2, 7, 3, 10, 9, 12]. In thissection, we briefly describe some of the most popular tech-niques and focus on presenting the details of the three tech-niques that we compare in this user study: Penalty, Plateausand Dissimilarity.
The basic idea behind this technique [3, 7] is to iterativelycompute shortest paths and, after each iteration, apply apenalty on each edge of the shortest path found in the pre-vious iteration (by increasing its weight by a certain factor).Since the edge weights of the previous shortest paths areincreased, it is likely that the new shortest path found onthe graph will be different from the previous path(s). Thealgorithm stops when k shortest paths are retrieved.This approach does not guarantee that the paths are “sign-ficiantly” different from each other or are meaningful (e.g.,without small detours). However, we observe that, in prac-tice, the routes generated by this approach turn out to bepretty good in most of the cases. This is mainly because,on typical road networks, there exists several different pathsfrom s to t with very similar traveling time. Thus, whenthe algorithm applies penalty to one of these paths, it nat-urally tends to select the other significantly different paths.Furthermore, after retrieving each path, the algorithm canspecifically apply additional filtering criteria to remove thepaths that fail to meet certain requirements, e.g., the pathsthat are too similar to existing paths or have detours. The technique to generate alternative paths using plateauswas developed [11] by Cotares Limited for their routing en-gine Choice Routing. We use Fig. 1 to illustrate how al-ternative paths from Cambridge (source s ) to Manchester(target t ) are generated using plateaus. First, two shortestpath trees are generated: a forward shortest path tree T f rooted at s (see Fig. 1(a)); and a backward shortest pathtree T b rooted at t (Fig. 1(b)). Then, the two trees T f and T b are joined to obtain the branches common in both trees.These common branches are called plateaus. Fig. 1(c) showssome of the most prominent plateaus. It was noted [11] thatlonger plateaus result in more meaningful alternative paths.Therefore, top- k plateaus are selected based on their lengths.Let u and v be two ends of a plateau pl ( u, v ) where u is theend closer to the source and v is the end closer to the target.Each plateau pl ( u, v ) is used to generate an alternative pathby appending the shortest paths from s to u and v to t tothe plateau. Fig. 1(d) shows five alternative paths generatedusing the five longest plateaus from Fig. 1(c).It was shown that the alternative paths generated usingplateaus are local optimal [2]. Furthermore, the plateausdo not intersect each other. Thus, two paths generated us-ing longer plateaus are expected to have a smaller overlap(i.e., lower similarity). Thus, the paths generated using the k longest plateaus are likely to be more dissimilar to eachother. The computational cost to compute alternative paths Manchester Cambridge
Figure 1. Source tree from Cambridge
Another by-product of the computation of this tree is that for each point, we have computed and stored the cost of the minimum cost route from the origin A to that point.
We then compute the single most optimum routes from all nodes to the destination B. These are a tree that contains chains of points that form the good routes for getting towards B. (a) T f rooted at Cambridge Manchester Cambridge
Figure 2. Destination tree to Manchester
We now look for sequences of directly linked points that are found in both trees, in the same order. These are chains that are both good for getting away from A and towards B. Any good route from A to B is going to involve some of these chains. The longer the chains are, the better they are going to be in getting from A to B. The chains represent the best roads in their area that are well-aligned for getting from A to B, which is just what we are after. To find these chains, we begin by adding together the costs from each tree. For a general point C, the source tree gives us the cost of follwing the optimum route from A to C. The cost from the destination tree gives us the cost of following the optimum route from C to B. Thus the sum of these costs at C gives us the cost of the optimumroute from A to B via C. If there is a point D that adjoins C and where a link from C to D is contained in both trees, then the cost in one tree will increase by exactly the amount by which it decreases in the other tree, so the sum remains the same. Thus the chains that we are interested in are characterised in that the cost-sum at each node in the chain is constant. The route involving the chain will begin at the source node where the cost-sum is the cost of the optimum route from A to B. As the route proceeds towards C, if C is not on the optimal route, that cost-sum will rise at some nodes, then reach and stay at the cost-sum at C for some while (the length of the chain), then decrease at some nodes until the destination is reached. For this reason, we call the chain a plateau . We find these by grouping together all sets of nodes that have the same cost-sum and that are connected directly by a link. (b) T b rooted at Manchester Manchester
Cambridge
Figure 3. Combination tree
Another way to find the links that are in the plateaux is to mark links that have back pointers in the source tree pointing to them, and the links that have back pointers in the destination tree pointing to them. Then, if a link has both marks, it is part of a plateau. It is essential to use the back pointers rather than the costs if the trees have been computed using a time-dependent cost function.
Many routing engines compute only a subset of the source or destination tree. One approach is to preferentially search roads in the direction of the destination, using a variant of the A* algorithm. In this case, the trees will explore roughly elliptical areas with A and B as the foci of the ellipse. These trees must still cover all feasible routes (otherwise they might miss the optimum), and so when they are combined, they still yield the same choice routes. Another approach is to route along a subset of roads which are known to be better for use in crossing the country, which we will call priority roads. Of course, local roads must be searched in the vicinity of the source and destination, but the main computation across the space between source and destination is vastly reduced by only searching along this subset of known good roads. Again, the trees must cover most feasible routes, otherwise the optimum could be missed. The trees can therefore be combined in the usual way to identify the plateau, and a set of choice routes is generated. For the ultimate in computation speed and memory reduction, the techniques above can be combined, and other clever optimisations may also be used. We have (c) Tree Join implemented both of these techniques, as well as the full routing algorithm, and can demonstrate choice routing running over any combination. Whichever way the trees are computed, so long as they cover sufficient roads to identify the optimum route, they must also be exploring the other near-optimal routes to some extent, and our method of combining the trees will yield the good choices.
Once the links that are parts of plateaux are marked, we scan all of the links, following plateaux as we find them, marking the links as traversed, and keeping a note of the length of the plateau and the link that generated it. We keep a note of the longest n plateaux found in this way. When the scan has finished, we have a list of the longest n plateaux that have been generated by combining the trees. We can generate a full route from a plateau by choosing any point in the plateau, and tracing it back to A in the source tree, and to B in the destination tree. There will be many such routes, some generated by only tiny plateau. What we look for are the longest plateau. Actually, where we refer to “longest”, we really mean “highest cost”. We also want routes that are not too much longer than the single most optimal route. The simplest assessment is to use the length of the chain, minus the length of the overall generated route. Call this C - R. This can be expressed as the amount of the generated route that is outside of the chain, and can be simply computed from values stored in the trees. It is a negative quantity, and the less negative it is, the better the route. This quantity can be used to rank the routes in order of preference, and we find that the routes that we are interested in are indeed brought to the fore. Manchester Cambridge Figure 4. Plateau routes (d) Plateau-based paths
Figure 1: Alternative paths using plateaus. Imagesadapted from [11] with permission. consists of generating two shortest path trees (e.g., using Di-jkstra’s algorithm) and joining the two trees. The latter canbe done in time linear to the size of the tree [11]. Thus, thetotal cost is dominated by the two Dijkstra searches.
Some existing works [10, 9, 12] specifically define a dis-similarity function dis ( p, P ) to compute the dissimilarity ofa candidate path p to a set of paths P . The aim is to iter-atively add paths to the result set P in ascending order oftheir lengths as long as they are sufficiently dissimilar to thepreviously selected paths. Specifically, a path p is added to P only if dis ( p, P ) > θ where θ is a user-defined dissimilaritythreshold. As a result, the k paths reported to the user aresignificantly different to each other and are short.The advantage of this approach is that it guarantees thatthe alternative paths are sufficiently dissimilar to each other(as defined by the parameter θ ). However, this approachdoes not guarantee that the generated alternative paths arefree of small unnecessary detours. This can be addressed byhaving additional filtering criteria to prune the paths thatdo not meet certain criteria. A major disadvantage of thisapproach is that the problem is NP-hard [10, 12]. The exist-ing studies have proposed several approximate algorithms.However, many of these techniques still appear to be tooslow taking tens of seconds to report alternative paths on acity-scale road network.In this study, we use SSVP-D+ [9] which has been shownto generate good quality alternative routes and has reason-able computation time. The basic idea is to use via-nodes togenerate paths. A path (called via-path) generated using avia-node u is the concatenation of sp ( s, u ) and sp ( u, t ) where sp ( x, y ) denotes the shortest path from x to y . To efficientlycompute sp ( s, u ) and sp ( u, t ), similar to the plateaus-basedapproach, two shortest path trees are constructed rooted at s and t , respectively. The algorithm iteratively selects via-nodes in an ascending order of their via-paths lengths. Avia-path is added to the result set only if its dissimilarity tothe existing paths in P is greater than the threshold θ .2a) A user selects source and target locations (b) Alternative routes by each approach are displayed Figure 2: User InterfaceFigure 3: Feedback form
Yen’s algorithm [14] can be used to compute k shortestpaths from s to t . However, these k shortest paths are allexpected to be very similar to each other. Thus, Yen’s al-gorithm is not suitable for generating alternative paths ifapplied trivially. However, some existing techniques (e.g.,see [8]) use Yen’s algorithm to incrementally generate short-est paths and apply filtering techniques to prune the pathsthat do not meet certain criteria. Pareto optimal [5, 6] paths(i.e., skyline paths) report the paths that are not dominated by any other path according to given criteria (e.g., distance,travel time and ease of traveling). Many techniques use via-nodes to generate alternative paths (e.g., the SSVP-D+techniques discussed in Section 2.3). Such techniques iden-tify interesting via-nodes in the road network and then ap-ply different filtering/ranking criteria to generate the top- k alternative paths.
3. DEMONSTRATION SYSTEM
Our web-based demonstration system consists of the fol-lowing major components: 1) road network constructor; 2) http://aamircheema.com/routing/demo.html user-interface; 3) query processor. We briefly describe eachcomponent below. Road Network Constructor:
The road network construc-tor takes a rectangular area as input and extracts the roadnetwork data from OpenStreetMap (OSM) that lies withinthe input rectangle. We design our demo system to allowrouting queries only in Melbourne Metropolitan area, i.e.,the input rectangle covers the Melbourne Metropolitan area.First, we export the raw OSM data using Geofabrik . Then,we filter the data that lies in the input rectangle. Finally,we parse the content of this raw OSM data to generate theroad network data needed for the approaches. Specifically,we extract tuples where each tuple represents an edge of theroad network along with its end vertices and edge weight(travel time). The travel time is obtained by dividing thelength of the edge with the maximum speed along the edge.In real-world scenarios, the vehicles may need to stop at in-tersections, wait at traffic lights or slow down while turningeven when there is no congestion on the roads. Thus, esti-mating the travel time using maximum speed is not realistic.To better simulate real-world scenarios, for each road seg-ment that is not a freeway/motorway, we multiply the edgeweight (travel time) by 1.3. Our trials showed that thisresults in a reasonably good estimate of actual travel timewhen the roads have no congestion (e.g., compared with thetravel time estimated by Google Maps at 3:00 am). User Interface:
The user interface is a dynamic web pagecreated using HTML, Javascript, and JQuery. It has twomain functionalities: (1) sending the user’s query request tothe back-end, and (2) interacting with Google Maps API to plot the routes on Google Maps. More specifically, ini-tially, it displays Melbourne region on Google Maps. A usercan click anywhere on the map within a specified rectangulararea (corresponding to the Melbourne Metropolitan area) topick two markers corresponding to the source and target lo-cations, respectively (see Fig. 2(a)). When the user pressesthe “Submit” button, the source and target locations aresent to the back-end which computes the alternative routesgenerated by the Penalty, Plateaus and Dissimilarity tech-niques. Additionally, the routes generated by Google Mapsare also obtained by calling its API. The routes generatedby each of the four approaches are then displayed in a new http://download.geofabrik.de/ https://developers.google.com/maps/documentation/ Query Processor : The input to the query processor is apair of source and target locations each represented by longi-tude and latitude. First, the query processor performs geo-coordinate matching and selects the closest vertices fromthe OSM data to the source and target locations, respec-tively. Then, the query processor computes the alternativeroutes from the source location to the target location usingthe three techniques we implemented (Penalty, Plateaus andDissimilarity). It also calls Google Maps API to get the al-ternative routes generated by Google Maps. For each of theroutes generated by these four approaches, the query proces-sor computes its travel time by using the OSM data. Eachtravel time is rounded to display time in minutes. Finally,the routes generated by each approach are passed to GoogleMaps API to display these routes using different colors sothat they are easily distinguishable.
Parameter Details:
The three approaches that we imple-mented (Penalty, Plateaus and Dissimilarity) use some pa-rameters. As suggested in [4], for the Penalty approach,the penalty that we apply to each edge is 1 .
4, i.e., the edgeweight is multiplied by 1 .
4. For the Plateaus and Dissimilar-ity approaches, we use the upper bound [2] to be 1 . . θ forthe Dissimilarity approach is set to 0 .
4. USER STUDY
We created a webpage explaining the purpose and back-ground of this research and providing instructions to theparticipants. The participants were able to provide feed-back using any internet enabled device (e.g., laptop, tabletsor smartphones). We sent the requests for participation inthe study via emails and personal messages. Most of therequests were sent to the people living in Melbourne whowere likely to be familiar with the roads. For the sake ofthis study, we say a participant is Melbourne resident ifhe/she was living (or had lived) in Melbourne at the timeof participation. We also sent requests to non-residents toget their ratings for each approach based on their perceivedroute quality. The Melbourne residents were requested toselect the source and target locations for the routes familiarto them (although we cannot guarantee if they always didso). We made sure that none of the approaches tries to avoidtoll roads and we told the participants to ignore toll chargeson the roads. In total, we received 237 responses (156 fromMelbourne residents and 81 from non-residents). http://aamircheema.com/routing We show the results (mean rating and standard devia-tion) for each approach for different groups of participants(Melbourne residents vs non-residents). We also group theresponses based on the lengths of the shortest routes fromsource to target locations. Specifically, small routes corre-spond to all the responses where the fastest travel time from s to t was at most 10 minutes. Medium and long routes cor-respond to the responses with fastest travel time from s to t within ranges (10 ,
25] and (25 ,
80] minutes, respectively.The highest mean rating for for each group is shown usingbold font.The results in Table 1 show the results for all respon-dents. The Plateaus achieves the highest mean rating andGoogle Maps the lowest considering all responses. It is alsointeresting to note that Penalty has the highest mean ratingfor the small routes whereas Dissimilarity and Plateaus per-form better for the medium and long routes, respectively.Also note that the difference between the mean ratings ofGoogle Maps and the other approaches shrinks, consideringresponses only from Melbourne residents. This indicatesthat the routes provided by Google Maps may be perceivedto be of poor quality by non-residents when in fact they maynot be necessarily so. Next, we provide detailed results con-sidering responses only from Melbourne residents (Table 2)and non-residents (Table 3).Table 2 shows the results considering responses only fromthe Melbourne residents. Dissimilarity achieves the high-est overall mean rating whereas Plateaus and Penalty havemarginally lower mean ratings. As earlier, Penalty per-forms the best for the small routes whereas Dissimilarityand Plateaus have the highest mean ratings for medium andlong routes, respectively. The results considering only thenon-residents are shown in Table 3. Plateaus achieves thehighest mean rating whereas the Google Maps the lowest.Interestingly, the mean rating for each approach is smallercompared to the mean rating received by Melbourne resi-dents (significantly smaller for medium routes).We also conducted one-way ANOVA tests for differentcategories of respondents. Given a null hypothesis of nostatistically significant difference in mean ratings of the fourapproaches, the p-value is relatively high (p-value=0.16 con-sidering all respondents, p-value=0.68 for Melbourne resi-dents and p-value=0.18 for non-residents) suggesting thatthere is no evidence that the null hypothesis is false, i.e.,there is no credible evidence that the four approaches re-ceive different ratings on average.
While we have tried our best to be as fair as possible toall the approaches, certain factors may have affected theparticipants’ perceived quality of the routes. Below we listsome of these.
Different data used by Google Maps and other ap-proaches:
One of the major factors (beyond our control)potentially affecting the participants’ ratings is that the dataused by Google Maps and the OpenStreetMap (OSM) dataused by the other three approaches are different. To estimatethe travel time, Google Maps uses real-time traffic data (orhistorical data for queries issued at future dates/times). Tominimize the impact of real-time traffic or historical traf-fic data, we call Google Maps API to retrieve the routesat 3:00 am on the next day (assuming minimal traffic on4 oogle Maps Plateaus Dissimilarity Penalty (1.25) 3.58 (1.29) 3.56 (1.17) 237
Melbourne residents (1.22) 3.66 (1.12) 156
Non-residents (1.38) 3.34 (1.37) 3.37 (1.25) 81
Small Routes (0, 10] (mins) (1.08) 66
Medium Routes (10, 25] (mins) (1.26) 3.42 (1.23) 109
Long Routes (25, 80] (mins) (1.13) 3.45 (1.44) 3.54 (1.14) 62
Table 1: All responses: Mean rating m and standard deviation sd for each approach shown as m ( sd ) .Google Maps Plateaus Dissimilarity Penalty (1.22) 3.66 (1.12) 156 Small Routes (0, 10] (mins) (0.99) 38
Medium Routes (10, 25] (mins) (1.13) 3.55 (1.17) 83
Long Routes (25, 80] (mins) (1.10) 3.54 (1.44) 3.60 (1.09) 35
Table 2: Only Melbourne residents: Mean rating and standard deviation for each approachGoogle Maps Plateaus Dissimilarity Penalty (1.38) 3.34 (1.37) 3.37 (1.25) 81
Small Routes (0, 10] (mins) (1.08) 3.61 (1.17) 28
Medium Routes (10, 25] (mins) (1.33) 26
Long Routes (25, 80] (mins) (1.21) 3.33 (1.47) 3.48 (1.22) 27
Table 3: Only non-residents: Mean rating and standard deviation for each approach (a) Routes by Google Maps (b) Routes by Plateaus
Figure 4: Blue and Green routes by both approaches are the same. The purple route by Google Maps looksmore complicated and has higher travel time than the purple route by Plateaus when OpenStreetMap datais used but has smaller travel time when Google Maps data is used to compute the travel time. roads at that time). However, the travel time estimation forthe same route may still be different for Google Maps andOpenStreetMap data. We observe that this difference inthe underlying data affects the routes generated by GoogleMaps and the other approaches.Consider the example given in Fig. 4 that shows the al-ternative routes generated by Google Maps and Plateausfor the same pair of source and target. While the blue andgreen routes returned by both approaches are the same, thepurple route returned by Google Maps looks significantlymore complicated and appears to have detours. We care-fully looked into the purple routes provided by the two ap-proaches. It turns out that if the data from OpenStreetMapis used, the travel time of the purple route by Google Mapsis a few minutes higher than that of the purple route byPlateaus. However, when Google Maps data is used to ob-tain the travel times (by forcing Google Maps to generate apath taken by Plateaus), the travel time of the purple route taken by Plateaus is a few minutes higher than that of thepurple route by Google Maps. A user looking at the routesin Fig. 4 is likely to give a higher rating to Plateaus but thismay be unfair because the two approaches are essentiallyusing different underlying data.
Apparent detours that are not:
Due to the complexstructure of road networks, a participant may incorrectlyassume that a route provided by an approach has a detour.In the example of Fig. 4(a), the purple route by GoogleMaps appears to have a detour, e.g., one may assume thatthe route should have turned left at around “Shrine of Re-membrance” instead of the detour. However, this is not adetour because the route goes through a tunnel and thereis no left turn available near “Shrine of Remembrance”, i.e.,the path returned by Google Maps is a reasonable path. Un-less a user is familiar with these roads and/or carefully looksat the road structure (e.g., by zooming in), he/she may per-ceive it as a detour and give a lower rating. We remark5hat this does not only negatively affect the ratings receivedby Google Maps. Other approaches may also be negativelyaffected by such scenarios where a user may incorrectly as-sume a reasonable route to have detours.
Biases to favorite routes/navigation systems:
A par-ticipant’s rating may be biased by his/her favorite routes (orhis/her favorite navigation system). E.g., a person who reg-ularly uses Waze to travel from home to office may perceivethe routes that are similar to those provided by Waze tohave a better quality, although this may not be necessarilytrue. For example, one participant submitted the followingcomment: “no route using Blackburn rd” . We believe thatthe route via Blackburn road is his/her favorite route whichwas not returned by any of the approaches. Consequently,the maximum rating the user gave to any approach in thiscase was 3.
Additional filtering/ranking criteria are not consid-ered:
For the approaches that we implemented (Plateaus,Dissimilarity and Penalty), we could choose to use someadditional filtering/ranking criteria to refine the top- k al-ternative routes. For example, we could improve the routesgenerated by Penalty and Plateaus by pruning the alterna-tive routes that have very high similarity to the other routes.Similarly, we could filter the routes in Penalty and Dissim-ilarity approaches that did not satisfy local optimality [2].Some comments from the participants also point out that,at least some, users consider certain factors to be importantwhich we did not consider in our implementation but can beeasily included.For example, some comments from the participants were: “Approach C provides paths with less turns ”; “less zig-zagis better” ; and “highest rated path follows wide roads” . Thisindicates that these users perceive the routes to be better ifthey have fewer turns or are using wider roads (which prob-ably means roads with more lanes). Since Google Maps is awidely used commercial product, we believe that they wouldhave spent significant time and resources to identify such po-tentially important factors and implement additional filter-ing/ranking criteria to report alternative routes. However,most of these filtering criteria can also be easily included forthe other approaches but are not considered in this study.Considering the factors mentioned above (and the otherunforeseen factors), we recommend the readers to make anyconclusions with caution. However, we believe that ourstudy shows evidence that the three approaches that we im-plemented (Plateaus, Dissimilarity and Penalty) are at leastcomparable to Google Maps. We also received some com-ments from the participants indicating that they find theroutes to be of similar quality. For example a participantcommented: “I don’t see these approaches as very distinctfrom each other.” . Another participant sent a personal mes-sage to the authors stating that he is finding it hard to rankthe approaches since they all seem to be of similar quality.
5. CONCLUSIONS
This is the first detailed user study that compares some ofthe most popular approaches to generate alternative routes,including Google Maps which is one of the most widely usednavigation applications. We develop a web-based demo sys-tem to conduct the user study. Our results show that thethree approaches published in the literature provide alter-native routes of similar quality to each other. Although themean ratings received by these approaches is higher than that of Google Maps, one-way ANOVA test shows that theresults are not statistically significant. We also identify thelimitations of this study that might have potentially affectedthe ratings submitted by the participants. Despite the limi-tations of the study, we believe that it is fair to conclude thatthe three approaches (Plateaus, Dissimilarity and Penalty)are promising and the quality of routes generated by them isat least comparable to the routes provided by Google Maps.
6. REFERENCES [1] I. Abraham, D. Delling, A. V. Goldberg, and R. F.Werneck. A hub-based labeling algorithm for shortestpaths in road networks. In
International Symposiumon Experimental Algorithms . Springer, 2011.[2] I. Abraham, D. Delling, A. V. Goldberg, and R. F.Werneck. Alternative routes in road networks.
Journalof Experimental Algorithmics (JEA) , 18:1–3, 2013.[3] V. Akg¨un, E. Erkut, and R. Batta. On findingdissimilar paths.
European Journal of OperationalResearch , 121(2):232–246, 2000.[4] R. Bader, J. Dees, R. Geisberger, and P. Sanders.Alternative route graphs in road networks. In
International Conference on Theory and Practice ofAlgorithms in (Computer) Systems , 2011.[5] F. Barth and S. Funke. Alternative routes for nextgeneration traffic shaping. In
Proceedings of the 12thACM SIGSPATIAL International Workshop onComputational Transportation Science , 2019.[6] F. Barth, S. Funke, and S. Storandt. Alternativemulticriteria routes. In
Proceedings of theTwenty-First Workshop on Algorithm Engineering andExperiments, ALENEX 2019, San Diego, CA, USA,January 7-8, 2019 , pages 66–80, 2019.[7] Y. Chen, M. G. Bell, and K. Bogenberger. Reliablepretrip multipath planning and dynamic adaptationfor a centralized road navigation system.
IEEETransactions on Intelligent Transportation Systems ,2007.[8] T. Chondrogiannis, P. Bouros, J. Gamper, andU. Leser. Alternative routing: k-shortest paths withlimited overlap. In
SIGSPATIAL , 2015.[9] T. Chondrogiannis, P. Bouros, J. Gamper, U. Leser,and D. B. Blumenthal. Finding k-dissimilar paths withminimum collective length. In
SIGSPATIAL , 2018.[10] T. Chondrogiannis, P. Bouros, J. Gamper, U. Leser,and D. B. Blumenthal. Finding k-shortest paths withlimited overlap.
The VLDB Journal , pages 1–25, 2020.[11] A. H. Jones. Method of and apparatus for generatingroutes, Aug. 21 2012. US Patent 8,249,810.[12] H. Liu, C. Jin, B. Yang, and A. Zhou. Finding top-kshortest paths with diversity.
IEEE Transactions onKnowledge and Data Engineering , 2017.[13] D. Ouyang, L. Yuan, L. Qin, L. Chang, Y. Zhang, andX. Lin. Efficient shortest path index maintenance ondynamic road networks with theoretical guarantees.
Proceedings of the VLDB Endowment , 2020.[14] J. Y. Yen. Finding the k shortest loopless paths in anetwork. management Sciencemanagement Science