A navigation heuristic, not a graph search

Skip the road graph.
Draw the line instead.

Real navigation engines build a graph of every road and search it — Dijkstra, A*, thousands of nodes evaluated per query. TraceRoute tries a cheaper idea: draw a straight line from A to B, and pick whichever waypoints sit closest to it. No per-point graph, no priority queue — just a projection and a sort for every candidate. Simpler work per query is exactly what a CPU with no cycles to spare needs.

Try the routing engine ↓ See how it works
One idea, three implementations: 🐍 Python ⚙️ C++ ☕ Java + JavaFX

Try it as a router

One computed route, three ways to look at it — switch with the View dropdown below. Think of the dots as waypoints — intersections, charging stations, delivery stops. Click to set the origin, optionally Shift+click to add mandatory stops the route must pass through in order, then click again to set the destination. The 🔴 red points are the route TraceRoute picked, connected by the 🟡 yellow path it would actually follow. You don't pick how many stops to use — set the one thing that actually matters (say, 20km max between fuel/delivery stops) and TraceRoute finds the fewest, straightest stops that keep every single leg under that limit. The map itself is split into colored islands (dense clusters, like boroughs), joined only by the single closest bridge point-pair between them — the fast routing only ever runs inside one island at a time, crossing is just a lookup.

Origin
Destination
Mandatory stop
Chain stop
Route / bridge
Island (color varies)

📍 Click to set the origin

Why this is cheaper than a real router

A production navigation engine searches a graph. TraceRoute replaces that search with four constant-time geometry steps per waypoint — no traversal, no priority queue.

  1. 01

    Draw the direct line

    Instead of a road graph, TraceRoute starts from the one line every router already knows: the straight shot from origin to destination.

  2. 02

    Project each waypoint

    Every candidate point is dropped perpendicularly onto that line — one multiplication-heavy step, no recursion, no queue.

  3. 03

    Discard what's off-route

    Waypoints whose projection falls outside the origin–destination segment are dropped — they'd be a detour, not a shortcut.

  4. 04

    Rank by detour distance

    What's left is sorted by how far it sits off the direct line — the closest ones are the cheapest real-world route to follow.

Three implementations, three different jobs

Same core idea, at different stages of maturity — the demo above runs the two that are actually current.

🐍 Python

Web demo · reference engine

The only engine that supports client-defined mandatory stops. Where the island routing and adaptive stop-spacing were proven out first — easy to read, easy to change, not the fastest.

⚙️ C++

Web demo · default engine

Same island routing, compiled to a shared library — no runtime, no GC pauses, roughly an order of magnitude faster than the Python engine at a few thousand points. The profile you'd want on embedded or battery-powered hardware.

☕ Java

Original prototype

Where the core corridor-projection idea was first built, plus a native JavaFX desktop visualizer for inspecting routes offline. Hasn't been upgraded with island routing or mandatory stops yet — not part of this web demo.

For engineering teams evaluating routing

Bring TraceRoute into your product

Early-stage and looking for design partners — teams with a real constrained-hardware routing problem who want to pressure-test this approach against their own data and hardware. Not a finished drop-in SDK yet; a serious algorithm worth a technical conversation.

🚁 Drone & fleet routing

Open terrain

Waypoint planning for swarms or delivery drones where the flight corridor is mostly open and full graph search is dead weight on the flight controller.

📦 Last-mile & logistics

High throughput

Thousands of rough routes computed per second on modest hardware, where "good enough, instantly" beats "optimal, eventually."

🔋 Embedded & IoT trackers

Low power

Asset trackers and battery-powered devices that can't afford the RAM or CPU cycles a graph-based router needs.

What's proven, what isn't

  • Proven: the core geometry — projection, corridor filtering, even-chain construction — runs correctly and reproducibly in all three implementations. The production routing (Python + C++) layers one more piece on top: the map is split into islands with a tiny island-to-island graph — a handful of nodes, not one per point — so the expensive per-point corridor search never runs across the whole map, only locally inside one island at a time.
  • Not yet proven: real-world routing accuracy against actual road/obstacle data, and measured CPU/RAM numbers against Dijkstra/A* on target hardware. That's exactly what a design partnership would establish together, on your data.
Request a technical walkthrough ✉️ Straight to the author — Gilbert Zenner. No sales team, no funnel.