What is Map Matching? GPS Traces, Methods and Examples

Map matching takes the positions a vehicle's GPS (Global Positioning System) receiver recorded and finds the roads it drove on. The result is one connected path on a road network, with each GPS record placed on a road.

The simplest way to do this is to move each GPS record to its nearest road. That works when the GPS position is close to the road. It fails where the error is larger than the gap between two roads.

We tested this on one week of drives in Ann Arbor, Michigan: 199,249 GPS records, matched two ways. The first way moved each record to its nearest road. The second used hidden Markov model (HMM) map matching, which scores whole chains of connected roads and keeps the most likely route.

Where a record was within 5 m of the matched road, the methods disagreed on 5.1% of records. At 20 to 50 m, they disagreed on 54.2%. Many disagreements put a moving car on a driveway or parking aisle next to the main road.

For moving vehicles, use HMM map matching. In 12,968 records, nearest-road snapping put the car on a driveway, parking aisle or other service road where the HMM put it on the main road. 56.6% of those records were moving at 40 km/h or more, a speed that fits the main road.

Nearest-road snapping gives nearly the same answer only when GPS error is small: within 5 m of the road, the two methods agreed on 94.9% of records. The test had no record of the true route, so it shows where the methods differ and which result the recorded speed supports. It does not give an error rate for either method.

Key takeaways

• Map matching turns a GPS trace into a path on a road network. Every GPS record gets a road and a position on that road.
• Nearest-road snapping handles one record at a time. Hidden Markov model (HMM) map matching scores whole chains of candidate roads, so the result is a connected route.
• On 199,249 Ann Arbor GPS records, the two methods placed 16.4% of records on different roads. 771 of 833 trips had at least one such record.
• Disagreement grows with GPS error. It was 5.1% for records within 5 m of the matched road and 54.2% for records 20 to 50 m away.
• Disagreement was higher within 25 m of a junction (22.5%) than elsewhere (8.6%).
• Walking and cycling need their own network. In Ann Arbor, 57% of sidewalk segments and 66% of cycleway segments run within 15 m of a car road. At that distance, GPS error can put a record on the wrong one.
• In 12,968 disagreements, nearest-road snapping returned a service road and the HMM returned a main road. The reverse happened 405 times. 56.6% of those 12,968 records were moving at 40 km/h or more, a speed that does not fit a driveway or parking aisle.

What is map matching?

Mohammed Quddus, Washington Ochieng and Robert Noland define map-matching algorithms in Current map-matching algorithms for transport applications (Transportation Research Part C, 2007). In their words, these algorithms "integrate positioning data with spatial road network data (roadway centrelines)." Their purpose is "to identify the correct link on which a vehicle is travelling and to determine the location of a vehicle on a link." A link is one stretch of road between two junctions. A centreline is the line drawn down the middle of a road.

Two inputs go in:

• A GPS trace. This is the list of positions a device recorded during one trip, in time order. Each record usually has a time, a latitude and a longitude.
• A road network. This is a set of road lines plus the points where they connect. The connections let a method check whether a car can drive from one road to the next.

One output comes out: a path along the road network, with each GPS record placed on one road.

Map matching is needed because GPS positions are noisy. Pingfu Chao, Yehong Xu, Wen Hua and Xiaofang Zhou list the two main error sources in A Survey on Map-Matching Algorithms (arXiv, 2019). The first is measurement error, where a recorded position lies some distance from the true one. The second is sampling error, which grows as the time between GPS records gets longer. A noisy GPS record can sit beside the road, in a parking lot, or closer to a road the car never used.

Map matching is one step in geospatial analysis of vehicle data. Its output becomes the input for distance per road, speed per road and route counts.

How map matching works

Quddus and his co-authors grouped methods published before 2007 into four kinds: geometric, topological, probabilistic and advanced. Chao and his co-authors summarize the groups.

