Multi-Stop Route Planner: How Stop Ordering Works and What to Check Before You Trust It

What a multi-stop route planner actually solves

You have a list of places to visit: deliveries, service calls, pickups, site inspections. A single-destination map app will take you from one to the next, but it will not tell you which one should be next. That decision, the order of the stops, is the job of a multi-stop route planner.

It helps to separate two problems that are often bundled together:

• Sequencing. Given all the stops, in what order should they be visited so the trip as a whole is short?
• Pathfinding. Given two consecutive stops, which roads connect them?

Pathfinding is well understood and quick to compute. Sequencing is the hard part, and it is the part this page is about.

Why the order of stops is a hard problem

Sequencing a single vehicle's stops is a version of the travelling salesman problem. The difficulty comes from how quickly the number of possible orders grows. A handful of stops can be checked exhaustively. Add a few more and the count of possible orders multiplies with every stop, until checking them all stops being practical for any computer.

Exact methods exist and are used in research and in specialist solvers, but they become slow as the stop list grows. So most planners you can use from a browser do something different: they use a heuristic, a procedure that finds a good order quickly without proving it is the shortest one possible.

That is not a flaw to hide. It is the normal engineering trade-off, and a planner that tells you which heuristic it uses is giving you useful information.

Three heuristics worth knowing

Nearest neighbour. Start at the first stop, go to the closest unvisited stop, repeat. It is simple and fast, and it tends to leave a long, awkward leg at the end, when the only stops left are the ones it kept skipping.

2-opt. Take an existing order, pick a segment, and reverse it. If the route got shorter, keep the change. Repeat until no reversal helps. On a map this is the step that removes places where the route crosses over itself.

Simulated annealing. This uses the same kind of move as 2-opt, with one difference: early in the search it will sometimes accept a change that makes the route worse. That lets it climb out of an order that is merely locally good. As the search continues, it accepts worse moves less and less often, and settles. Because it relies on random choices, two runs on the same stops can finish with different orders.

None of these promise the shortest possible route. They differ in how much computing they spend and how easily they get stuck.

Two questions to ask of any planner

What distance is it measuring? There is a large difference between straight-line distance (the direct distance between two coordinates) and road distance. Straight-line distance is cheap to compute and needs no road data, but it knows nothing about rivers, one-way systems, motorway junctions or bridges. In a dense street grid, a straight-line ordering is often a reasonable first pass. Where water or limited-access roads sit between stops, it can mislead.

What is it ignoring? Real routes are shaped by traffic, delivery time windows, vehicle capacity, driver hours and the number of vehicles available. A planner that models none of these can still be useful for sequencing, as long as you know that is what you are getting. The risk is a tool that shows controls or figures for things it does not compute.

How Q-Logos plans a multi-stop route

Q-Logos is a web app with a route planning page behind a free account. Here is what that page does in the current live version, and nothing beyond it.

Entering stops. There are four ways to add a stop, and every one of them ends in real coordinates:

• Type an address and pick from the suggestions. The lookup runs through OpenStreetMap's Nominatim geocoder.
• Type a latitude and longitude directly.
• Upload a CSV file with an address, a latitude and a longitude on each line. Rows without valid coordinates are skipped, and the page tells you how many and on which lines.
• Click the map.

If an address cannot be located, the stop is not added and you see a message saying so. The planner does not place a stop at a guessed position.

Ordering the stops. When you press the optimize button, the stops are sent to the Q-Logos server, which orders them with simulated annealing. The backend's own documentation calls the approach quantum-inspired; in plain terms it is a classical heuristic running on ordinary servers, with no quantum hardware and no quantum circuit involved. The pricing page describes the engine the same way.

The first stop in your list is kept as the starting point and the later stops are reordered. The route is an open path: it does not add a return leg to the start.

Three alternatives, with the method printed underneath. The server returns three orderings, drawn on the map as lines and shown as three cards. The cards carry time-, cost- and balance-style labels, but the page also prints the server's own note about them: they are three independent simulated-annealing runs of the same distance objective, not three different objectives. Alongside that note, the page shows:

• the baseline that any "saved" figure is compared against, which is a nearest-neighbour order improved by 2-opt rather than the order you typed;
• the definition of the on-time confidence figure;
• ETA percentiles, when the server sends them.

Distances are straight-line. The distance on each card is the sum of straight-line distances between consecutive stops, and the card says so in a footnote: it is not road distance. Durations and the time and fuel differences against the baseline are derived from that same straight-line model, so they are modelled estimates, not measured drive times or measured savings.

Missing figures stay missing. The server does not return a fuel cost, a total cost, a toll cost or a carbon figure for a route, so those rows on the card show a dash instead of a number.

What the Q-Logos planner does not model

A planner is easier to trust when its limits are written down. The route optimizer in the Q-Logos web app does not use:

• road networks, turn-by-turn directions or road distance;
• live traffic or weather data;
• delivery time windows or per-stop deadlines;
• vehicle capacity or more than one vehicle;
• toll, highway or low-emission-zone avoidance in the ordering;
• a fixed final stop, since only the first stop is held in place.

The route page also has a What-If Analysis panel. It shows a fixed sample result under a sample-data banner and is not connected to a calculation engine, so it is not part of what this page describes.

When this kind of planner fits

A straight-line sequencing tool fits when you have one vehicle, a list of stops, and you want a sensible order quickly, which you will then drive with your usual navigation app. It also fits when you want to see how the result was produced instead of taking a single answer on trust.

It is not the right tool if you need road-accurate arrival times, deliveries inside customer time windows, or a plan that splits stops across several vehicles. Those call for a full vehicle-routing system with road data.

Plans differ in how many routes you can run per day and how many stops a route can hold; the limits are listed on the pricing page. To try the planner on your own stop list, create a free account.