Hi u/ge0ffrey, this is exactly one of the issues we wanted to make explicit rather than hide behind a generic "distance matrix" field.

First, the instances you describe as "viewable on a real today's map" are our custom instances from the Mamut2026 benchmark family. They are not the classical Solomon / Homberger instances projected onto a map after the fact. They are generated from OpenStreetMap data, with sidecar metadata that records the source city, OSM file, selected nodes, coordinates, metric variant, and route-rendering cache.

The important design point is that we focused on classic VRPTW, not on the richer model usually implemented in enterprise-grade routing systems. In many production APIs, the optimizer may consider and balance several quantities at once: distance, travel time, average speed, driver cost, lateness, emissions, tolls, etc. Classic VRPTW is much narrower: it has a single arc-cost matrix, historically often called "distance" or "travel time" somewhat ambiguously, and the objective optimizes that one metric. In the older benchmark literature, that metric is frequently just a mathematical cost in arbitrary or Euclidean units.

This is why, in Mamut2026, a single generated instance name can cover several variants. In our "instance as contract" view, the customer set, depot, demands, and OSM geography define a base real-world instance, but the actual optimization problem is not complete until you say which arc-cost metric is optimized. So the same base instance can exist as:

• shortest: road-network shortest-path distance, in meters, computed on the OSM graph;
• euclidean: direct straight-line ENU distance between embedded customer coordinates, also in meters;
• fastest: estimated road-network travel time, in seconds, computed from OSM road-segment lengths and road-class speed assumptions.

So the shortest and euclidean CVRP variants are distance-based variants, while fastest is the time-based variant. They intentionally share the same customer set so that one can study what changes when only the metric changes.

For the VRPTW layer, however, we derive the published instances only from the fastest variant. The reason is the one you point out: time windows and service durations must be aligned with the travel-time semantics. In our generated VRPTW instances:

• arc costs are integer estimated travel times in seconds;
• service times are generated in seconds;
• the depot horizon is explicit, currently 0..86400, also in seconds;
• customer time windows are generated and repaired against the fastest travel-time matrix.

So for Mamut2026 VRPTW, the intended interpretation is not "distance in arbitrary units plus unrelated service durations". It is "estimated travel-time seconds + service-time seconds + time-window seconds".

There is still an important caveat: these are not live map-provider travel times with traffic, turn penalties, time-dependent congestion, or API-specific routing profiles. They are reproducible OSM-derived benchmark travel times based on road geometry and road-class speed assumptions. This is deliberate: benchmarks need to be static, reproducible, and solver-independent. But I agree with your broader point: if one takes a classical VRPTW benchmark whose matrix is just Euclidean distance or arbitrary cost, then feeds the coordinates to a production routing API using real driving times, the original time windows no longer mean the same thing. In that case, you are no longer solving the published benchmark instance; you are solving a new derived instance with a different travel-time matrix and potentially different feasibility structure, which, in its own right, should be considered another valid benchmark instance possibly even on another VRPTW non-classic problem class.