Geometric methods use only the distance between GPS records and roads. Topological methods also use how roads connect and their shapes. Probabilistic methods model GPS error and search for the path most likely to have produced the trace. Advanced methods use tools such as Kalman filters, particle filters and fuzzy logic.

Nearest-road snapping (point-to-curve)

The oldest geometric method is point-to-curve matching. In the words of the Chao survey, it "projects each trajectory point to the geometric-closest edge." An edge is one road piece between two connections. This method needs only a distance calculation, so it is fast and easy to run in Structured Query Language (SQL), the standard language for querying databases.

It ignores order and connections. Two GPS records one second apart can land on roads with no link between them.

Curve-to-curve matching

Curve-to-curve methods compare a piece of the GPS trace with a piece of road and pick the road whose shape is closest. The Chao survey names the Fréchet distance as the most common measure. The Fréchet distance compares two lines while keeping the order of their points, so it measures shape as well as position. The survey also notes that it is sensitive to outliers: one bad GPS record can dominate the score.

Hidden Markov model map matching

A hidden Markov model is a statistical model of a sequence of states that cannot be seen directly. Each state produces a measurement that can be seen. Lawrence Rabiner explains HMMs in A tutorial on hidden Markov models and selected applications in speech recognition (Proceedings of the IEEE, 1989).

In map matching, the hidden state is the vehicle's real position on the road. The GPS record is the measurement. The Chao survey describes the steps:

1. Candidates. Each GPS record gets a few candidate positions on nearby roads.
2. Emission score. Each candidate is scored by its distance from the GPS record. A closer candidate scores higher.
3. Transition score. Each pair of candidates for consecutive GPS records is scored by how plausible the drive between them is. Newson and Krumm compared the driving distance between the two candidates with the straight-line distance between the two GPS records. A large gap means a detour, which scores low.
4. Best path. The Viterbi algorithm finds the chain of candidates with the best combined score. It does this without scoring every possible chain one at a time. Andrew Viterbi published the algorithm in Error bounds for convolutional codes and an asymptotically optimum decoding algorithm (IEEE Transactions on Information Theory, 1967).

The transition score can outweigh distance. A chain on the service road would need two detours through a parking lot, so it scores lower than a straight drive on the main road.

Online and offline map matching

The Chao survey separates two modes. Online map matching runs while the vehicle drives. It uses the current GPS record and a few records near it, so a navigation app can show the car on the right road with little delay. Offline map matching runs after the whole trip is recorded. It can use every record, so it can aim for the best path for the whole trip.

HMM methods work in both modes. The survey notes that online HMM methods match each record after a short delay.

Map matching vs nearest-road snapping

Feature	Nearest-road snapping	Curve-to-curve matching	HMM map matching
Unit matched	One GPS record	A piece of the trace	The whole trip
Uses road connections	No	Partly	Yes
Uses the order of records	No	Yes	Yes
Output	A road for each record	A road for each piece	One connected path
Main weakness	Picks the wrong road when GPS error is larger than the gap between roads	One bad GPS record can dominate the score	Needs a connected road network and more computation
Examples	A spatial join in SQL (below)	Fréchet-distance methods	Newson and Krumm (2009), fast map matching (FMM), Wherobots Map Matching

Which method works better in published studies

The results of studies that checked both methods against a known route follow one pattern. Snapping each record to the nearest road works when GPS records are frequent and accurate and no other road runs close by. With ordinary GPS, HMM map matching holds up better when records are noisy, far apart, or near other roads. On stacked roads, neither method did well with ordinary GPS alone.

