Mamut2026 (CVRP)

Mamut2026 is the CVRP-only companion to Poryos2026, generated from the same OpenStreetMap pipeline and under the same conventions, but built for a specific experiment: what happens to a state-of-the-art solver when the metric between customers changes? Every base instance is materialized under all three arc-cost metrics — euclidean, shortest, fastest — over identical customers, demands and vehicle capacity, so within a triple the metric is the only thing that varies.

The release contains 330 CVRP instances — 110 base instances materialized under each of the three metrics. A main tier of 100 instances sweeps n from 100 to 1000 over 100 distinct cities, one instance per city; a second tier of 10 larger instances runs from 1200 to 4000 customers, every one of them wholly amenity-sourced. Every base is a genuine multi-vehicle problem — the lightest needs 7 vehicles, the heaviest 508 — and each name carries that minimum the way CVRPLIB's X-n101-k25 does, as a lower bound rather than a fleet cap.

That experiment puts a requirement on the instances themselves. If the base instances all resemble one another, a difference between the metric slices is a statement about those particular instances, and a result on any single slice says nothing about CVRP in general. Mamut2026 is therefore a designed set rather than a parameter grid: one instance per city over 100+ fetched city extracts, with each configuration chosen so that the set as a whole spans the space of instance characteristics.

Two of those characteristics are decided before anything is drawn. Instance size follows a ladder rather than a grid — 100 distinct values of n rising geometrically from 100 to 1000, one per instance, in the spirit of Uchoa et al.'s X set, so size is a covariate you can regress against instead of an eight-level factor. And half the set has customers that are real places on a real map: 50 instances source every customer from OpenStreetMap amenities, 25 mix amenities with sampled road points, and 25 are sampled parametrically to introduce customer geometries a city does not naturally offer.

The amenities are curated for the purpose. Of the 49 amenity categories the platform parses, 35 are premises a vehicle actually serves — restaurants, pharmacies, schools, post offices, places of worship, banks. The other 14 are street furniture and are excluded: measured on these extracts, bench, waste_basket and recycling alone account for 69.9 % of Lyon's amenities, and an amenity=parking node usually marks one individual parking space rather than a car park. Because that curation cuts a city's usable POI count several-fold, each city's ceiling is measured before generation and each rung of the size ladder is matched to a city that can demonstrably supply it. A size no city can serve is reported rather than quietly downgraded, so nothing labelled poi is anything less than wholly amenity-sourced.

Selection is measured, not assumed. A large candidate pool is enumerated and each candidate is described by features computed from its coordinates and demands alone — how clustered the customers are (a Clark-Evans aggregation index), how uneven and how spatially autocorrelated the demands are, how far off-centre the depot sits, the realized average route size, and how tight the capacity is. The published set is the subset that maximizes the minimum distance between instances in that standardized feature space, subject to coverage quotas on every design axis: all seven demand distributions, all seven average-route-size bands, all three depot placements and all three customer placements, with exactly one instance per rung of the size ladder.

One quota is about the experiment itself. Road networks depart from the Euclidean plane by different amounts — a gridded city bends straight lines far less than a river-cut or peninsular one — so each city is profiled beforehand and the selection is required to span low, medium and high road-distortion cities. Every published instance also carries its own measured divergence: mean and 90th-percentile detour over straight-line distance, the direction asymmetry the one-way streets induce, and the Kendall rank correlation between each pair of metrics' orderings of node pairs. That last figure is what makes "does breaking the Euclidean assumption hurt solvers?" a dose-response question rather than a yes/no one.

Conventions are shared with Poryos2026 exactly — 3-decimal float arc costs (seconds for times, meters for distances), sha256-pinned sidecars for the road graph, geographic features and distance matrices, and the hard LB_cap = ceil(sum(q_i) / Q) >= 2 gate that keeps every instance a genuine vehicle-routing problem — so results on the two families are directly comparable.

Licensing note: because this family is generated from OpenStreetMap data, the OSM-derived instances, sidecars, route-rendering artifacts, and related benchmark data are distributed under the Open Data Commons Open Database License (ODbL) v1.0 where applicable, with attribution to OpenStreetMap and its contributors.

Data

Instances and best-known solutions: /benchmarks/cvrp/mamut2026/ on the website. Repository: https://github.com/ANR-MAMUT/MAMUT-routing-Mamut2026.

This family is one problem-type layer of the Mamut2026 collection; the collection README (layout, conventions, sidecars) is on the collection page.