A ForceDirected Approach for Offline GPS Trajectory Map Matching
Abstract.
We present a novel algorithm to match GPS trajectories onto maps offline (in batch mode) using techniques borrowed from the field of forcedirected graph drawing. We consider a simulated physical system where each GPS trajectory is attracted or repelled by the underlying road network via electricallike forces. We let the system evolve under the action of these physical forces such that individual trajectories are attracted towards candidate roads to obtain a map matching path. Our approach has several advantages compared to traditional, routingbased, algorithms for map matching, including the ability to account for noise and to avoid large detours due to outliers in the data whilst taking into account the underlying topological restrictions (such as oneway roads). Our empirical evaluation using real GPS traces shows that our method produces better map matching results compared to alternative offline map matching algorithms on average, especially for routes in dense, urban areas.
1. Introduction
Map matching is the process of mapping a geospatial trajectory obtained from a GPS receiver onto a given road network. As the coordinates obtained from these devices are not always precise, in dense road networks the task of matching these onto a real map is not trivial. Several candidate roads may exist in close proximity and a map matching algorithm must ensure that the resulting path on the road network is plausible and that physical constraints (e.g., oneway streets, obstacles) are respected.
Map matching has been studied for over a decade (Quddus et al., 2007) and a large collection of algorithms exist with varying degrees of complexity and accuracy. Existing algorithms can be divided into two broad categories: i) online or realtime algorithms, where the algorithm has to determine the likely position on a map given the history of previous points, for example on a vehicle equipped with a GPS navigation device, and ii) offline algorithms, where the entire trajectory is known in advance and the algorithm has to adjust the trajectory points a posteriori such that they represent on a map the likely route taken by the vehicle.
The present article considers offline map matching. This problem has received less focus than its realtime counterpart as it is not useful for realtime navigation. However, in many applications, such as logistics and supply chain management, the analysis of vehicle trajectories is done a posteriori once the vehicles have returned to the depot, where a map matching algorithm is used to correct measurement errors by the GPS receivers and produce a trajectory that lies completely on a real map network. One of the main differences with the online case is the inclusion of the entire trajectory in the analysis, which provides additional information on the likely route taken.
We propose a novel approach which borrows methods from forcedirected graph design to direct the map matching strategy, improving on the existing map matching literature. The algorithms used in forcedirected graph design aim to produce an elegant visualization of a graph topology (vertices and edges) on a plane (Fruchterman and Reingold, 1991; Walshaw, 2001). To achieve this, each vertex is assumed to repel each other whilst each edge can expand or contract freely, and these forces are modeled using concepts from physics, such as electrical repulsion or spring forces. The system is then simulated on a computer where the edges and vertices are allowed to move according to physical laws and, after a number of iterations, a visually elegant layout of the graph is obtained. These approaches are presented in detail in Section 3.
In this article we use similar techniques to achieve high precision mapmatching results. The road network of the map is assumed to exert a force field and every vertex of the trajectory is attracted to the field in such a way that after a number of iterations the trajectory is closely matched to, or ‘snapped’, onto the road network. Using this approach, the force exerted is linked to the distance between the trajectory and the road, so the trajectory will be preferentially attracted to nearby roads and, in addition, the direction of the force is linked to the angle between the road and the trajectory, enabling oneway streets to be correctly represented (if a trajectory travels in the opposite way near a oneway road, it results in a repelling force and this road is avoided). These two features produce an effective map matching algorithm. To our knowledge this is the first method which uses forcedirected algorithms for map matching.
2. Related work on map matching methods
The aim of map matching is to convert, based on some known map data, a list of GPS points into a trajectory (series of roads or links) denoting the most likely route traveled by the vehicle or moving object. Over the past years, many map matching algorithms have been proposed in the literature, both for realtime and for offline map matching, which cover a number of different types of applications and input data. A comprehensive review of over 30 map matching algorithms can be found in (Quddus et al., 2007). The authors classify the analytical approaches used in the algorithms into ‘geometrical’, which use proximitybased methods, ‘topological’, which use the notions of connectivity between the links (oneway roads, connectivity and reachability information), ‘probabilistic’, which further use information about the quality or accuracy of the GPS signal (typically obtained from the GPS sensor), and ‘advanced’, which use more specific methods such as Kalman filters, hidden Markov chains, timing information (e.g., to predict the exiting from a tunnel) and other applicationspecific approximation techniques. Typically the underlying map network is known, however some researchers (Buchin et al., 2017; Li et al., 2016; Wang et al., 2015; Mao et al., 2012) have developed approximation techniques to generate an unknown underlying map or to perform map matching without reference to a known map topology by observing the clustering of trajectories.
Recently, improvements on these methods have been proposed, such as an efficient buffer topological algorithm to detect bicycle paths in Bologna (Schweizer et al., 2016), or a scorebased matching for car trajectories in Zurich (Marchal et al., 2005). The ACM SIGSPATIAL 2012 competition (Ali et al., 2012; Liu et al., 2012; Levin et al., 2012; Song et al., 2012; Tang et al., 2012; Torre et al., 2012; Wei et al., 2012) requested participants to determine a fast map matching algorithm for use in realtime systems; the focus of the competition was on algorithm speed since the competition used only ten vehicle trajectories and the provided instances were relatively easy to solve (good quality GPS points on a not very dense road network). The authors of (Lin et al., 2016) use a geometric distance measure to determine the nearby roads and then apply a Dijkstrabased algorithm to select those roads which satisfy the topological restrictions of the map. In a different direction, (Li et al., 2013) select their road segments using an optimization method which takes advantage of cases where many users drove along a similar route, similar to trajectory clustering methods.
More complex approaches can also be found in the literature, the most noteworthy of which is the votingbased map matching algorithm (Yuan et al., 2010) where the most likely path is determined by the relative mutual influence between pairs of points, taking into account at the same time the temporal information (timestamps) of the GPS points.
Among the probabilistic approaches, a method proposed in (Bierlaire et al., 2013) ranks all topologically possible trajectories based on a calculated probability, which is a generalization of earlier hidden Markov chain or Viterbi map matching methods. This approach is extended in (Osogami and Raymond, 2013) where the number of turns in the resulting trajectory is taken into consideration and optimized using inverse reinforced learning. A similar comprehensive search method is used in (Wu et al., 2007) where a heuristic search algorithm is used to find and score each possible trajectory, and in (Wang and Zimmermann, 2014) for realtime map matching.
Another interesting approach is the one presented in (Silva et al., 2015), where the authors do not really perform mapmatching but aim to ‘correct’ GPS trajectories by interpolation so that the resulting traces are closer to the real route taken, using a clustering algorithm which compares trajectories between them. This concept is similar to our proposed forcedirected algorithm where we also ‘correct’ the raw GPS points, but we do so by considering the interaction of a particular trajectory with the underlying road network instead of comparing trajectories between them.
The most commonly used approaches for map matching which combine both ‘geometrical’ and ‘topological’ methods are routingbased methods. This means that the map matching problem is converted into a routing problem, where in its simplest version the trajectory is divided in smaller segments, the endpoints of which are then matched onto a road (for example, moving each endpoint to the nearest point on the road), and the intermediate points of the segment are replaced by a routing calculation of the shortest possible route from one endpoint to the other, taking into account the road layout. This approach produces good results as it ensures that the produced route is close to the original points and that the route will be plausible, in the sense that it is guaranteed to lie on an existing road and all the topological restrictions will be satisfied. The most popular implementations of routebased algorithms for map matching are GraphHopper (Graphhopper, 2017), and MapBox (MapBox, 2017) both of which use shortestdistance routing directed by weights derived from the GPS trajectory to find a match.
However, routing based methods are not foolproof. They operate under the assumption that the driver who produced the GPS trace was driving on a shortestdistance fashion between periodicallysampled segments of the route, so short, circular loops within each segment (taken for example by taxis) will not be matched correctly.
Our proposed method takes these routingbased methods one step further, adding an element of the ‘probabilistic’ map matching techniques: we use a forcedirected algorithm to adjust, or correct, the obtained raw GPS points before applying a routingbased method, resulting in a more accurate match.
3. Complexity and evaluation of map matching algorithms
The nature of the map matching problem presents some unique challenges. First of all, the difficulty of the task can vary significantly: if the trajectories obtained correspond to a rural setting (e.g., on an isolated highway) the task can be very easy or trivial, as there may only be one possible candidate road for the path taken. Conversely in a city center setting, the challenge is much harder as the road network is more dense. Similarly, the frequency of sampling of the GPS points is important, as recording one point every second will make map matching easier than, say, recording every minute. Finally, the quality of the GPS signal, the GPS receiver used and the underlying map are also important as a good quality trajectory will result in points that are closer to coordinates of the real road, making the task much easier.
Although the density of the underlying map is a key factor in terms of determining the difficulty of the map matching problem and therefore the performance of a map matching algorithm, other elements that influence this are the quality of the GPS data and the mode of transport, which determines the speed of the vehicle. Bicycle and pedestrian trajectories are easier to match for a given sampling frequency as the object does not move much between successive GPS points.
In terms of the underlying fixed road network map, which is necessary for most map matching algorithms, researchers tend to use data from the freely available OpenStreetMap service (OpenStreetMap, 2017), which has a good coverage of road networks for most cities around the world.
In order to evaluate the performance of map matching algorithms, the obvious step is to compare the produced trajectory with the ‘ground truth’, i.e., the actual trajectory taken by the vehicle. However, this approach can only be used in limited circumstances, as the ground truth is typically not available in most cases of large scale data collections (as it requires navigating along a predefined route or significant manual input to record the precise route taken). Some researchers derive the ground truth by manually matching some trajectories by sight, for example in (Li et al., 2013) experienced human drivers were asked to trace, based on their experience, the ‘ground truth’ of a random subset of 100 trajectories among their dataset of Beijing taxi traces. Other researchers (White et al., 2000) create their own datasets by driving along a very small number of predefined routes (four). These approaches have many drawbacks, namely the fact that the chosen routes are defined in advance by the researchers, that human discretion is required to ascertain the route taken and that a large number of trajectories cannot be matched by hand.
In order to mitigate these limitations and use trajectories for which no ground truth exists, some authors (Lin et al., 2016; Marchal et al., 2005; Quddus et al., 2005) propose distancebased metrics based on minimizing the distance between the GPS trajectory and the route produced by the algorithm. This suggests that map matches that are close to the original points are considered to be more accurate than those which are farther away. Some alternatives for the evaluation of map matching algorithms in the absence of ground truth include the comparison of the length of the original trajectory compared the the length of the matched route (Schweizer et al., 2016). Finally, an interesting approach (Quddus et al., 2005), although with limited practical use, is to collect two sets of GPS data, one of low quality used as the input trace and a second trace of high quality data used as a proxy for the ground truth.
4. Forcedirected graph drawing methods
Graph visualization is a wellresearched field, as graph structures appear in many areas and graph drawing on a 2dimensional plane quickly becomes challenging as the size of the graph increases. Recently, a number of approaches in this area have focused on ‘forcedirected’ methods which can automatically ‘draw’ large graphs on a plane (Kamada and Kawai, 1989; Fruchterman and Reingold, 1991; Sugiyama and Misue, 1995; Walshaw, 2001; Harel and Koren, 2002; Hachul and Jünger, 2007). A comprehensive overview of such algorithms is presented in (Kobourov, 2013) and some interesting, more recent variations appear in (Hu, 2006; Holten and van Wijk, 2009; Lin and Yen, 2012). In these methods, a directed or undirected graph is modeled as a system of particles with forces acting between them and a compelling visual result is achieved when the particles are placed in such a way as to achieve a force equilibrium.
An example of the input and output of a forcedirected graph drawing algorithm from (Fruchterman and Reingold, 1991) is shown in Figure 1. One can see how the forces between the edges in 2dimensions force the graph to spread out into a symmetrical equivalent representation.
In general, all forcedirected graph drawing algorithms consider repelling forces between nonadjacent vertices that are inversely proportional to the distance between the vertices (), or to the square of the distance () in order to reduce the strength of the force between distant vertices and yield a faster convergence. The edges are modeled as spring forces that can both expand and contract around an ‘ideal’ length, although pure spring forces (proportional to the displacement of the spring) are considered too strong and are usually replaced by the logarithm of the displacement (, where is the desired ‘ideal’ length between vertices (often defined as the square root of the total drawing area divided by the number of vertices to ensure an even spread on the drawing area).
As the computational simulation of a system of particles under the laws of physics is computationally intensive, an approximation is always used, where the force applied to each vertex is calculated in turn, and then the vertex is displaced by a small amount in the direction of the combined net force before the process iterates. Other refinements that have been proposed in the literature include modified force formulas, computation of various parameters based on some further graph characteristics (e.g., the diameter of the graph) and the introduction of a cooling coefficient (based on the field of simulated annealing in optimization) where the displacement of the vertices gradually becomes smaller to ensure that once a good configuration is found no major modifications to the layout occur.
In the next section we present an algorithm that uses the techniques of forcedirected graph drawing outlined in this section to perform a map matching of GPS trajectories onto a map.
5. A forcedirected map matching algorithm
We consider GPS trajectories defined by points where a point is defined by its position in space and time . We do not use information about the quality of the signal or receiver (accuracy and precision of the GPS receiver) as this is typically not included in many GPS production systems. The fixed road network or map is represented by a directed graph of intersection points and straight line segments (links) between them, which are obtained from the publicdomain mapping provider OpenStreetMap (OpenStreetMap, 2017).
The key idea of forcedirected map matching is to consider an ‘electrical current’ that passes through each edge of the road network and results in an attractive or repulsive force on each point of a given trajectory. We set the magnitude of this force as follows:

inversely proportional to the distance between the point and the road edge ,

proportional to the cosine of the angle between the road edge and the trajectory at ,

proportional to the length of .
We explain the rationale behind each choice in turn: the first point specifies that trajectory points should be attracted more strongly by nearby roads, which is sensible. The second point relates the force to the angle between the trajectory and the road. The force should be at its maximum when the trajectory and the road are parallel to each other, it should reduce to zero when the two are perpendicular to each other and then become negative (repulsive) when the trajectory and the road point in opposite directions. The last requirement is necessary as the edges in the underlying road network are not of equal length. Without this constraint, if a road on the map was split into two edges, it would result in doubling the force on point . Adjusting for the length of each edge avoids the trajectory being pulled towards areas with high road density (many small roads).
The direction of the force is taken to be either: (i) perpendicularly towards the edge or (ii) towards the midpoint of the edge . Note that unlike graph drawing algorithms, no forces are operating between individual vertices except for neighboring vertices as described below.
We also assume that spring forces apply on each edge of a given trajectory. These were set at the same standard logdistance formula as used in graph drawing:
where are constants and is the length of the spring. We have set the natural length to be equal to the length of the trajectory segment as we assume that the distance between points on the true trajectory will be similar to the observed distance. The forces between the points can be attractive or repulsive and are applied in the direction of the edge .
Once all the forces are calculated for each point , each point is moved in turn by a distance proportional to the net force
The key parameters of our algorithm are summarized in Table 1. We experimented with variations of the distance and force formulas as suggested in the forcedirected graph drawing literature until we found an ideal combination for the strengths of the electrical and spring forces. The values that we used for the final algorithm are denoted by a star ‘*’ in the table. Regarding our choices, we can comment that an electrical force proportional to the road edge length is too strong for quick convergence and replaced it with . Furthermore, the repulsive forces when the road and trajectory are pointing in opposite directions had to be significantly reduced to ensure that the trajectory is still attracted to nearby roads with the correct orientation. We also note that because of the sharp decrease in the magnitude of the electrical forces with the distance as well as for computational efficiency, we only include edges which are within 100 meters from the current point in the calculation of the electrical forces.
variable  selection used  alternatives tested 
(i) perpendicular distance from to line defined by edge  
*  (ii) distance from to segment ():  
– perpendicular distance, if projection of lines inside segment  
– minimum distance to endpoint of , otherwise  
(iii) distance of to midpoint of  
*  (i) ,  
(ii) , (average of cosines)  
(iii) (cosine of average)  
edge  *  (i) if replace with 
repulsion  (ii) if replace with  
(iii) if replace with  
force  *  (i) perpendicular from towards the edge 
direction  (ii) direction from towards the midpoint of  
force  *  
value  
* 
A pseudocode of our forcedirected algorithm is given in Figure 2. Once the trajectory is read, we use the forcedirected method to attract the trajectory points towards the roads on the map. After a number of iterations, the trajectory will be close to a plausible map match. As a final step in order to convert the points into road segments, it is necessary to apply an algorithm to place the obtained points exactly on a map road. This algorithm can simply be to place each point to the nearest road segment that has the correct alignment (in the case of oneway roads), or alternatively, it could be an implementation of a traditional routebased algorithm. In our implementation and numerical experimentation we chose the latter method for a number of reasons that are explained in the following section.
6. Experimental evaluation
This section presents the results of an experimental evaluation of our forcedirected map matching algorithm applied on a large number of GPS trajectories where we compare its performance with other stateofthe art map matching algorithms. We consider a large dataset of taxi trajectories created in 2014 in Rome (Bracciale et al., 2014). This data consists of timestamped latitude/longitude data corresponding to nearly 500,000 km of driving carried out by taxi drivers equipped with a GPS tracking device on a tablet computer.
We chose this dataset for specific reasons: The road network in Rome is very dense, not gridlike with many short and irregularly shaped roads, many obstacles and oneway streets. (The average road segment length in our Rome map data was 29 meters.) This means that the map matching problem on this layout is more complex than a similar problem on city with a grid layout and large blocks. Moreover, this dataset records a trajectory as one GPS point every 15 seconds (so pretty infrequently) which increases the trajectory ambiguity, and the need for a proper trajectory correction.
In line with most articles in the literature, we obtained the underlying map road network for Rome from OpenStreetMap (OpenStreetMap, 2017) and filtered the road network to include only roads that are open to car traffic. The road network (corresponding to the assumed force field passing through each road segment) that was obtained is shown in Figure 3, while Figure 4 shows the distribution of the length of the road segments in the same area.
In the implementation of our forcedirected algorithm, we used the same routebased algorithm as Graphhopper for the last step to convert the final positions of the modified points into road segments. This choice was made for three reasons: first, we had to produce a path that can be correctly identified using its underlying OpenStreetMap name in order to compare it to the map matching produced by the routingbased algorithm; using the Graphhopper tool to do so is the obvious solution. Secondly, using Graphhopper as the last step in our method also demonstrates the superiority of our method compared to routebased methods, since if we produce a better map matching result this cannot be due to particularities or limitations in the Graphhopper implementation, as these would be present in our results too. The third reason was a practical one: with this step in place we do not need to wait until the forcedirected algorithm converges (sometimes slowly, depending on the choice of the algorithm parameters) towards the final matched path; instead we can terminate our algorithm after a number of iterations when a good enough approximate match is found, and then postprocess this result to obtain a feasible path. In other words, we compare the difference of performing a map match by a routing algorithm (such as Graphhopper) directly on the input data, against performing the same algorithm on data points that have been first displaced towards specific roads by our forcedirected algorithm.
The GPS data was cleaned and divided into distinct trajectories in the same way as the authors in (Bracciale et al., 2014): when an anomaly is detected (defined as a speed of over 50 km/h), we look at the total duration of the anomaly. For anomalies under 42 sec we simply delete the incorrect GPS points; for anomalies between 42 sec and 8 min we delete the points and replace with intermediate points based on linear interpolation; for anomalies over 8 min or consecutive points over 8 min apart we assume that this is due to a break implying the end of a trajectory and the start of a new one. We further removed trajectories with fewer than 10 points or totaling less than 8 mins as they are too short for useful map matching. Finally, we also excluded a small number of trajectories which lie outside our chosen reference grid of latitude (41.8001, 41.9859) and longitude (12.382189, 12.608782). This approach resulted in a total of 18,111 trajectories containing over 16 million points (1.3GB data) and a total distance of 467,875 km in 37,517 hours.
In line with (Schweizer et al., 2016) we also excluded from the comparative evaluation trajectories totaling less than 300 meters in length and those for which the length index (defined in (Schweizer et al., 2016) as the ratio of the total length of the calculated trajectory divided by the total length of the original trajectory) is outside of the range . Our investigation showed that a large difference in trajectory length is due to undocumented particularities of the map network, for example around the touristic Piazza di Spagna area which in reality can be driven through by taxis but which is recorded on the map we used as a pedestrianonly area forcing any mapmatching algorithm to take a long detour. Removing these trajectories resulted in a total of 11,154 trajectories, containing 7.1 million points and a total distance of 199,398 km driven over 16,753 hours. Figure 5 shows a histogram of the distribution of the lengths of the trajectories used in this analysis.
The implementation of our algorithm was done in Java on a machine with 16GB of RAM and four CPU cores. We compared our algorithm to the popular routingbased map matching algorithm Graphhopper.
An example of the algorithm output is shown in Figure 6. The original data is shown in blue and the routingbased map match is shown in purple. When we carry out the forcedirected map matching algorithm the trajectory is modified to the green trajectory and the resulting mapmatch is shown in black. It is quite evident that, even using one iteration, the forcedirected algorithm produces a better matching route.
A second example depicting a trajectory with a loop is shown in Figure 7. We note that the routingbased map matching algorithm fails to detect the apparent loop in the trajectory, which is successfully identified once the trajectory points are modified under our forcedirected algorithm.
7. Results and discussion
In order to evaluate the results of the proposed map matching algorithm, we used two metrics found in the literature for the comparative evaluation of map matching algorithms in the absence of the ground truth. It is worth noting that all evaluation metrics without ground truth will have some limitations since there is no foolproof method of comparing a map match produced by one algorithm with one produced by another algorithm. Nonetheless, these metrics measure elements that can be reasonable deemed to feature in bad matches, such as the path being too far away or its length being too different to the original trajectory, and therefore can be used to assess the quality of map matching.
We first used the method proposed by (Schweizer et al., 2016) to evaluate map matches for bicycle paths in Bologna: we calculate the length index , which is defined by dividing the length of the matched route by the lineinterpolated length of the GPS trace:
and assume that the closer this index is to 1 the better the match. In other words, it is assumed that a good map matching algorithm will produce a path with length similar to the length obtained from the GPS points. Although this is not necessarily true, it provides a good approximation by penalizing algorithms which produce paths are too short or too long for the trajectory, for example paths containing a lot of detours or that omit loops of the trajectory.
The results of using this metric are shown in Table 2. We note that the forcedirected algorithm results in an index which is closer to 1 and therefore produces a better match than the routebased map matching method. A distribution of the index according to the length of the original trajectory and the number of points in the trajectory are shown in Figure 8 and Figure 9 respectively. We can observe that the forcedirected algorithm performs consistently better, except for very short trajectories. There is little difference in the distribution of the length index according to the number of iterations used in the algorithm.
routebased  forcedirected algorithm, # of iterations  

algorithm  1  5  10  15  20  
Method 1: Length index  1.114  1.113  1.096  1.084  1.079  1.079 
Method 2: Avg. error (meters)  18.34  18.29  15.34  14.50  14.25  14.21 
Computational time (sec)  0.22  1.03  4.10  7.04  8.80  13.52 
The second evaluation metric used is linked to the average absolute error of the calculated path compared to the original GPS points. This method has been used in (Marchal et al., 2005). For each GPS point of the original trajectory we define its distance to the matched path as the minimum of the distances of the point to the line segment of the matched path. The distance of a point to the segment is defined as the perpendicular distance if the projection of the point to the line segment lies between the endpoints of the segment, otherwise it is defined as the minimum distance to the endpoints:
where is the projection of on the line . The average error is then defined as the average distance of each GPS point to the matched path:
In other words, the average error can be considered as the average, along the trajectory, transverse distance between the trajectory and the matched route and a smaller error denotes a better match.
The results using this method are shown in Table 2 and the distribution of this metric by the length and the number of points of the trajectory are shown in Figure 10 and Figure 11. We note that the forcedirected algorithm also produces better results using this evaluation method than traditional map matching, and the performance improves as the number of iterations of the forcedirected algorithm increases. This trend continues until approximately 20 iterations, when the average error stabilizes and remains around 23% better than routingbased method on average. This suggests that a longer running time of the forcedirected algorithm does not produce better results, and only a small number of iterations is needed to perturb the trajectory points sufficiently for a good, potentially optimal, match to be found.
It is also worth noting that in 12% of the trajectories both algorithms produced the same matching path, reflecting our observation that for several trajectories there can only be one or very few plausible routes and the task of finding a map match is easier.
In terms of computational time, Table 2 and Figure 12 show the average computational time taken by each of the two algorithms, measured in seconds of elapsed clock time. We note that while the routing based algorithm is able to transform one GPS trajectory into a sequence of roads in less than one second, the forcedirected one takes significantly more time, on average 13.52 seconds and up to 17 seconds for the trajectories over 30km. This is because of the large number of interactions that have to be taken into account during the calculation of the forces between the trajectory and the road network. The computational time of the forcedirected algorithm increases linearly with the number of points in the trajectory. The slight decrease in computational time for trajectories over 30km long is due to the small number of trajectories in this range and to the fact that many of these trajectories were on fast motorways, resulting in fewer GPS points than was typical for their length.
The increase in computational time to under 20 seconds per trajectory poses no practical limitations, since the algorithm is designed for offline processing of trajectories and is an acceptable price to pay if it results in more accurate road matches.
Under the two evaluation metrics considered the proposed algorithm performs better in terms of the quality of the produced path than the baseline routingbased map matching algorithm, at the expense of increased computational time, although as mentioned earlier, all evaluation metrics have limitations in in the absence of ground truth data.
8. Conclusions and future work
This paper presented a novel algorithm that can be used to match trajectories obtained from GPS receivers onto a known map network. The algorithm borrows techniques used in forcedirected graph drawing in order to incrementally perturb the trajectory and make it converge onto a good, likely path whilst at the same time ensuring that topological limitations such as oneway streets are satisfied. The interactions between the trajectory points and the underlying road network are modeled by a physical system evolving under the influence of physicallike forces which were described in detail in this work.
Numerical experimentation using real trajectories in a dense, urban road network demonstrates that the proposed method produces better map matching paths than routingbased map matching alone, providing a framework for the use of forcedirected algorithms in related domains such map construction through the clustering of multiple related trajectories and realtime map matching.
The future work in this direction includes the evaluation of the algorithm using new data, including datasets which contain the ground truth, and the development of more reliable metrics of evaluation, for example using a version of the Fréchet distance which can better measure the similarity of spatiotemporal trajectories. We are also working to further explore the optimal values of the parameters of the algorithm, such as the optimal number of iterations. Equally, a comparison of the performance of the proposed approach with other relevant implementations, in particular (Yuan et al., 2010; Bierlaire et al., 2013; Osogami and Raymond, 2013; Wei et al., 2012) and commercial software (MapBox, 2017), is under investigation. The performance of the algorithm in difficult constellations and uncommon layouts, such as flyovers or roads separated vertically and multilane matching (which are very uncommon in the Rome dataset used for this paper) remains to be evaluated. Finally, the use of the GPS temporal information (timestamps) to determine some of the parameters of the algorithm has the potential to further improve the accuracy in the case of sparse data.
References
 (1)
 Ali et al. (2012) Mohamed Ali, John Krumm, Travis Rautman, and Ankur Teredesai. 2012. ACM SIGSPATIAL GIS Cup 2012. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 597–600. https://doi.org/10.1145/2424321.2424426
 Bierlaire et al. (2013) Michel Bierlaire, Jingmin Chen, and Jeffrey Newman. 2013. A probabilistic map matching method for smartphone GPS data. Transportation Research Part C: Emerging Technologies 26 (2013), 78–98. https://doi.org/10.1016/j.trc.2012.08.001
 Bracciale et al. (2014) Lorenzo Bracciale, Marco Bonola, Pierpaolo Loreti, Giuseppe Bianchi, Raul Amici, and Antonello Rabuffi. 2014. CRAWDAD dataset roma/taxi (v. 20140717). Downloaded from http://crawdad.org/roma/taxi/20140717.
 Buchin et al. (2017) Kevin Buchin, Maike Buchin, David Duran, Brittany Terese Fasy, Roel Jacobs, Vera Sacristan, Rodrigo I. Silveira, Frank Staals, and Carola Wenk. 2017. Clustering Trajectories for Map Construction. In Proceedings of the 25th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (SIGSPATIAL’17). ACM, New York, NY, USA, Article 14, 10 pages. https://doi.org/10.1145/3139958.3139964
 Fruchterman and Reingold (1991) Thomas M. J. Fruchterman and Edward M. Reingold. 1991. Graph drawing by forcedirected placement. Software: Practice and Experience 21, 11 (1991), 1129–1164. https://doi.org/10.1002/spe.4380211102
 Graphhopper (2017) Graphhopper. 2017. Mapmatching based on graphhopper. https://github.com/graphhopper/mapmatching
 Hachul and Jünger (2007) Stefan Hachul and Michael Jünger. 2007. Largegraph layout algorithms at work: an experimental study. Journal of Graph Algorithms and Applications 11, 2 (2007), 345–369.
 Harel and Koren (2002) David Harel and Yehuda Koren. 2002. A fast multiscale method for drawing large graphs. Journal of Graph Algorithms and Applications 6, 3 (2002), 179–202.
 Holten and van Wijk (2009) Danny Holten and Jarke J. van Wijk. 2009. Forcedirected Edge Bundling for Graph Visualization. In Proceedings of the 11th Eurographics / IEEE  VGTC Conference on Visualization (EuroVis’09). The Eurographs Association & John Wiley & Sons, Ltd., Chichester, UK, 983–998. https://doi.org/10.1111/j.14678659.2009.01450.x
 Hu (2006) Yifan Hu. 2006. Efficient, HighQuality ForceDirected Graph Drawing. The Mathematica Journal 10, 1 (2006), 37–71.
 Kamada and Kawai (1989) Tomihisa Kamada and Satoru Kawai. 1989. An algorithm for drawing general undirected graphs. Inform. Process. Lett. 31, 1 (1989), 7–15. https://doi.org/10.1016/00200190(89)901026
 Kobourov (2013) Stephen G. Kobourov. 2013. Forcedirected graph algorithms. In Handbook of Graph Drawing and Visualization, Roberto Tamassia (Ed.). Chapman & Hall/CRC, Boca Raton, FL, USA, Chapter 12, 383–408.
 Levin et al. (2012) Roy Levin, Elad Kravi, and Yaron Kanza. 2012. Concurrent and Robust Topological Map Matching. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 617–620. https://doi.org/10.1145/2424321.2424431
 Li et al. (2013) Yang Li, Qixing Huang, Michael Kerber, Lin Zhang, and Leonidas Guibas. 2013. Largescale Joint Map Matching of GPS Traces. In Proceedings of the 21st ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (SIGSPATIAL’13). ACM, New York, NY, USA, 214–223. https://doi.org/10.1145/2525314.2525333
 Li et al. (2016) Yang Li, Yangyan Li, Dimitrios Gunopulos, and Leonidas Guibas. 2016. Knowledgebased Trajectory Completion from Sparse GPS Samples. In Proceedings of the 24th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (GIS ’16). ACM, New York, NY, USA, Article 33, 10 pages. https://doi.org/10.1145/2996913.2996924
 Lin and Yen (2012) ChunCheng Lin and HsuChun Yen. 2012. A new forcedirected graph drawing method based on edgeedge repulsion. Journal of Visual Languages and Computing 23 (2012), 29–42. https://doi.org/10.1016/j.jvlc.2011.12.001
 Lin et al. (2016) Mick ChangHeng Lin, FuMing Huang, PoChing Liu, YuHsiang Huang, and Youshan Chung. 2016. DijkstraBased Selection for Parallel Multilanes MapMatching and an Actual Path Tagging System. In Intelligent Information and Database Systems, Ngoc Thanh Nguyen, Bogdan Trawiński, Hamido Fujita, and TzungPei Hong (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 499–508. https://doi.org/10.1007/9783662493908_49
 Liu et al. (2012) Kuien Liu, Yaguang Li, Fengcheng He, Jiajie Xu, and Zhiming Ding. 2012. Effective Mapmatching on the Most Simplified Road Network. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 609–612. https://doi.org/10.1145/2424321.2424429
 Mao et al. (2012) Huajian Mao, Wuman Luo, Haoyu Tan, Lionel M. Ni, and Nong Xiao. 2012. Exploration of Ground Truth from Raw GPS Data. In Proceedings of the ACM SIGKDD International Workshop on Urban Computing (UrbComp ’12). ACM, New York, NY, USA, 118–125. https://doi.org/10.1145/2346496.2346515
 MapBox (2017) MapBox. 2017. https://www.mapbox.com
 Marchal et al. (2005) Fabrice Marchal, J. Hackney, and Kay W. Axhausen. 2005. Efficient mapmatching of large Global Positioning System data sets: Tests on a speedmonitoring experiment in Zürich. Transportation Research Record: Journal of the Transportation Research Board 1935 (2005), 93–100. https://doi.org/10.3141/193511
 OpenStreetMap (2017) OpenStreetMap. 2017. https://www.openstreetmap.org
 Osogami and Raymond (2013) Takayuki Osogami and Rudy Raymond. 2013. Map Matching with Inverse Reinforcement Learning. In Proceedings of the TwentyThird International Joint Conference on Artificial Intelligence (IJCAI ’13). AAAI Press, Beijing, China, 2547–2553. http://dl.acm.org/citation.cfm?id=2540128.2540495
 Quddus et al. (2005) Mohammed A. Quddus, Robert B. Noland, and Washington Y. Ochieng. 2005. Validation of map matching algorithms using highprecision positioning with GPS. Journal of Naviagation 58, 2 (2005), 257–271. https://doi.org/10.1017/S0373463305003231
 Quddus et al. (2007) Mohammed A. Quddus, Washington Y. Ochieng, and Robert B. Noland. 2007. Current mapmatching algorithms for transport telematics applications: Stateoftheart and future research directions. Transportation Research Part C: Emerging Technologies 15, 5 (2007), 312–328. https://doi.org/10.1016/j.trc.2007.05.002
 Schweizer et al. (2016) Joerg Schweizer, Silvia Bernardi, and Federico Rupi. 2016. Mapmatching algorithm applied to bicycle global positioning system traces in Bologna. IET Intelligent Transport Systems 10, 4 (2016), 244–250. https://doi.org/10.1049/ietits.2015.0135
 Silva et al. (2015) Fabrício A. Silva, Clayson Celes, Azzedine Boukerche, Linnyer B. Ruiz, and Antonio A.F. Loureiro. 2015. Filling the Gaps of Vehicular Mobility Traces. In Proceedings of the 18th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM ’15). ACM, New York, NY, USA, 47–54. https://doi.org/10.1145/2811587.2811612
 Song et al. (2012) Renchu Song, Wei Lu, Weiwei Sun, Yan Huang, and Chunan Chen. 2012. Quick Map Matching Using Multicore CPUs. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 605–608. https://doi.org/10.1145/2424321.2424428
 Sugiyama and Misue (1995) Kozo Sugiyama and Kazuo Misue. 1995. Graph drawing by the magnetic spring model. Journal of Visual Languages and Computing 6, 3 (1995), 217–231. https://doi.org/10.1006/jvlc.1995.1013
 Tang et al. (2012) Youze Tang, Andy Diwen Zhu, and Xiaokui Xiao. 2012. An Efficient Algorithm for Mapping Vehicle Trajectories Onto Road Networks. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 601–604. https://doi.org/10.1145/2424321.2424427
 Torre et al. (2012) Fernando Torre, David Pitchford, Phil Brown, and Loren Terveen. 2012. Matching GPS Traces to (Possibly) Incomplete Map Data: Bridging Map Building and Map Matching. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 546–549. https://doi.org/10.1145/2424321.2424411
 Walshaw (2001) Chris Walshaw. 2001. A Multilevel Algorithm for ForceDirected Graph Drawing. In Graph Drawing, Joe Marks (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 171–182.
 Wang and Zimmermann (2014) Guanfeng Wang and Roger Zimmermann. 2014. Eddy: An Errorbounded Delaybounded Realtime Map Matching Algorithm Using HMM and Online Viterbi Decoder. In Proceedings of the 22nd ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’14). ACM, New York, NY, USA, 33–42. https://doi.org/10.1145/2666310.2666383
 Wang et al. (2015) Suyi Wang, Yusu Wang, and Yanjie Li. 2015. Efficient Map Reconstruction and Augmentation via Topological Methods. In Proceedings of the 23rd SIGSPATIAL International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’15). ACM, New York, NY, USA, Article 25, 10 pages. https://doi.org/10.1145/2820783.2820833
 Wei et al. (2012) Hong Wei, Yin Wang, George Forman, Yanmin Zhu, and Haibing Guan. 2012. Fast Viterbi Map Matching with Tunable Weight Functions. In Proceedings of the 20th International Conference on Advances in Geographic Information Systems (SIGSPATIAL ’12). ACM, New York, NY, USA, 613–616. https://doi.org/10.1145/2424321.2424430
 White et al. (2000) Christopher E. White, David Bernstein, and Alain L. Kornhauser. 2000. Some map matching algorithms for personal naviation assistants. Transportation Research Part C: Emerging Technologies 8, 1 (2000), 91–108. https://doi.org/10.1016/S0968090X(00)000267
 Wu et al. (2007) Dongdong Wu, Tongyu Zhu, Weifeng Lv, and Xin Gao. 2007. A Heuristic MapMatching Algorithm by Using VectorBased Recognition. In 2007 International MultiConference on Computing in the Global Information Technology (ICCGI ’07). IEEE, Guadeloupe City, Guadeloupe, 18–18. https://doi.org/10.1109/ICCGI.2007.3
 Yuan et al. (2010) Jing Yuan, Yu Zheng, Chengyang Zhang, Xing Xie, and GuangZhong Sun. 2010. An InteractiveVoting Based Map Matching Algorithm. In 2010 Eleventh International Conference on Mobile Data Management. IEEE, Kansas City, MO, USA, 43–52. https://doi.org/10.1109/MDM.2010.14