• Frequent, accurate GPS. Timothy Hunter, Pieter Abbeel and Alexandre Bayen tested matching methods on San Francisco taxis that logged one GPS record per second (The path inference filter, 2011). At that rate, "all the points are correctly identified by all the algorithms", including a method that takes the closest road. Their reference route came from their own method on the same data, so it is not an independent check.
• Accurate positions on open roads. Xin Bi and co-authors compared the two methods on drives in Sweden and France, at one record per second (Driving with Context, arXiv, 2025). They scored each result with F1, a measure from 0 to 100 of how well the matched route overlaps the true route. Snapping with a survey-grade positioning system scored 93.80. An online HMM, which matches records while the trip is still under way, scored 93.73 with ordinary GPS.
• Roads stacked or side by side. On elevated highways built above surface roads in Shanghai, the same snapping scored 43.45 with ordinary GPS and 65.25 with survey-grade positioning. The online HMM scored 63.33. The authors write that better positioning alone remains "insufficient to reach the performance level of mainstream map matching algorithms."
• Gaps up to 30 seconds. Paul Newson and John Krumm's HMM returned exactly the hand-checked route on an 80 km drive with one record per second. With one record every 30 seconds, "the error is only 0.11%." HMM accuracy falls as gaps grow.
• Gaps of several minutes. Chenxu Han, Sean Bin Yang and Jilin Hu measured the share of records matched to the right road on Porto taxi data (DiffMM, 2026). HMM matched 83.82% at an average gap of 150 seconds and 40.04% at 600 seconds. Their trained neural model, DiffMM, matched 86.87% at 600 seconds.
• Cost. In the HMM that David Fiedler and co-authors built, shortest-path searches between candidate roads took 98% of the run time (Map Matching Algorithm for Large-scale Datasets, 2019). A faster method that matched each record from the previous one alone had accuracy they called "very low."
• Open problems. The 2019 survey by Pingfu Chao and co-authors notes three. Online HMM methods match each record "after a certain delay." Noisy records logged at a high rate can add detours the vehicle never drove. Dense road networks remain "a challenging task."

The Ann Arbor test below fits this pattern. The two methods mostly agreed where records sat within 5 m of the road, and split near junctions and next to service roads.

Map matching examples

• Navigation devices. A navigation device shows the car on the road it is driving. That placement is online map matching. Christopher White, David Bernstein and Alain Kornhauser studied this case in Some map matching algorithms for personal navigation assistants (Transportation Research Part C, 2000).
• Fleet telematics. A telematics device in a truck or van records GPS positions during each trip. Matched paths tie each position to a road, so speed can be compared with that road's speed limit. HERE, a location data company, lists driving analytics and speeding detection among the uses of its Route Matching API.
• Map matching APIs. The Mapbox Map Matching API "snaps fuzzy, inaccurate traces from a GPS unit or a phone to the road and path network." It accepts up to 100 coordinates per request. The Google Roads API takes up to 100 GPS points per request and returns them "snapped to the most likely roads the vehicle was traveling along." Longer traces must be split across requests.
• OSRM map matching. The Open Source Routing Machine (OSRM), an open source routing engine, has a match service that "matches/snaps given GPS points to the road network in the most plausible way." Its radiuses option sets the expected GPS error for each point, with a default of 5 m.
• Fast map matching (FMM). Can Yang and Győző Gidófalvi published Fast map matching, an algorithm integrating hidden Markov model with precomputation (International Journal of Geographical Information Science, 2017). FMM computes shortest paths in the road network ahead of time and combines them with an HMM.
• Research datasets. The Vehicle Energy Dataset (VED) records GPS traces and fuel and energy use for 383 personal cars in Ann Arbor, Michigan. Its authors publish it on GitHub, with data from November 2017 to November 2018. It covers about 374,000 miles and is licensed under Apache 2.0. The test below uses one week of it.

Map matching for walking and cycling

Map matching works for any mode of travel, as long as the network matches the mode. A car trace is matched to roads a car can use. A walking trace needs sidewalks, crosswalks, footpaths and steps. A cycling trace needs bike paths plus the roads a bike may use.

Map matching services ask for the mode up front. The Mapbox Map Matching API takes a profile: mapbox/driving, mapbox/driving-traffic, mapbox/walking for "pedestrian and hiking" travel, or mapbox/cycling. In the OSRM API, the profile is fixed when the road data is prepared and is "typically car, bike or foot."

