Ben Leizman

ORF 476-Transportation Systems

Professor Kornhauser

5/6/23

Trip Arrivals and Departures for Burlington and Ocean

Counties

Introduction

The goal of this project is to determine how to effectively and dynamically reallocate aTaxi in a

fleet throughout the day. This reallocation enables the fleet owner to use the minimum number of

aTaxis to satisfy all of the trips throughout New Jersey. To begin this analysis, we must look at

the aTaxi imbalance in each county throughout the day.

Burlington County Imbalance

Figure 1)

aTaxi Imbalance in Burlington County, by type

1

Most interesting in this data is that there are more daily arrivals than departures for the

Bur2 subset of Burlington County. This may be due to errors in the data. Also, the extreme daily

2 passenger imbalance for Bur1 is likely due to an error in the data.

Figure 2) Hourly aTaxi Imbalance in Burlington

2

Ocean County Imbalance

Most notable in this data is the extremely high 20 and 50 passenger vehicle imbalance in the

subset Oce2 of Ocean County. Again, we can only attribute this to possibly malformed data.

Figure 3)aTaxi Imbalance in Ocean County, by Type

3

Figure 4) Hourly aTaxi Imbalance in Ocean County

4

Imbalance Graphics

Figure 5) Daily Vehicle Imbalance by Subcounty, with each line marking 25,000 vehicles

Figure 6) Daily vehicle imbalance by county, with each line marking 20,000 vehicles

5

Figure 7) Hourly vehicle imbalance, by subcounty, with each line marking 5,000 vehicles.

Double click the image to compare all 24 hours.

Figure 8) Hourly vehicle imbalance, by subcounty, with each line marking 10,000 vehicles.

Double click the image to compare all 24 hours

6

Figure 8) Daily vehicle imbalance by subcouty and vehicle type

Imbalance CDFs for Burlington County

7

8

9

Imbalance CDFs for Average Pixel in Burlington County

10

Imbalance CDFs for Ocean County

11

Imbalance CDFs for Average Pixel in Ocean County

12

Empty Vehicle Reallocation Analysis

In order to optimally redirect empty aTaxis to a necessary location, we would implement

three different data structures: one for taxis, one for queries, and one for mapping taxis to

queries. The taxi information is stored in a list of arrays containing 6 values each. The first

column is taxi identification number, second is x position, third is y position, the fourth is a

status, the fifth is the expected drop off time (updated after drop off), and the sixth is a query ID.

In the fourth column, the status 0 signifies the taxi is stationary, 1 signifies it is empty and on the

way to pick up, and 2 signifies nonempty and on the way to drop off. Once a taxi is paired with a

query, it stores that query ID. All initial statuses are 0 and Query Ids are NULL. The taxi list of

arrays would look something like this:

13

Taxi ID X position Y Position Status tDrop Query ID

46872 115 134 2 54323.2 73620

46873 103 121 0 NULL NULL

46874 131 123 1 81034.1 35038

46875 118 137 2 73240.4 57392

Figure 9) Taxi data structure

Queries are stored in a list of arrays with 7 columns. Similar to the taxi array, the first

column is the query identification number, second is x position, third is y position, fourth is an

expected time of pick up (updated after pick up), fifth is expected time of drop off (updated after

drop off), the sixth is a status, and the seventh is the taxi ID. In the fourth column, a status of 0

signifies not yet picked up, 1 signifies picked up and en route, and 2 signifies dropped off. The

taxi ID is helpful in locating a client. The list would initially be empty. When a query comes up,

it would be added to the list. Once a query is assigned has an aTaxi en route, the Taxi ID

updates. All queries added to the list would have an initial status of 0 and Taxi ID of NULL. The

query list of arrays would look like this:

Query ID X position Y Position Status tPick tDrop Taxi ID

92482 132 149 2 25230.3 28535.3 46845

92483 124 126 2 39538.4 40042.5 46893

92484 142 127 1 67382.4 67892.5 46730

92485 118 135 0 NULL NULL NULL

Figure 10) Query data structure

14

Both the taxi and query data structures have the ability to grow or shrink. The taxi

structure will initially start with a certain number of taxis. This fleet size can easily grow if more

taxis are added to the fleet or shrink if a taxi breaks down. The query data structure is initially

empty and queries are added as they come. Since the query list continuously grows, at midnight

every night, all queries with a status of 2 (almost all of them) are moved to a long-term storage

structure or simply cleared. Thus, at midnight every day, the query data structure resets.

The program sending taxis to people would be a loop that runs every 5 minutes. It would

run through the taxi list and put the x and y coordinates of any query with a status of 0

(stationary) into a separate 2 by i array, where i is the number of taxis that do not have an

associated query. It would also add to the query any taxis with status 1 (en route) that have a

drop off time before 300 seconds + current time. It would then run through the query list and put

the x and y coordinates of any query with a status of 0 (not picked up yet) into a separate 2 by j

array, where j is the number of queries needing to be handled. The cost of the edge going from

taxi a to query b is equal to 1.2 times the Cartesian distance. If the cost of a taxi is greater than 5

for a taxi leaving at the current time, the cost is automatically set to infinity. You then solve the

optimization problem, minimizing the cost. After the optimization problem is solved, if there is a

query that has no taxi assigned to it, a new taxi is added to the taxi list with the location of query

and is assigned to that given query. These extra taxis added after the optimization problem is

completed are taxis that must have been waiting there from the previous day.

15