Dynamic service time // group activities together

[quiqua]

Description

This is a naive proof of concept to group activities at the same location with different service times together.
It has been requested / discussed several times in the forums: 1, 2, 3.

Let's consider this route:

• service time for new shipment: 60
• service time for existing shipment: 120
• pickup locations for both shipments are the same
• dropoff locations for both shipments are the same

Vehicle_Start --> New Shipment_Pickup -> Shipment_Pickup -> New Shipment_Dropoff -> Shipment_Dropoff  -> Vehicle_End

Before this change, we would get something like:

+--------------------------------------------------------------------------------------------------------------------------------+
| detailed solution                                                                                                              |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| route   | vehicle              | activity              | job             | arrTime         | endTime         | costs           |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| 1       | vehicle              | start                 | -               | undef           | 200             | 0               |
| 1       | vehicle              | pickupShipment        | new             | 260             | 320             | 60              |
| 1       | vehicle              | pickupShipment        | shipment        | 320             | 440             | 60              |
| 1       | vehicle              | deliverShipment       | new             | 500             | 560             | 120             |
| 1       | vehicle              | deliverShipment       | shipment        | 560             | 680             | 120             |
| 1       | vehicle              | end                   | -               | 680             | undef           | 120             |
+--------------------------------------------------------------------------------------------------------------------------------+

Afterwards, it will change to:

+--------------------------------------------------------------------------------------------------------------------------------+
| detailed solution                                                                                                              |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| route   | vehicle              | activity              | job             | arrTime         | endTime         | costs           |
+---------+----------------------+-----------------------+-----------------+-----------------+-----------------+-----------------+
| 1       | vehicle              | start                 | -               | undef           | 200             | 0               |
| 1       | vehicle              | pickupShipment        | new             | 260             | 380             | 60              |
| 1       | vehicle              | pickupShipment        | shipment        | 260             | 380             | 60              |
| 1       | vehicle              | deliverShipment       | new             | 440             | 560             | 120             |
| 1       | vehicle              | deliverShipment       | shipment        | 440             | 560             | 120             |
| 1       | vehicle              | end                   | -               | 560             | undef           | 120             |
+--------------------------------------------------------------------------------------------------------------------------------+

This is a rather naive approach by adjusting the times computed in the class UpdateActivityTimes.

The implementation of this was done after all activities have been inserted into a route, when calling the finish() method of this state updater.

If two or more activities at are happening at the same place and time, then they could be grouped together, having identical arrival and end times and adjusting the following activities accordingly by the time that has been saved.

[quiqua]

@oblonski could you check out this early draft of a PR to exchange some ideas and feedback on this?

[quiqua]

Hej @oblonski! Happy to report that I overhauled the implementation of using a dynamic service time for the activities.

I've added one integration example as well as some test cases for the UpdateActivityTimes class to check different scenarios.

I don't know if this behaviour should be enabled by default though or if it should be controlled by a toggle.

Happy to get some feedback on this.

[waldobeest]

Interesting observation when running the PR above.

It seems as though the code is run after a route has been generated, to return the route to be newly timed route (through the .finish() code).

Practically, what this means, is a route which uses a vehicle type which available for 12 hours, will take a 12 hour route with sites loaded adjacently (i.e 3 x 30 minute loading at the same site), and will generate a newly timed route being 12hours - 60 minutes, so will at most ever be 11 hours utilised. In theory, the newly timed stops may be violating time windows as well (TBC).

Will revert if I have more information, or a solid approach to using the above code.

[quiqua]

Yeah there are some more missing things for this to work properly, especially for each Insertion class.

I didn't find the time yet to further improve the PR.

[waldobeest]

All good, was running into the same problem as yours and was wondering if I could use your PR! I ended up taking a different approach which is proving promising, but not without challenges! You can see those changes here