Arc Routing vs Node Routing: Why Street-Based Fleets Need a Different Solver in 2026

Arc routing is the class of route optimization problem where the task being served is attached to a street segment, an edge on the map, rather than a single point, and the vehicle has to traverse that segment to complete the work. Node routing, the formulation behind the classic Vehicle Routing Problem that most route optimization software is built around, assumes every task lives at a discrete stop the vehicle visits and departs from. Waste and recycling collection, street sweeping, winter gritting and salting, and utility meter reading on residential blocks are, mathematically, arc routing problems, not node routing problems, and applying a node-based solver to them treats a continuous street traversal as if it were a series of separate points, which prices the work incorrectly. Locus, the world’s first Decision-Intelligent, Agentic TMS, models both node-based stops and edge-based service tasks inside the same constraint engine, so a mixed network does not have to force one problem type into the other’s solver.

Why Arc Routing Matters: The Business Case

Most route optimization software, including the majority of enterprise TMS platforms, is built around the Vehicle Routing Problem: a set of discrete stops, each with a location, a demand and a time window, sequenced and assigned to vehicles subject to capacity constraints. That formulation is correct for the large majority of delivery and dispatch use cases, where the task genuinely happens at a point. It is the wrong formulation for a meaningful category of street-based fleet work, where operations researchers have separately studied and named the correct problem: the Capacitated Arc Routing Problem, which models tasks as required edges on a graph rather than required nodes, with real, named applications spanning snow removal and street sweeping, winter gritting, utility meter reading, and waste collection, including a documented fast heuristic built specifically for Danish waste collection networks.

The distinction is not academic pedantry. A 2023 peer-reviewed survey of waste collection routing research found that node routing, meaning VRP-family formulations, remains the most commonly applied approach in the literature and in practice, even though a meaningful share of real waste collection work is genuinely edge-based. That gap between what is commonly deployed and what is mathematically correct for the task is exactly the mismatch this piece is about. A node-based solver applied to a street segment has to approximate the segment as a point, typically the segment’s midpoint or one endpoint, and that approximation breaks in a specific, predictable way: service on an edge-based task happens continuously while the vehicle traverses the segment, not at the moment it arrives at a stop. A solver reasoning only in points either counts the segment’s traversal distance as separate travel time on top of a service time that already happened during that traversal, inflating the plan’s cost, or it collapses the segment to a single point and loses the fact that a two-way residential street is typically collected in both directions in a single pass, understating how much work one traversal actually completes.

The market this affects is not small. Global spending on municipal solid waste management alone is estimated in the range of $122.77 billion in 2025 growing toward $128.05 billion in 2026, and that figure sits alongside street sweeping, winter road maintenance and utility meter reading fleets that face the identical edge-versus-node mismatch. A network running a node-based solver against genuinely edge-based work is not failing loudly, the routes still get built and the trucks still run, but the plan is quietly mispriced against a task that was never the one the solver was built to represent.

This is why the mismatch tends to persist for years inside an operation without anyone flagging it as a modeling problem. A route that runs long or a fuel bill that comes in higher than expected gets attributed to traffic, driver behavior or an outdated map, all plausible explanations that point away from the actual cause: the plan was built by treating a street the truck has to traverse as if it were a single pin the truck simply visits. Because the routes still execute and the work still gets done, the mispricing shows up as a persistent, low-grade inefficiency rather than a visible failure, which is exactly the kind of problem that survives unexamined inside an otherwise well-run fleet.

How to Tell Which Problem Type a Network Actually Has

Step 1: Identify whether the task lives at a point or along a segment

A delivery, a pickup, a single-address service call, these are point tasks. Curbside waste collection along a residential block, a street-sweeping pass, a cable inspection run, these are edge tasks where the vehicle has to physically traverse the segment to complete the work, not just arrive somewhere on it.

Step 2: Check whether the street needs to be served once or in both directions

