Breadcrumb trail: the line driven, not the line planned
In short
A breadcrumb trail is the ordered series of position reports one vehicle produced over a period — where it was, in sequence, by its own clock. The planned route line is intent; the trail is evidence, and only of what the device reported at the resolution it reported it. That resolution, the ping interval, decides what the trail can settle and what it cannot.
Key takeaways
- The trail is observation, the route line is intent, and the matched path is interpretation. Three lines, not 2.
- At 90 km/h a 5-minute interval leaves 7.5 km unobserved between fixes. That is what limits the claim.
- A trail always undercounts distance, because straight segments cut the corners the vehicle drove around.
- A trail proves what the device reported. It does not prove who drove, or what was on the trailer.
- Polling a provider API often returns a decimated trail; the device stream is the only native-resolution source.
A breadcrumb trail is the ordered series of position reports one vehicle produced over a span of time — each fix with its device timestamp, drawn in sequence. It records what was observed. The route line on the same map is a plan produced before the vehicle moved. Both render as a line, and treating them as 2 views of one thing is how a mileage argument gets lost.
There are 3 lines, and keeping them apart is most of the discipline here.
- The planned route. Intent, generated before departure: the right basis for costing and promising, and evidence of nothing that happened.
- The breadcrumb trail. Observation: the raw fixes, in device-clock order, with their accuracy figures intact. This is the only one of the 3 that is evidence.
- The map-matched path. Interpretation — the trail snapped to the road network, which makes it readable and introduces assumptions, as map matching turning pings into roads sets out. Store it beside the trail, never instead of it.
What the ping interval decides
The trail's evidential value is bounded by one number: how far the vehicle travelled between 2 consecutive fixes. At 90 km/h that is 25 metres a second, and the arithmetic settles most arguments about what a trail can be asked to show.
| Interval | Unobserved gap at 90 km/h | Can substantiate | Cannot substantiate |
|---|---|---|---|
| 10 s | 250 m | Lane-level route, stops of 20 seconds or more, close arrival timing | Anything shorter than the interval itself |
| 30 s | 750 m | Street-level route in town, arrival within about a minute | A brief stop: a vehicle can pull in and leave unseen |
| 60 s | 1.5 km | Corridor taken, presence at a site, dwell of some minutes | Which of 2 parallel roads was used, or a short detour |
| 5 min | 7.5 km | That the vehicle was in a region during a window | Route, detours, or any stop under 5 minutes |
A dispute is about a specific claim — detention started at 09:14, the vehicle never left the site, the route was 40 km longer than quoted. Read the interval first and decide whether the trail can carry it, before anyone opens a replay.
Why the trail always undercounts distance
So the odometer field is worth insisting on when a feed is specified, alongside the accuracy and timestamp fields in the 8 fields a position report must carry. Discovering this during a billing dispute is discovering it too late.
What a trail proves, and what it does not
- It proves a device reported those positions at those times — narrower than 'the vehicle was there'.
- It does not identify the driver. Position and identity are separate records joined by a rostering assumption, wrong on the days it matters most.
- It does not show whether the engine ran during a stop. A stationary trail fits a delivery, a break and a queue equally, which is why ignition state is read alongside it — with the caveats in what an ignition event actually proves.
- It says nothing about the load. What should be on the trailer is a separate promise, recorded in the ASN as a promise about what is on the truck, which a trail can neither confirm nor contradict.
- It is only as good as its accuracy figures. A trail containing 2 fixes with 800-metre accuracy has a visible detour in it that never happened.
The route line says where the vehicle was meant to go. The trail says where a device said it was. Only one is admissible, and it is the less flattering one.
Getting the trail at the resolution you think you have
Fleets often discover during a dispute that their stored trail is thinner than their device cadence. Providers decimate history on the way out of an API — 1 fix a minute from a device reporting every 10 seconds — so the stored trail is a sample of a sample. Taking the device stream or polling a provider decides this, and it is examined in pulling from the provider or taking the device stream.
Two practices follow. Store raw fixes with accuracy and device time exactly as received, and derive matched path, distance and dwell on read, so a better matcher next year applies to the same history. And version the planned route separately, because a route changed at 11:00 makes any comparison against the morning's plan meaningless. The replay view and the export an operations team hands to a customer are the narrow tooling we describe under internal tools and operations software; neighbouring definitions sit in telematics and the live vehicle data plane, inside our logistics and mobility work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a breadcrumb trail in vehicle tracking?
It is the ordered set of position reports a single vehicle produced over a period, drawn in sequence. Each point carries its own timestamp and, in a well-specified feed, an accuracy figure. It records observations rather than a route: the line between 2 points is drawn by software, not travelled by the vehicle.
What is the difference between a planned route and a travelled path?
The planned route is intent, produced before the vehicle moved; the travelled path is observation, assembled from what the device reported. They differ whenever traffic, a closure, a customer instruction or a driver decision intervenes, which is most days. Quoting the plan in a dispute about what happened is a category error; quoting the trail in a costing conversation is the same error reversed.
Can a breadcrumb trail be used to prove mileage?
It gives a lower bound, not a total, because distance summed between fixes cuts every corner the vehicle drove around. The shortfall grows with the ping interval and with how urban the route is. Where the vehicle reports its own odometer, use that; where it does not, quote the interval alongside the figure so the number can be assessed rather than argued about.
- breadcrumb trail
- telematics
- route history
- evidence
The work behind this page
Builds from our portfolio that this page draws on.
Axlebound
Real-time fleet tracking and dispatching platform with full visibility over every vehicle, driver, and route.
LogisticsHaulBoard
An AI freight load board that matches every open load to the best-fit carrier, prices each lane on live spot-rate data, and tracks broker margin on every move.
LogisticsRead next
- The 8 fields in a position report, and the 2 that make it trustworthyA coordinate pair on its own proves almost nothing. The 8 fields around it decide whether a position is evidence, and 2 of them decide whether the other 6 can be believed.definition
- Ignition on and off: 1 true signal and its 4 false versionsEvery telematics feed carries an ignition flag. Whether it means the engine is running depends on how it was obtained, and the field itself almost never says.definition
- Geofence: a zone, 3 triggers, and the hysteresis that stops it lyingA zone on a map is not a geofence. It becomes one when a trigger rule and a hysteresis policy are attached, and without the second it fires whenever a parked vehicle's fix wanders.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation