none
MIO API | Flexible dwelltime RRS feed

  • Question

  • Hello,

    is it possible to have a flexible dwell time?

    Background:
    I'm trying to use MIO for Ride-Pooling/-Sharing. Thererfore the dwell time for a Stop is 0, because the passenger only leaves the vehicle.
    The problem: A vehicle has already a tour with other passengers. If a new passenger requests a ride and wants to be at his destination at e.g. 4pm (+/- 5 minutes). So I'm calculating the pickup-time by subtracting the direct travel duration + offset of 15 minutes (the ride shouldn't take longer than direct duration + 15 minutes). As the last ride for the vehicle is at 3pm, the new passenger's pick up time is the earliest calculated (arrival - direct duration - 15 mins). At this time slot, the passenger is the only customer, so it won't take longer than the direct travel duration, which leads me now to my issue: Ride takes 5 minutes, but arrival time is pick up time + 15 minutes (because of the offset).
    The solution for me would be, that the driver waits at the pickup stop for e.g. 15 minutes.

    Very complicated, but I hope it's almost clear :)

    Summary:
    Customer wishes to arrive destination at 4pm (+/- 5 minutes)
    No other customers at this time
    Calculated pick up time between 3:30pm and 4:09pm
    MIO takes the earliest pick up time and calculates a travel duration of 5 minutes 8 seconds
    MIO returns a arrival time of 3:55pm, because of the priviously defined time window
    --> Solution would be, that MIO automatically schedules a dwell time of 10 minutes at start point.

    Thursday, July 30, 2020 7:19 AM

All replies

  • Hi j.punz,

    This does not sound like a MIO scenario. Let me see if I have this correct.

    1. A driver has capacity for x passengers in their carpool vehicle and is willing to accept ad-hoc extra riders if they have less than x people

    2. Likely distance matrix or MIO is used ahead of time by the carpool/ride share service and people are assigned to that vehicle based on the most efficient carpool option, likely they live on a reasonable route for that driver and work near where that driver works

    3. If a new passenger request arrives, it would come to the carpool service and they would need to detect which vehicles are near that route at that time and choose from that smaller set then offer that passenger to that set of available drivers to accept  

    4. When the driver accepts that passenger, their route will update to include that passenger.  This is a single route call rather than a matrix

    Sincerely,

    IoTGirl

    Thursday, July 30, 2020 4:10 PM
    Owner
  • Yes that's all correct.

    What I haven't described before: We are calling MIO for e.g. 3-5 vehicles, as this is depending on the operating area. A score is calculated, which is just the change of total distance in the tour of the day (which is just the distance needed for all passengers).

    So my main problem is, when the driver has (at the time of the new booking) passengers until 3pm and there is a request for a ride at 4pm, MIO uses (of course) the earliest starttime given by my software.

    For example:
    Driver has passengers until 3pm
    Request for a ride with arrival at destination of new passenger at 4:30pm
    Software calculates a arrival time window between 4:25pm and 4:35pm
    Afterwards a start time window is determined by subtracting the direct driving duration (without any other passengers, e.g. 10 minutes) from destination time window. Additionally a deviation of direct driving duration (15 minutes) is considered, as it could be, that at this time is another booking.
        Pickup time window start = 4:25pm - direct driving duration - 15 minutes = 4:00pm
        Pickup time window end = 4:35pm - direct driving duration =  4:25pm
    --> Now MIO encounters a pickup time of 4pm (as the vehicle is empty before) and driving duration of 10 minutes - BUT: dropoff starts at 4:25. Ideally MIO delivers a dwell time at the destination of 15 minutes and says dropoff at 4:10pm - even better would be a desired pickup time and dwell time there (but that's only the a "nice to have" :D ).

    I hope it's now a little bit more understandable. I hope there is an option/solution for my problem - otherwise I have to implement something for that special case.

    Sincerly,
    Jürgen

    Friday, July 31, 2020 6:04 AM
  • Hi Jürgen,

    It still seems like overkill to call MIO for this. In your scenario, the car is empty and this is a single trip with a single start and end point so I am not sure why dwell time would be a factor.  

    You just need to choose the closest car in this scenario and add waypoints for the pick up and drop off to find which has the best. This is 3-5 routing calls rather than the more intensive MIO call.

    You are now in a "Taxi" scenario rather than a scheduled carpool.

    I have asked the Routing Team to take a look at this posting and I will let you know if they have any suggestions.

    Sincerely,

    IoTGirl

    Friday, July 31, 2020 5:20 PM
    Owner
  • Hi,

    yes that's right - in that scenario the car is empty for the new passenger. But I think that's a case (pickup time + driving duration != drop off time) which can also occur, while another passenger is on board.

    For me it's not a problem, which i can't solve with some lines of code - it was just a question, if there is a possibility without writing some extra code ;)

    I hope everything was clear :)

    Monday, August 3, 2020 10:31 AM
  • Hello,

    any news concerning my "issue"?

    Regards,
    Jürgen

    Tuesday, September 1, 2020 11:29 AM
  • Hello Jürgen,

    The team has been working on improving the speed of the current implementation and recently announced larger values available per call.  You can check out the documentation for those updates.

    I have no news on your feature request.

    Sincerely,

    IoTGirl


    Wednesday, September 2, 2020 10:09 PM
    Owner