What makes this vertical distinctive
- Reserved warehouse slots — an early pickup window at the warehouse is reserved for one specific vehicle, on top of the standard hours everyone else sees.
- Load-aware CO2 accounting — CO2 is calculated from the load actually carried per leg, not from distance alone.
- Consolidation loops — a truck with no fixed home base opens and closes its tour on whichever point it visits first, minimizing empty running.
- A real overnight rest — a two-day route plans an explicit rest period, not just a working window that happens to span two days.
Combined example
Reserved warehouse slots
order-warehouse-dock’s window carries resourceTags: ["dock-slot:reserved-a"] — only tractor-reserved-1, which holds that tag, can be assigned this early slot; every other resource is restricted to whatever untagged window exists elsewhere on the same stop. See Restricting a window to specific resources — the exact worked example this follows.
Emissions scaled to load carried
truck-1.CO2EmissionCalculation mirrors the Cost object’s shape: a flat km rate plus costPerCapacityPerTravelledKm, which multiplies the weight actually carried on each leg by the distance travelled. A fully loaded leg reports more CO2 than an empty return leg over the same kilometres, instead of both being priced identically by distance alone.
Consolidation loops
truck-loops-1 has no departure and sets arrival: "atFirstPosition" — its tour closes on whichever stop the engine assigns first, rather than a fixed depot. Paired with order-loop-0’s pickup-then-delivery stops (successiveStops: true, matching weight capacities), this lets the engine build a self-contained loop sized to whatever load it consolidates. See Depot vs. position for how "atFirstPosition" fits alongside a normal fixed departure/arrival.
A real overnight rest
In the full payload, onlytruck-1 works two days. The four other trucks work day 1 only. Without that limit, a truck with no rest to take would pick up the day-2 order and wait at the client all night.
order-day2-delivery has two stops. The goods are loaded on day 1, between 16:00 and 18:00, and delivered on day 2. So the truck that carries them keeps the goods overnight.
The sliding break and the night timeWindowBreak reserve the rest. It falls right after the last stop truck-1 serves on day 1, because, currently, a break is only taken where the vehicle stands. See Where a break can fall.
maxWorkingDuration counts breaks and waiting too. That is why truck-1 has PT37H: it covers both working days and the 11-hour rest between them. With a one-day cap such as 13 hours, both stops of order-day2-delivery stay unplaced, and the engine returns no error.
In the solution, the break starts as soon as that last stop of day 1 is done. It can last more than 11 hours, because waiting at that place is shown as part of the break. For the general pattern, see Modeling multi-day sleepovers.
Full payload
Full payload — ready to submit as POST /plans
Full payload — ready to submit as POST /plans
The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (
workingTimeWindow, departure, arrival), the complete objectives list, and enough orders (including an LTL pickup/dropoff pair unloaded in strict LIFO order) to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own. Its datetimes are local times, read in the plan’s tz (Europe/Paris); see Dates and time zones.See also
- Modeling advanced constraints — multi-day
workingTimeWindowand the sliding break that actually forces rest. - Modeling advanced constraints —
resourceTagson a time window. - Data model —
departure/arrival, including"atFirstPosition".