Open map data carries the paths these modes need. Overture's transportation data has road classes for footways (with sidewalk and crosswalk subclasses), cycleways, paths, steps and pedestrian streets. Its scoping rules let an access restriction apply to one travel mode only.

We measured those paths in the same Ann Arbor area as the test below, with Overture data in Wherobots. Footways, paths, cycleways, steps, pedestrian streets and bridleways add up to 2,064 km. That is 58% of the 3,561 km of road the car test used:

SELECT SUM(CASE WHEN class IN ('footway','path','cycleway','steps','pedestrian','bridleway')
                THEN ST_LengthSpheroid(geometry) END) / 1000 AS walk_bike_km
FROM wherobots_open_data.overture_maps_foundation.transportation_segment
WHERE subtype = 'road' AND bbox.xmin > -83.86 AND bbox.xmax < -83.62
  AND bbox.ymin > 42.18 AND bbox.ymax < 42.37

Many of these paths run right beside a road:

Path type	Segments	Midpoint within 15 m of a car road	Median distance to that road
Sidewalk	4,021	57.0%	8.8 m
Cycleway	599	66.4%	8.9 m
Other footway	11,912	38.4%	9.3 m
Path	1,772	5.5%	16.1 m

The median distance counts only segments with a car road within about 25 m. The table comes from this query:

WITH seg AS (
  SELECT id, class, subclass, geometry
  FROM wherobots_open_data.overture_maps_foundation.transportation_segment
  WHERE subtype = 'road' AND bbox.xmin > -83.86 AND bbox.xmax < -83.62
    AND bbox.ymin > 42.18 AND bbox.ymax < 42.37),
walk AS (
  SELECT id, CASE WHEN class = 'footway' AND subclass = 'sidewalk' THEN 'sidewalk'
                  WHEN class = 'footway' THEN 'other footway' ELSE class END AS kind,
         ST_LineInterpolatePoint(geometry, 0.5) AS mid
  FROM seg WHERE class IN ('footway', 'cycleway', 'path')),
car AS (
  SELECT geometry FROM seg
  WHERE class IN ('motorway','trunk','primary','secondary','tertiary','residential','unclassified','living_street')),
near AS (
  SELECT w.id, MIN(ST_DistanceSphere(w.mid, ST_ClosestPoint(c.geometry, w.mid))) AS d
  FROM walk w JOIN car c ON ST_DWithin(c.geometry, w.mid, 0.0003)
  GROUP BY w.id)
SELECT w.kind, COUNT(*) AS segments,
       AVG(CASE WHEN n.d <= 15 THEN 1.0 ELSE 0.0 END) AS share_within_15m,
       percentile_approx(n.d, 0.5) AS median_distance_m
FROM walk w LEFT JOIN near n ON n.id = w.id
GROUP BY w.kind

Those gaps of about 9 m are close to the GPS error in the car test. There, the median distance from a GPS record to its matched road was 5.8 m. So a walking or cycling trace faces the same problem as a car beside a parking lot: the nearest line is often the wrong one. Snapping a pedestrian to the nearest line can put them in the traffic lane. Snapping a cyclist on a bike path can put them on the road next to it.

The car test below left these paths out on purpose, because a car cannot drive on them. It did not measure walking or cycling traces. Separate bike paths appear as cycleway segments in Overture; this article did not check how painted bike lanes on a road are recorded.

Map matching in Wherobots

Wherobots Map Matching runs HMM map matching on tables of trips. Its Python matcher reference documents matcher.match, which takes a table of road edges and a table of trips. The Wherobots Map Matching launch post describes it as "a Hidden Markov Model approach in the lineage of Newson and Krumm." Nearest-road snapping is a spatial join in WherobotsDB SQL. So both methods can run on the same records in one job.

The test

