• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • Dispatch Buses by Voting

    August 19th, 2010
    transport, ideas  [html]
    Most buses in the US run on routes with schedules. There are some problems with schedules. The biggest one is that the real world is not that predictable, so buses are often not on schedule. In an effort to make buses run more on schedule, there will often be downtime built into the schedule where the driver will park the bus somewhere for 5-20min so that the next trip will start on time, which is of course wasteful. Often there will be bunching, where buses on the same route get stuck one behind the other, so you'll get two in quick succession and then none for half an hour. For routes with relatively frequent service leaving from the same station (ex: buses 74, 75, 77, 78, 86, and 96, which all leave from harvard station's bus tunnel) I have another solution:

    Keep the current numbers of buses and routes the same. Train the drivers on all the routes in a pool. Passengers arriving at the station swipe their transit cards on readers indicating which bus they want. Readers do not charge the cards, but they do note the id of the passenger. Passengers can swipe multiple readers in a form of approval voting, indicating that they'd be willing to get on multiple buses (ex: swiping for the 74 and 78, which both run between my work and harvard square) but additional swipes on the same machine would be ignored. Each machine displays it's total for the route. As buses come in they are assigned the route with the most votes and that machine goes to zero (other passengers who swiped on both this reader and another reader are subtracted from the other reader). Passengers may give up or take a bus not in the pool (say a trackless trolley, or even a subway) so after some amount of time (20min?) passengers are assumed to have gotten on a bus they didn't swipe for or left, so swipes are forgotten. Passengers waiting for unpopular buses could then reswipe.

    Update 2010-08-19:Reilly and Becky point out that this has a 'starvation' issue, where unpopular users could end up waiting indefinitely because they give up before enough of them collect to qualify for the next bus. Potential solution: you can swipe as many times as you want, as often as you want. Each swipe tells the system "I'm still here". The 20min timeout becomes an assumption that someone is not still there if they've not swiped in the past 20min. The longer someone waits, the more likely they get their way. Make this exponential, where even one person waiting for 45 minutes beats a busfull waiting for 10min on the grounds that waiting a long time is unpleasant.





    This doesn't account for picking people up enroute, so there'd need to be something in the system to deal with such people. One way is that the buses record data on who got on when, so that could be used to add votes for passengers who presumably would vote to request a bus.

    This system could also work for something like commuter rail trains on the outbound trip.

    Comment via: facebook

    Recent posts on blogs I like:

    What should we do about network-effect monopolies?

    Many large companies today are software monopolies that give their product away for free to get monopoly status, then do horrible things. Can we do anything about this?

    via benkuhn.net July 5, 2020

    More on the Deutschlandtakt

    The Deutschlandtakt plans are out now. They cover investment through 2040, but even beforehand, there’s a plan for something like a national integrated timetable by 2030, with trains connecting the major cities every 30 minutes rather than hourly. But the…

    via Pedestrian Observations July 1, 2020

    How do cars fare in crash tests they're not specifically optimized for?

    Any time you have a benchmark that gets taken seriously, some people will start gaming the benchmark. Some famous examples in computing are the CPU benchmark specfp and video game benchmarks. With specfp, Sun managed to increase its score on 179.art (a su…

    via Posts on Dan Luu June 30, 2020

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact