DRT with ortools
Ticket for tracking the progress of the tool drtOrtools.py.
Features
- [ ] add support for time windows
- [ ] handle pre-booking in SUMO
- [ ] considers current plan as initial solution
- [x] include occupied vehicles for solution with new requests
- [x] add disjunction for the new requests for the case that there is no solution and some have to be droped (and thus guarantee service for the old requests)
- [ ] support more than one vehicle type
- [ ] initialize cost_dict in run() and update for speed improvement
- [x] find out why traci.person.getTaxiReservations(0) is needed
- [ ] Direct route factor
- [ ] Maximum waiting time
General support
- [ ] add support for Python 2
- [ ] fix different test results on Linux
Code quality
- [ ] improve debbuging information
- [ ] add unit tests
find out why traci.person.getTaxiReservations(0) is needed
Retrieving a reservation once, changes it's state from NEW (flag = 1) to RETRIEVED (flag = 2).
This controls whether a subsequent call to getTaxiReservations(2) will return them.
If you replace these calls with getTaxiReservations(3) (which returns NEW and RETRIEVED), then the prior call is no longer needed.
My description above described the intention of the code but there was still a bug: #11501
find out why traci.person.getTaxiReservations(0) is needed
Retrieving a reservation once, changes it's state from
NEW(flag = 1) toRETRIEVED(flag = 2). This controls whether a subsequent call togetTaxiReservations(2)will return them.If you replace these calls with
getTaxiReservations(3)(which returns NEW and RETRIEVED), then the prior call is no longer needed.
Can you add this (and maybe other missing reservationStates) to the documentation? https://sumo.dlr.de/docs/Simulation/Taxi.html#gettaxireservations
see test for the previous commit here: https://github.com/eclipse/sumo/commit/dfc6843d31cda559ae1e2656adb67fce44e23860
The disjunction effects the result, if there is the possibility of getting no solution. This happens only if there are more restrictions (as time windows or direct route factor). So there is still no test possible.
commit for drf see: 864d0580b50b75841593fcdf73555f9f81e2d9cb
Changing cost type to "time" should reduce the needed time. Using this in the test cases, the time seems to increase (see test drtOR-Tools_twoTaxis). Could be a problem of the solver...
Prebooking can be used now with params in ride:
<param key="earliestPickupTime" value="..."/>
<param key="reservationTime" value="..."/>
The reservationTime defines the time the reservation is created. The earliestPickupTime means the expected arrival time of the person. reservationTime can be smaller than the depart of the person.
The ride needs the from attribute. The route file must be loaded as additional file.
If taxi and customer meet before earliestPickupTime, they are going to depart earlier.
If taxi and customer don't meet (because the customer comes too late) the taxi waits for 3mins after earliestPickupTime and then reject the reservation.
Greedy and greedyShard are using earliestPickupTime to sort the reservations (not the reservationTime).
TODOs:
- [ ] Waiting time if the customer comes too late is hard coded to 3mins, needs an option to customize
- [ ] Check merged reservations due to common start or end positions (in MSDipatch::updateReservationFromPos)
- [ ] Check group reservations with different arrival times of the customers (especially if some customers miss the taxi and others do not)
- [x] Add tests for many and combined reservations
- [x] Add documentation
- [ ]
fromattribute should be avoided
- what about documentation?
- is the ride
fromneeded even if the ride is not the first part of the plan? This need should be avoided
Yes, documentation is still open.
from is needed, because the from edge is not always clear, especially in connection with accesses.
I updated the todos.
I see the problem of missing from in combination with access (#14435)
Thanks for the advice. I add this to the TODOs. I need to check merged reservations anyway.