Claim. Snapping each GPS record to its nearest road puts a moving car on the wrong road often enough to change per-road results. The errors cluster near junctions and where a service road runs next to the road the car drove.

What would support it. Disagreement between the methods rises as GPS error rises, and is higher near junctions. In disagreements, nearest-road snapping returns a service road while the car is moving at road speed. The HMM path stays close to the length of the raw trace, so it does not add detours.

What would break it. Disagreement stays flat across GPS error and junction distance. Disagreements split evenly between "nearest picks the service road" and "HMM picks the service road." Or the HMM path is much longer than the raw trace.

A limit applies to the whole test. VED has no ground-truth path, so neither method can be scored as right or wrong. The test measures where the methods differ, and uses recorded vehicle speed to judge which placement is plausible.

Data and method

The GPS records come from the VED week starting 1 November 2017, as published in the Wherobots examples bucket. We kept one record per second per trip. That left 344,200 records from 854 trips by 258 vehicles.

The road network is Overture Maps road segments in a box around Ann Arbor, from the transportation segment table in Wherobots Open Data. Overture describes its transportation data as segments, which are the paths, and connectors, which are the junctions where they meet. Each segment was split at its connectors into edges. That produced 65,235 edges from 29,980 segments, totaling 3,560.9 km of road.

Method 1 snaps each GPS record to the nearest edge within 50 m:

SELECT trip_id, sec, eid AS nn_eid, seg_id AS nn_seg, d AS nn_d FROM (
  SELECT p.trip_id, p.sec, e.eid, e.seg_id,
         ST_DistanceSphere(p.pt, ST_ClosestPoint(e.geometry, p.pt)) AS d,
         ROW_NUMBER() OVER (PARTITION BY p.trip_id, p.sec
           ORDER BY ST_DistanceSphere(p.pt, ST_ClosestPoint(e.geometry, p.pt)), e.eid) AS r
  FROM p JOIN edges e ON ST_DWithin(e.geometry, p.pt, 0.0006)
) WHERE r = 1 AND d <= 50

ST_DWithin with 0.0006 degrees (about 49 to 67 m at this latitude) narrows each record to nearby edges before the exact distance is measured. ST_DistanceSphere gives that distance in meters.

Method 2 runs Wherobots Map Matching on each trip as one line of GPS positions. The settings allow a GPS record to be up to 50 m from its road, with an expected GPS error of 20 m:

from wherobots import matcher

sedona.conf.set("wherobots.tools.mm.matcher", "legacy")
sedona.conf.set("wherobots.tools.mm.maxdist", "50")
sedona.conf.set("wherobots.tools.mm.maxdistinit", "50")
sedona.conf.set("wherobots.tools.mm.obsnoise", "20")
mm = matcher.match(roads_mm, trips, "geometry", "geometry", "ids")

The matcher returns matched_nodes, the junctions the matched path passes through, in order. Each pair of consecutive junctions is one road edge. All 47,669 junction pairs in the matched paths joined to an edge:

-- mn: one row per consecutive junction pair (n, n2) in each trip's matched_nodes
SELECT DISTINCT ids, eid FROM (
  SELECT mn.ids, e.eid FROM mn JOIN edges e ON e.src = mn.n AND e.dst = mn.n2
  UNION ALL
  SELECT mn.ids, e.eid FROM mn JOIN edges e ON e.dst = mn.n AND e.src = mn.n2
)

Each GPS record was then placed on the nearest edge of its own trip's matched path. A record counts as a disagreement when the two methods put it on different Overture segments.

Results

All 833 trips with at least 5 records and 100 m of travel were matched. The matched path was close in length to the raw trace. The ratio of matched length to trace length had a median of 1.005, with 10th and 90th percentiles of 0.988 and 1.045. So the HMM path did not add long detours.

199,249 GPS records had a road from both methods. They disagreed on 32,596 records, or 16.4%. 771 of the 833 trips had at least one disagreement. For 31,808 records (16.0%), the nearest-road segment was not on the trip's HMM path at all. The median distance from a GPS record to its road was 4.86 m for nearest-road snapping and 5.76 m for the HMM path.

