Background

Public transport

The current state of public transport is pitiful. It hasn’t changed in almost 100 years. A simple Google Maps search can demonstrate that the length of time it takes for a bus to get from point A to point B is 3 times longer than it takes a car. Besides being slow, public transport is also expensive and inefficient. Transit buses are usually almost empty and have a gas mileage of 3.26mpg, versus the 23.41mpg of a car. Further, public transport is rigid and user unfriendly. Bus schedules are set months in advance on the basis of historical data. Such a system does not adapt well to disruptions.

The sorry state of the public transport system is one of the major reasons people choose to drive.

And how to fix it

Make public transport serve the people instead of the other way around. Lyft and Uber have proven that private transport can be made more efficient than the taxi system. A similar principle can be adapted to public transport, and can provide larger gains in efficiency. Each patron of such a system would have a smart phone with an app with which they can make a request for transport to whichever destination they desire. All the requests would be processed in a Central System which would then calculate the optimal routes and distribute public vehicles accordingly. The vehicles would be equipped with another smart phone directing them where to go and whom to pick up. The patron would then get a confirmation of their request along with the estimated waiting time and the estimated time for the arrival to the final destination. The Central System would group nearby patrons desiring similar destinations in the same vehicles.

For such a system to be efficient, it is necessary to have vehicles of different sizes. Smaller size vehicles would serve less dense areas and non-peak hours. Somewhat similar to the “park and ride” systems, larger vehicles would transport larger number of riders from one side to another side of the city. Smaller vehicles would gather riders to the larger vehicles, and on the destination side, smaller vehicles would distribute riders to their final destinations.

Value propositions

Would this system be faster?

Undoubtedly yes. As soon as a patron makes a request, the Central System would calculate the optimum route based on the final destination and would reroute the closest/best suited vehicle for pick up or assign an unused vehicle to the task. To avoid wait times due to transfers between vehicles, the Central System would time the arrival of the smaller vehicles to arrive at roughly the same time as the larger vehicle.

Furthermore, this system would be able to instantly adapt to new conditions by adding more vehicles in times of need or taking unused vehicles off the road.

Would this system be less expensive?

It should be. The cost savings come from better utilization of vehicles, as vehicles would only be deployed when needed. In addition, smaller vehicles cost less and utilize less gas than larger buses. As well, cost savings come from more optimized routes, which travel shorter distances while carrying the same or larger number of passengers. Cost savings climb as the ridership and the number of vehicles climbs.

Proving the concept

There already exist datasets which can be used to test this theory. Among others, Brisbane and Singapore collect data with start and end points for each trip taken (“tap in” and “tap out” data) for all their public transport patrons. Given the originating point, destination point, and the originating time of day, this data can be used to simulate the solution proposed. By running multiple simulations with different variables, including the number of vehicles, the ratio of smaller to larger vehicles, the number of available drivers, the number of transfers, the average time of waiting for transport, and the fuel consumption, an optimum set of variables can be chosen.

Would it be too expensive to throw away a large number of buses and replace them with smaller vehicles?

It is not necessary to make such a drastic change. Every public transport system replenishes their fleets yearly, retiring older buses and buying new ones. The change in the fleet could be achieved gradually by buying smaller vehicles instead of traditional buses for a few years until the optimum fleet configuration is achieved.

What would the drivers gain from this system?

In the existing system, drivers have little flexibility in choosing their shifts. This system would allow for drivers to pick their working hours. The system could incentivize drivers to drive at the times of greatest need by giving higher wages.

For the system to achieve maximum efficiency, it is necessary to have an optimum number of drivers on the road at all times. This can be achieved by giving drivers freedom to choose. For example, they might be allowed to choose 80% of the times they want to ride but might be obligated to drive 20% of the time when the Central System needs drivers but has no volunteer drivers available.

How would this system be able to adapt to new conditions?

The proposed solution should be much better at reacting to congestion, accidents, and other disruptions. The Central System would possess knowledge of the positions and speeds of all vehicles, and would utilize traffic data from sources like Google Maps and alike. This would allow the System to avoid congested areas and reroute traffic in real time.

How to get cities to undertake this change?

Most people cringe when faced with the prospect of trying to introduce a change in municipal governance. However, there are hundreds of thousands of cities in the world wrestling with the public transport problems. Armed with the simulation results showing advantages of the proposed solution, it should be possible to persuade at least a few cities to switch to the new system. Given the nature of the solution, it is very likely that these first projects would be widely publicized, especially if the results are higher user satisfaction, lower cost, less pollution etc. This should result in a push by citizens in other cities to adopt a new system and give city councillors ammunition for the change.

Requirements

Input data

Data set containing tap-in, tap-out information for a representative city for a period of time.

Map of the city.