Many residential arc-routing applications require bilateral service, both sides of a two-way street collected in a single pass or two separate passes. A node-based solver has no native way to represent that a segment’s demand exists on both sides independently.

Step 3: Separate genuinely mixed networks into their component problem types

Most real networks are not purely one type. Commercial and roll-on-roll-off collection at a single dock is a point task. Residential curbside collection along the same route is an edge task. A network running both needs a solver that handles both without forcing one into the other’s model.

Step 4: Model the edge’s service cost as part of the traversal, not on top of it

For a genuine arc-routing task, the time to complete the service is bound to the time to traverse the segment, not an additional dwell time added after arrival at a point. Modeling it as a separate service time stacked on top of travel time double-counts the work.

Step 5: Solve for edge coverage and vehicle capacity together

An arc-routing solve still has to respect vehicle capacity, a waste truck fills up mid-route the same way a delivery van does, which means the solver has to sequence which required edges get served before a capacity-triggered return to a depot or disposal site, the same operational logic as a capacitated VRP, applied to edges instead of points.

Step 6: Re-solve when a segment’s status changes mid-shift

A blocked street, a closed lane, a segment that turns out to need a second pass, all change the arc-routing problem mid-execution the same way a cancelled stop changes a VRP mid-execution, and the solver needs to re-plan the affected segments rather than treating the original plan as fixed.

Node Routing vs Arc Routing for Street-Based Fleets

The table’s last row is the finding worth sitting with. The more commonly deployed approach is not the more accurate one for a meaningful share of street-based fleet work, which means a buyer evaluating route optimization software for a waste, sweeping, gritting or meter-reading network cannot assume that “route optimization software” on a vendor’s feature list means the vendor has actually built for this problem type.

The reason node routing stays dominant even where it fits poorly is mostly historical rather than technical. VRP-family solvers are older, more widely commercialized, and back a much larger share of the route optimization software market than arc-routing-specific tools do, so a fleet manager evaluating software options will encounter far more vendors that speak fluently about points, time windows and capacity than vendors that speak fluently about required edges and bilateral street service. That commercial gravity, not a genuine technical argument that node routing suits edge-based work, is why the mismatch persists as widely as the 2023 survey found it does.

What to Look for in Software That Handles Arc-Based Networks

Explicit support for edge-based tasks, not just points with a workaround. Ask whether the platform natively models a required segment with its own demand and service cost, or whether the vendor’s answer is to manually convert every segment into an artificial point before the network can be planned.

Bilateral collection modeled as a native case. For residential street networks, confirm the solver can represent both sides of a two-way street as distinct demand rather than assuming one side implies the other.

Mixed-network capability in the same solve. If the operation runs both point-based commercial pickups and edge-based residential collection, the solver needs to handle both problem types together in one plan, not as two disconnected systems reconciled manually.

Capacity-triggered routing to a depot or disposal site built in. The solver should sequence required edges against vehicle capacity the same way a capacitated VRP sequences stops, triggering a return trip when the vehicle fills rather than treating capacity as an afterthought.

Mid-shift re-planning for segment-level disruptions. Ask how the system handles a blocked street or a segment that needs a second pass mid-route, since this is the arc-routing equivalent of a cancelled stop and needs the same live re-optimization discipline.

What This Looks Like in Practice

A leading North American retailer running a multi-hundred store network across truck, rail and 3PL reached 95 percent-plus route compliance after consolidating six legacy systems onto one platform, a result that depended on the planning engine correctly representing the actual operating constraints of the network rather than approximating them into whichever problem type the software happened to be built for.

A Fortune 50 parcel enterprise running more than 4,500 drivers across 51 sites uncovered more than $14 million in annualized operational opportunity by making previously invisible capacity and constraint modeling visible inside a single planning system, evidence that solving the actual problem a network has, rather than the nearest problem the software already knows how to solve, is where a meaningful share of durable operational savings comes from.

Common Mistakes to Avoid With Arc-Based Networks