Disagreement rose with GPS error. Where the GPS record was within 5 m of the road on the HMM path, the methods disagreed on 5.1% of 89,262 records. At 20 to 50 m, they disagreed on 54.2% of 12,387 records.

Junctions raised disagreement. We counted a record as near a junction when it was within 25 m of a point where three or more edges meet. 111,420 records met that test. The methods disagreed on 22.5% of them, against 8.6% of the other records. One likely reason: near a junction, a cross street lies a few meters from the car, so a small GPS error can make it the nearest road.

Speed made less difference. Disagreement was 11.4% below 5 km/h, 16.8% at 5 to 30 km/h, 19.1% at 30 to 60 km/h and 14.4% at 60 km/h or more.

Overture's road classes include main roads (motorway, trunk, primary, secondary, tertiary), residential streets and service roads. Service roads include driveways, parking aisles and alleys. The most common disagreement was a record the HMM placed on a secondary road and nearest-road snapping placed on a service road: 8,576 records.

In 12,968 disagreements, nearest-road snapping returned a service road and the HMM returned a main road. In 405, it was the other way round. Of the 12,968 records, 56.6% were moving at 40 km/h or more, with a median speed of 44 km/h. The 405 records had a median speed of 16 km/h.

Of the service roads nearest-road snapping returned, 4,275 were driveways, 2,142 parking aisles and 232 alleys. 6,319 had no subclass in Overture.

Across all 99,317 compared records at 40 km/h or more, nearest-road snapping put 8,429 (8.5%) on a service road. The HMM put 1,119 (1.1%) there.

One trip on South Industrial Highway

One trip shows the pattern. Vehicle 457 drove along South Industrial Highway in Ann Arbor, a road lined with driveways and parking lots. The trip passed the same stretch twice, at 54 to 63 km/h. Nearest-road snapping put 48 of the 63 records in that stretch on service roads. The HMM placed all 63 on the highway.

The records sit west of the road centreline. Along this stretch, a driveway or parking aisle is often closer to them than the centreline, so nearest-road snapping returned it. In the HMM, a drive along the highway got a higher transition score than hops between separate driveways.

Verdict

The claim held. Disagreement rose from 5.1% within 5 m of the road to 54.2% at 20 to 50 m. Near junctions it was 22.5%, against 8.6% elsewhere.

When the methods split between a main road and a service road, nearest-road snapping returned the service road 12,968 times and the HMM 405 times. 56.6% of those 12,968 records were moving at 40 km/h or more. The HMM path was no more than 4.5% longer than the raw trace for 90% of trips.

Without a ground-truth path, this test cannot give an error rate for either method. It shows where they differ. In the main road vs service road splits, the recorded speeds fit the HMM result far more often.

Map matching research history

Early algorithms (2000). White, Bernstein and Kornhauser's 2000 study tested simple map matching algorithms for personal navigation assistants, the handheld and in-car navigation devices of the time.

The 2007 review. Quddus, Ochieng and Noland's review sorted methods into geometric, topological, probabilistic and advanced groups. It notes that navigation in intelligent transport systems needs a horizontal accuracy of 1 m to 40 m (95%). It found that existing algorithms could not always meet those needs, "especially in difficult and complex environments such as dense urban areas."

Hidden Markov models (2009). Paul Newson and John Krumm published Hidden Markov map matching through noise and sparseness in 2009, at the Association for Computing Machinery (ACM) SIGSPATIAL conference. It combined the emission and transition scores described above with the Viterbi algorithm. The Wherobots launch post says "most map matching implementations are variants" of their algorithm.

Low sampling rates (2009). At the same conference, Yin Lou, Chengyang Zhang, Yu Zheng, Xing Xie, Wei Wang and Yan Huang published Map-matching for low-sampling-rate GPS trajectories. Their method scores candidate paths by distance and by whether the implied speed is reasonable. It targets traces with long gaps between GPS records.