Among others, Brisbane and Singapore collect data with start and end points for each trip taken (“tap in” and “tap out” data) for all their public transport patrons.

Use existing infrastructure - subway, tram, train, ferry

The simulation needs to be able to stipulate “hard-coded” routes with “hard-coded” stops for the existing infrastructure.

hybrid model – mix of hardcoded schedule + dynamized schedule

It is likely that client cities will want to switch to the new system gradually, over a period of months or even years. The simulation should be able to import existing bus/tram/train/ferry routes and schedules and use them together with the dynamized vehicles. The imported data would effectively define the percentage of the rides fulfilled by the old vs new system.

This should be done in conjunction with the “use existing infrastructure” requirement – the implementation should be common for both.

The hybrid simulation using e.g. Brisbane data set would import the routes and schedules for the vehicles in the old system, but would use the actual travel data for these vehicles from the data set. This will enable a more realistic simulation.

Route

Each route has GPS coordinates translatable to the streets on the map.

API

Use Google Maps API or a different suitable API, to calculate routes.

Ensure repeatability by ignoring traffic congestion when asking Google Maps for routes.

Traffic congestion data

Ensure that the simulation does not ignore traffic jams, congestion, slowdowns which are present in the input data. (Using existing API like Google Maps will insure this.)

Simulation timing

The simulation should be run without any “peeking into the future”. The simulation should run sped up X times, but the timing of the requests (corresponding to the tap-in data) should be preserved. Also, care should be taken to ensure that the simulation is not affected by the fact that Google is calculating routes for a live city for the simulation – i.e. running the simulation during peak traffic hours may result in slower results if traffic congestion information is not ignored in API requests.

Route planning

Uses tap-in time and location and tap-out location. (Tap-out time will be the result of the simulation)

Adaptable for different cities

The simulation infrastructure should be created in such a way to allow reuse for different cities:

using different maps, type and number of vehicles, existing infrastructure (subway, tram, train, ferry…)

Two types of vehicles: large (bus) and small

Vary the small vehicle size

Vehicle size, especially for the small vehicle, needs to be configurable so different simulations can be done to determine the best vehicle size.

Google uses Chrysler Pacifica minivan which has 8 passenger seats and can drive 55km on an electric battery.

https://tech.slashdot.org/story/18/11/14/0152236/waymo-to-start-first-driverless-car-service-next-month

TBD: calculate fuel savings with hybrid cars – e.g. Chrysler Pacifica saves 55km every day. It can save more if it can be recharged while not in use.

Preferred stops

The system should give preference to existing bus stop locations because they have already been cleared as safe to use for buses. Therefore, even if a patron requests a service when away from a bus stop, he/she should be made to walk to the bus stop, unless being picked up by a car, in which case there is more flexibility.

Sharing of bus stops

Use bus stops for small vehicles as well but ensure that it is not used by a bus at the same time.

No stops on certain roads

E.g. no stops on highways.

Output

Maximum and average time of waiting for transport (output result)

Maximum and average time of waiting between transfers (output result)

Total fuel consumption (output)

Total vehicle hours travelled (for each vehicle type)

Number of kilometers travelled by vehicles

Maximum and average travel on foot

For each simulation run:

List of passenger routes

List of vehicle routes

Variables

It must be possible to run the simulation over and over with different parameters. The purpose for this is to identify the optimum set of parameters for the cost/convenience analysis. This is not very well thought out - some of these variables will end up as the output statistics instead…

Average trip time (output result)

Maximum and average number of transfers (input)

Maximum number of large vehicles (input)

Maximum number of small vehicles (input)

Average number of active large vehicles (input)

Average number of active small vehicles (input)

Average utilization of vehicles (input and output)

Avg. number of passengers vs maximum the vehicle can accept. All these “number of vehicles” variables are inter-dependant. However, we need to be able to tune vehicle these numbers. E.g. make the “sensitivity” to the need for more vehicles tunable: wait until utilization is 100% for all vehicles in an area before deploying another vs. as soon as the utilization in a small area is 50%, deploy another vehicle…

Maximum number of available drivers (input)

Average number of active drivers (input)

Number of kilometers travelled by vehicles (input and output)

The routes asked for from the API can be optimized for speed versus distance.

Maximum and average travel on foot (input and output)

Input data only has the tap-in, tap-out data – not the additional travel on foot data. Our simulation needs to allow for a certain travel on foot to pick-up, from drop-off and, if necessary for transfers.

When comparing with input data, we would need to make some assumptions regarding the average food travel – for example based on the average half distance between bus stops.

Simulation needs to provide the backbone for the real-time trip handling in a delivered product.

Even though the simulation has no real time requirements, it would be very beneficial if the route planning code can be reused in the deployment.