What makes this vertical distinctive
- PUDO gated by capacity — a PUDO pickup only gets scheduled once the vehicle still has room for it, not on a fixed slot regardless of load.
- Preferred zones — drivers are softly tied to their usual sector, and only pulled elsewhere once it’s been served or would otherwise overflow.
- Mixed last-mile fleet — vans, bikes, and walkers each cover the part of the city they’re actually suited to.
- Predictive traffic — forecast travel time is baked into the route calculation itself, not patched onto the result afterward.
Combined example
Gating a pickup by remaining capacity
order-late-pickup’s stop carries no time window of its own. Instead, every delivery stop carries nbDeliveries: 1 and the PUDO pickup carries nbPickups: 1, both counters also declared on each resource, and an atLeastOneValidCapacity constraint requires, at every stop, at least one of three things to hold: no delivery left on board (nbDeliveries: 0), no pickup done yet (nbPickups: 0), or no more than 300 kg on board (weight: 300). Since nbPickups never drops back to 0 once the pickup is loaded, the engine can only place it once the vehicle’s deliveries are done or its load is light enough, which in practice pushes it toward the end of a round rather than the start. See Sequencing pickups after deliveries for the same pattern traced step by step.
Preferred zones
van-1.preferredStopTags: ["zone:usual-sector-7"] is matched against the same tag on stop-customer-1. This is a soft pull, scored through the maximizePreferredStops objective, not a hard restriction — a van without spare capacity in its sector still gets sent to overflow stops tagged zone:overflow elsewhere. It’s the same preferredStopTags mechanism Driver skills and qualifications documents for a skill preference, applied here to a zone instead.
Mixed last-mile fleet
vehicleProfile.type differs per resource (car, bicycle, pedestrian), each sized with its own capacities — a walker carries a handful of parcels, a van dozens. The engine assigns each stop to whichever profile can legally and practically reach it. See Vehicle profiles.
Predictive traffic
van-1.vehicleProfile.withTraffic: true makes the engine use forecast travel times for that vehicle’s legs instead of free-flow distances, so the plan already accounts for congestion rather than needing a correction pass after the fact.
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 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.See also
- Modeling advanced constraints — the
atLeastOneValidCapacitymechanism behind PUDO gating. - Modeling advanced constraints —
preferredStopTags, the soft mechanism behind zone preference. - Data model — vehicle profile types and the fields that vary per profile.
- Data model — the full
additionalConstraintsandglobalConstraintscatalog.