research · tech · 27 Jul 2026

Blauth2024: a major time-dependent routing benchmark joins the MAMUT-routing catalog

27 Jul 2026 0nyr

The MAMUT-routing catalog has a new family, and it is a significant one. Blauth2024 is our faithful conversion of the vrptdt-benchmark published by Jannis Blauth, Stephan Held, Dirk Müller, Niklas Schlomberg, Vera Traub, Thorben Tröbst and Jens Vygen (University of Bonn) alongside their paper Vehicle routing with time-dependent travel times: Theory, practice, and benchmarks (Discrete Optimization, 2024). It is now live on my mirror: mamut-routing.onyr.net/benchmarks/tdvrptw/blauth2024.

Why this benchmark matters

Most time-dependent routing benchmarks generate their congestion synthetically. The Bonn group did something different: they built travel times from real OpenStreetMap road networks combined with measured Uber Movement speed data, for ten cities on four sub-continents (Berlin, Cincinnati, Kyiv, London, Madrid, Nairobi, New York, San Francisco, São Paulo, Seattle) at 10, 500, 1000 and 2000 customers. The result is, to my knowledge, the most realistic public TDVRPTW benchmark available today.

There is also a preservation angle. Uber Movement was shut down on October 1, 2023, so the published arrival-time matrices can no longer be reproduced: they are the sole surviving artifact of that speed data. Redistributing them faithfully, with checksums and a documented format, is a way to make sure they stay usable.

What the instances look like

The family covers the delivery-only variant of their benchmark: an unlimited fleet of identical uncapacitated vehicles, depot departures at or after 15:00 with free return, three minutes of service per delivery, and hard time windows (half one-hour windows, half a wide 15:30 to 21:00 window). Travel times are dense per-arc piecewise-linear arrival-time functions spanning 15:00 to 22:00. The upstream pickup-and-delivery variant is out of the catalog’s node-routing scope and stays upstream only; there is also no time-window-free twin, because the time windows are intrinsic to how the instances were generated.

Conversion choices

The port is a value-exact relabeling, not a numeric transformation. Two choices are worth spelling out:

Integer milliseconds. This is the first family in the catalog whose time unit is integer milliseconds rather than seconds, declared per instance. The reason is bit-exactness: 91% of the upstream breakpoints are not whole seconds, so any rescale would have broken the exact correspondence with the original data.
A new objective, FleetCostDuration. The upstream objective charges $200 per vehicle plus $20 per working hour. We added native support for it in the catalog’s format and reference checker: cost = sum of per-route optimal durations + 36000000 ms per route, so that the cost in dollars is exactly the cost in milliseconds divided by 180000. Costs map to their published dollar values exactly, without any epsilon.

Hosting is hybrid because a single n=1000 arrival-time-function sidecar exceeds GitHub’s file-size limit (the n=2000 ones reach 386 MB gzipped). The 10 and 500 customer tiers are hosted in full in the satellite repository; the 1000 and 2000 customer tiers host the instance descriptors and best-known solutions, while the oversized sidecars regenerate deterministically from the upstream GitLab data via a published converter, verified against published SHA-256 pins. Two independent conversions on different machines produce bit-identical files.

Best-known solutions, verified before import

The family ships with 40 best-known solutions, one per instance:

30 imported reference solutions from the authors’ BonnTour solver in high-effort mode, covering every city at 500, 1000 and 2000 customers, credited to their team. Before import, every solution was re-evaluated hard-time-window-feasible with the upstream evaluator’s own exact rational arithmetic, then repriced by our reference checker. As a cross-check, the published dollar values of the paper’s Table 2 are exactly the ceilings of the imported costs, thirty for thirty.
10 first-published solutions at n=10, where upstream publishes no solutions. These came out of a first Kayros solver campaign on the family; every city converged to a bitwise-identical best value on 20 independent seeds, which makes them strong candidates for the true optima.

License

Unlike most of the catalog, this family is distributed under CC BY-NC 4.0: the underlying Uber Movement speed data is CC BY-NC 3.0, so every instance and solution file is non-commercial use only, with attribution to the original authors, their repository and the bonndata archive. The full attribution block ships in the satellite repository’s LICENSE.

How it relates to Poryos2026

Readers of my Poryos2026 announcement may wonder how the two families relate, since both build their travel times on real OpenStreetMap road networks. Poryos2026 is in fact inspired by the Bonn benchmark, and the two are complementary rather than competing.

Poryos2026 is designed for comparative studies across the whole problem chain: CVRP, VRPTW, TDVRP and TDVRPTW instances share the same underlying networks and customer locations, so you can measure exactly what adding time windows or time dependence costs. Its congestion comes from traffic models applied to the road networks, and it ships under ODbL.
Blauth2024 is designed for real-world time-dependent benchmarking, with a level of realism Poryos2026 cannot match: its congestion is measured, not modeled, since the Bonn group had access to Uber Movement speed data. The trade-offs are a single problem variant (delivery-only TDVRPTW), a non-commercial license inherited from that data, and travel times that can no longer be regenerated from public sources.

In short: Poryos2026 for controlled comparisons along the problem chain, Blauth2024 for realism at scale under an industrial cost objective.