Speed through precomputation (2017). Yang and Gidófalvi's FMM adds precomputation to HMM map matching: shortest paths in the road network are computed once, before any trip is matched.

Surveys (2019). Chao, Xu, Hua and Zhou's survey proposed four newer groups: similarity models, state-transition models (HMMs among them), candidate-evolving models such as particle filters, and scoring models.

Map matching at scale. Each trip needs its own candidate search and shortest-path searches, so the work grows with the number of trips. Jia Yu, Jinxuan Wu and Mohamed Sarwat introduced GeoSpark (ACM SIGSPATIAL, 2015) to run spatial joins on Apache Spark, a system that splits data processing across many machines. Yu, Zongsi Zhang and Sarwat described how GeoSpark divides spatial data across machines in Spatial data management in Apache Spark: the GeoSpark perspective and beyond (GeoInformatica, 2018). GeoSpark became Apache Sedona, the engine WherobotsDB is built on.

The Wherobots launch post reports matching 90 million US trips in 1.5 hours on the Wherobots 2XL runtime, at a cost of $873. That is about $9.70 per million trips. The same post lists July 2024 prices per million trips of $1,600 for Mapbox, $4,400 for HERE and $8,000 for Google Maps Platform.

Conclusions

1. Map matching returns one connected path; nearest-road snapping returns one road per record. If an analysis counts distance, time or speed per road, use map matching. In Ann Arbor, the two methods placed 16.4% of records on different roads, in 771 of 833 trips.
2. Nearest-road snapping holds up only where GPS error is small. The methods agreed on 94.9% of records within 5 m of the road and on 45.8% of records 20 to 50 m away. If your records carry a GPS accuracy field, check its distribution before you choose a method.
3. Expect snapping errors near junctions. Within 25 m of a junction, the methods disagreed on 22.5% of records, against 8.6% elsewhere. If an analysis counts turns or junction delays, match the whole trip.
4. Service roads beside main roads pull moving cars off the road. In 12,968 main road vs service road splits, nearest-road snapping returned the service road; the HMM did so in 405. If your road network includes driveways and parking aisles, do not use nearest-road snapping for moving vehicles.
5. Match each mode against a network built for it. Use roads for cars, and add footways, crossings and steps for walking, and cycleways for cycling. In Ann Arbor those paths add 2,064 km to 3,561 km of road, and most sidewalks and cycleways sit within 15 m of a road.
6. Agreement between methods is not accuracy. Without a ground-truth path, compare methods and use other recorded fields, such as speed, to judge which result is plausible. Also check the matched path against the raw trace: in Ann Arbor, 90% of matched paths were at most 4.5% longer.

Related terms

• Geospatial analysis: the network analysis methods that use matched trips as input
• Spatial join: the operation behind nearest-road snapping
• Isochrone: another analysis built on the same road network graph
• Geospatial data: the vector data model that GPS points and road lines belong to
• Coordinate reference system: why distance in degrees differs from distance in meters
• H3: hexagonal grid cells for summing data by area
• Havasu catalog: the Wherobots Open Data tables, including Overture roads
• Physical AI: AI that senses and acts in the physical world, such as in vehicles
• Geofence: another way to turn a stream of locations into events, by checking each one against zones

Read more from Wherobots

• Wherobots Map Matching: Turn GPS Tracks into Road-Aligned Trip Insights at Scale
• Building the Wherobots Mobility Solution Accelerator: A Technical Deep Dive
• Mobility Data Processing at Scale: Why Traditional Spatial Systems Break Down
• How Bad Telemetry Data Sabotages Modern Fleets
• GPS map matching, the Wherobots notebook tutorial
• Map matching on road networks, the Wherobots tutorial

Match GPS traces to roads at scale with Wherobots at cloud.wherobots.com.