Time cost for shipments like with vehicles

[jwoyame]

A few use cases exist for adding time-based penalties for a shipment:

• Human or animal transport (establish a degree of circuity for the trip as in VRP literature)
• Perishables (warm pizza delivery, refrigerated product)

Currently, a pickup can be made which will sit in a vehicle for several hours. The only way around this is to use time windows on the pickup and the delivery job. Adding a time window requires picking a very specific time in advance.

I had previously submitted a proposal for a hard constraint between time windows to solve this (#703), and @jcoupey pointed out the difficulties of enforcing the two-way relationship between pickup and delivery. However, it seems possible that a cost-based alternative might be easier and even more flexible:

• With the soft constraint, a delayed shipment will not be rejected entirely.
• Some shipments may be less desirable to transport / consume more resources: more weight, more risk (fragile or very expensive item), or opportunity cost (something bulky but with low value). Applying the cost per unit of time can model some problems better than a fixed cost.

#528 added a per_hour cost for vehicles:

"cost": {
  "fixed": 0,
  "per_hour": 3600
}

Adding a similar time-based cost for shipments would look like the following:

"cost": {
  "fixed": 0,
  "per_hour": 3600,
  "start_time": 0
}

Note the fixed cost is similar to the existing service cost on jobs, but without affecting the vehicle's schedule. Also note the extra start_time property for when the linear time cost begins to apply. The start time would enable a situation like pizza delivery, where a large time penalty only begins to be applied after 30 minutes. Or, for human transport in a multi-rider vehicle, you could start applying a penalty only for time that exceeds the user's direct travel time. If a rider could get from A to B in 15 minutes with no one else in the vehicle, then a pooled ride would have a penalty that starts applying for that rider after 15 minutes.

[jcoupey]

#703 was about enforcing a max time gap between pickup and delivery at validity level, with a hard constraint discarding all gaps over a given value. This new suggestion moves the idea to the cost evaluation (rather than validity), penalizing extra time over a gap. From a pure modeling perspective, this is indeed more flexible, but unfortunately, the reason why we can't assert the time gap validity also applies here: we can't evaluate the penalty in a cheap way.

We only store margins for tasks (earliest and latest dates), because this is enough to decide validity upon route changes in a cheap way. In short: it allows to decide validity or determine cost changes without the need to iterate over a whole route. The actual ETA are only determined after solving, when formatting the solution. The drawback is that just like we can't really evaluate the time gap for #703, we can't measure the actual penalty that would have to be applied.

[jcoupey]

Closing as not actionable.