Assuming any route optimization software handles street-based collection correctly by default. Most platforms are built around node routing because most route optimization use cases are point-based. A vendor’s general routing capability says nothing about whether it natively models edge-based tasks.

Manually converting segments into points as a permanent workaround. Approximating a street segment as its midpoint might get a plan built, but it bakes the mispricing described in this piece into the plan every single time it runs, rather than fixing the underlying model.

Treating a mixed point-and-edge network as two separate planning problems. Commercial point collection and residential edge collection on the same fleet need to be solved together, against shared vehicle capacity, not reconciled after two separate systems each produce a partial plan.

Ignoring bilateral collection requirements when they exist. A solver that assumes one side of a street implies the other will understate true demand on residential blocks where both sides need independent service, producing a plan that looks complete but leaves real work undone.

How Locus Approaches Mixed Node and Arc Networks

Locus, the world’s first Decision-Intelligent, Agentic TMS, models both node-based stops and edge-based service tasks inside the same route planning system, so a network running commercial point collection alongside residential street-based collection does not have to force one task type into a solver built only for the other. Because Locus’s engine already handles more than 250 real-world constraints simultaneously, vehicle capacity, service timing and segment-level requirements are evaluated together rather than as two disconnected planning problems reconciled by hand. Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group’s SPARK Matrix, and ranked #1 in Route Planning on G2’s 2026 Best Software Awards.

A leading North American retailer reached 95 percent-plus route compliance after consolidating six legacy systems onto Locus, and a Fortune 50 parcel enterprise uncovered more than $14 million in annualized operational opportunity by making previously invisible constraints visible inside one planning engine, both evidence that modeling a network’s actual operating structure, rather than the nearest structure the software already understands, is where real savings are found.

In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.

Most route optimization software was built for point-based work, because most delivery and dispatch use cases genuinely are point-based. That leaves street-based fleets, waste and recycling collection, sweeping, gritting, meter reading, running plans built on an approximation the underlying mathematics never actually fit. Locus models the edge-based case as a first-class input alongside the point-based case, so a mixed network gets one accurate plan instead of two approximated ones. If your fleet runs street-based collection work through software built for point-to-point delivery, schedule a demo to see how Locus models the problem you actually have.

Frequently Asked Questions

What is arc routing in route optimization? Arc routing is a class of routing problem where the task being served is attached to a street segment, an edge on the map, rather than a single point, and the vehicle has to traverse the segment to complete the work. It is formally studied in operations research as the Capacitated Arc Routing Problem, distinct from the Vehicle Routing Problem most route optimization software is built around.

Why can’t a standard route optimization solver handle waste collection correctly? A standard solver assumes every task is a discrete point with a location and a time window. Residential curbside waste collection is typically an edge-based task, the truck serves the street as it drives along it, and approximating that street as a single point either double-counts travel time already spent performing the service or understates how much work one pass actually completes.

Is all waste collection an arc-routing problem? No. Commercial and roll-on-roll-off collection at a single dock or bin location is genuinely point-based and fits a standard VRP formulation well. Residential curbside collection along a block is the case that is genuinely edge-based. Most real waste networks run both types together.

What other industries face this same node-versus-arc mismatch? Winter gritting and salting, street sweeping, and utility meter reading on residential blocks all share the same structural issue as residential waste collection, work that is attached to a street segment rather than a single stop.

Does arc routing still need to respect vehicle capacity? Yes. A capacitated arc-routing solve still has to sequence which required segments get served before a vehicle fills up and needs to return to a depot or disposal site, the same operational logic as a capacitated VRP, just applied to edges instead of points.

How common is it for route optimization software to actually support arc routing? Less common than the underlying need would suggest. A 2023 peer-reviewed survey of waste collection routing research found node-routing, VRP-style, approaches remain the most commonly applied in practice even though arc routing is the more accurate formulation for genuinely edge-based collection tasks.