ShortBusRide

James Baker
Eugene Hsu
Roko Kruze

1 Abstra t:
Trying to nd the bus that one should take to get some where is always a daunting task.
With only maps of bus routes and bus s hedules one ould very easily miss the best route
to their destination. The idea behind this model is to be able to nd a path between two
points taking into a ount transfer times and the time one leaves.
The way in whi h this model solves the problem is by using Dijkstra's algorithm to solve
the shortest path. Ea h bus stop will be made up of many sub-stops. Ea h sub-stop will
represent a bus oming into the stop or a bus leaving the stop. This will allow Dijkstra's
algorithm to be able to a ount for transfer times.

2 Problem Des ription:

The ore problem for this model is nding the best bus route(s) to a lo ation. This is
a problem that fa es many people ea h day. The only way today to nd the best bus
route(s) is to look through the long lists of bus s hedules on Metro's web site or all one
of Metro's ustomer servi e representatives.
This being the motatve behind the proje t we set out to model the problem as a simple
graph.

Having the problem in a simple graph stru ture allows for algorithms su h as

Dijkstra's to be applied to it.

Solving for the best bus route(s) will yield to nding the shortest time between two
lo ations. In order to nd this time the model must also take into a ount bus transfer
and the time spent waiting for a bus.

Also one might want to have no less then a 5

minutes between transfer points, due to the unpredi tability of buses.

One question that had to be addressed was that of would Dijkstra's algorithm hold for
this problem? With giving the model a olle tion of sub stops for ea h bus stop allowed
Dijkstra's algorithm to work with this problem. Another requirement of the problem was
that of having variable edge weights sin e a bus might take longer depending on the time

ShortBusRide

of day. To get around this we allow the sear h to do look up alls whi h will s an the
time tables instead of doing the edge weight look ups itself. This is explained in further
detail in the implementation and theory se tion.

3 Implementation details
The implmentation is overed as follows: rst, a high-level English des ription of how
we model the bus system, followed by a brief des ription of the data format and data
stru tures, and we on lude with a pseudo- ode implementation of our algorithm.

3.1

Model des ription

This se tion outlines how our model works to give a general sense of how things t
together, but the a tual implementation details are des ribed later on.

3.1.1 Modeling a path

To nd the best path from one arbitrary point to another, we must rst abstra t the
problem of riding the bus into an easy-to-model graph problem.

It's probably easiest

to start by on eptualizing ea h stop as a vertex, and the edge weights as the ride time
between stops.

We ould then apply Dijkstra's algorithm to the graph and nd the

shortest possible ride time.

Figure 1: Simple model of bus routes.

Rt. 1

Stop A

Rt. 1

Stop B

Rt. 2

Stop C

Rt. 2

Rt. 2
Rt. 3

However, this is an over simpli ation: we ignore the fa t that as we ride along the route,
the time hanges, and as the time hanges, some edge weights between stops be ome
longer or shorter, appear or disappear. To get around this, at ea h vertex al ulate edge
weights based on what time it is (the departure time plus the travel time) at that vertex.
In other words, edge weights are a fun tion of path length.
Still, we are over simplifying. At ea h stop, we have the option of getting o and transfering to another bus. If we were to model ea h stop as a single vertex, these transfers would
have to be instantaneous and the bus we were transfering to would always be available.
The solution to this is to break up a stop into several smaller verti ies.

ShortBusRide

Figure 2: Modeling a stop, with a set of "in" and "out" verti ies, and how stops relate.
Stop B
B1

1B

Stop A

Stop A
In
1A
2A

A1

Out
1A

B2

2B

IN

OUT

B3

3B

B4

4B

1A

A2

2A

IN

OUT

A3

3A

A4

4A
Stop C

2A
C1

...

...

1C

C2

2C

IN

OUT

C3

3C

C4

4C

3.1.2 Modeling a stop and transfer

Instead of modeling a stop as a single vertex, ea h stop is a tually omposed of several
verti ies: there is a set of verti ies representing all the busses that stop there, and a set of
verti ies for all the busses that leave there. For example, if bus routes 1, 2, and 3 arrive
at stop A, then we an model this as sub-stops 1A, 2A, and 3A; all these stops the in
verti es for A. Correspondingly, say bus routes 2 and 3 leave stop A (route 1 terminates
at A), then we an model these as A2, and A3 (note that the letters and numbers are
reversed); these are the out verti ies for A.
Ea h in vertex of a stop has out-edges to every out vertex in that stop, and ea h out
vertex maps to at most one in vertex of some other stop. One thing to note: the ost of
transfering to and from the same bus at a stop is 0). See gure 2.
What does this gain us? Now, if we want to get o from one bus and transfer to another,
the time it takes to transfer an be modeled as the edge between the bus we ame in on to
the bus that will leave this stop. Dijkstra's algorithm an still be applied to this situation
to minimize the time we spend waiting on the next bus. See the following theory se tion
for details about Dijkstra's algorithm.
Additionally, we an have extra parameters that spe ify the minimum wait time, so that
if we were to get o one bus, we'll be assured that the next bus hasn't already left (e.g.
make sure at every stop I arrive at that there is at least ve minutes before the bus I
transfer to leaves).

3.2

Data representation

In this se tion, we des ribe how the various pei es of data t together, both on disk and
in memory.

ShortBusRide

3.2.1 Data input format

Figure 3: A time s hedule.

10:30
10:45
11:10
12:50

11:15
11:30
-

11:45
12:00
-

12:30
12:45
11:55
13:35

13:00
13:15
12:25
14:15

The format for the input les will be arranged roughly the equivalent to how the printed
time s hedules are formated. Ea h route has its own le with a table in it. Ea h table
ontains a list of stops in the rst row, and the times that the bus arrives at that stop.
Times where a bus skips that stop are left blank. In this form, we an read ea h line from
right to left to determine what a bus's next stop is and what time it will arrive there.
One aveat worth mentioning is that it's important to separate the dierent dire tions of a
route. For example, though we think of bus N as being the same bus both northbound and
southbound, it's really two dierent routes. If we don't make this distin tion, Dijkstra's
algorithm ould potentially fail to nd an optimal path (returning a sub-optimal one or
failure).

3.2.2 Obje t lasses

Class TimeS hedule

Responsible for loading the datales for all routes, and performing lookups for
a route for a given departure time.

Class Stop

Maintains the in and out sets of verti es.

Class Vertex

Keeps a pointer to the previous vertex (to re onstru t the path by ba ktra king), the time we arrived at the vertex, the stop that this vertex is part of,
whether it's an in or out vertex, and the route that this vertex represents.

3.3

Algorithms

Finally, we turn to the a tual pseudo- ode implementation of our algorithms

ShortBusRide

3.3.1 Initialization
After we initialize the time s hedule for all routes, we an begin reating the stops and
verti es of the graph.

We keep a growable table of stops, and initialize entries in the

table as ne essary. The task of adding a route that passes through a stop is delegated to
the stop (whi h in turn adds verti es to its in and out sets). The task of linking verti es
is done at the time of the query (due to the fun tional nature of edge weights).

See

algorithm 1.

3.3.2 Sear hes

Our sear h algorithm is a heavily modied Dijkstra's algorithm. See algorithm 2.

4 Theory
Let

G = (V; E )

be a dire ted graph.

f(v; w; t) j (v; w) 2

E; t

 0g

Let

be a fun tion that maps the domain

to the range of nonnegative reals.

fun tion that omputes the weight of an edge given a urrent time
Bus systems an be modeled with su h graphs. We an let

t, D(v; w; t)

is a

be the set of bus stops, and

be the set of (v; w ) su h that there is a dire t bus going from stop

a urrent time

Intuitively,

t.
v

to stop

is the amount of time it takes to get from stop

w.

Given

to stop

w.

This allows the model to a ount for time dependent fa tors su h as tra density.
The single sour e shortest paths problem (SSSP) is one of the most ommonly known
problems in graph theory.
shortest path is from

It asks, given a graph

to all other verti es of

G.

an pose a very similar question. Given a graph

vertex

s,

and a start time

t,

and a sour e vertex

s,

what the

In the time dependent formulation, we

G,

an edge weight fun tion

what is the shortest path from

F,

a sour e

to all other verti es of

G?

Call this problem the time dependent single sour e shortest paths problem (TDSSSP).
Of the algorithms to solve the standard SSSP problem, the most ommonly known is
Dijkstra's algorithm. It is stated as follows.

Dijkstra(G; s)

fg

K= s
d [ s = 0

for all v 2 V K do
if (s; v ) 2 E then
d[v

weight (s; v )

d[v

else

end if

ShortBusRide

end for
while K 6= V do
v
K

vertex in (V

for all
d[w

K)

with minimum

d[v

[v
fw j (v; w) 2 E g do
min fd[v + weight (v; w ); d[w g

end for
end while

We an make a slight modi ation to the algorithm to t the time dependent graph
formulation by hanging

and hanging
to

weight (s; v )
D(s; v; 0)

d[v
d[v

to

f
f

min d[v + weight (v; w ); d[w

d[w
d[w

min d[v + D (v; w; d[w ) :

Call this algorithm TD-Dijkstra.

Does this algorithm solve the TDSSSP problem? Not exa tly. It is simple to onstru t
a fun tion for

that breaks it.

However, it turns out that, by onstraining

to a

ertain set of fun tions, TD-Dijkstra will solve the TDSSSP problem. We laim that

TD-Dijkstra solves the TDSSSP problem if D has the FIFO (rst in, rst out) property. Basi ally, the FIFO property states that arriving later at a vertex never yields an
advantage. In the bus system model, the FIFO property holds, sin e arriving at a stop
earlier an't make you later to your nal destination. More formally,

has the FIFO

property if

 j ! i + D(v; w; i)  j + D(v; w; j )

8v; w 2 V 8i; j  0:

(1)

We argue that the following theorem holds.

Theorem 1 Given a graph G and a fun tion

solves the TDSSSP problem.

that satises the FIFO property,

TD-

Dijkstra

Proof

Suppose we are given

and

su h that

satised the FIFO property. Let

the the sour e vertex for TDSSSP. Assume without loss of generality that the start time

t = 0.

Given a vertex

v,

dene

fj

2 E g.

B (v ) to be the set u (u; v )

v . Dene (s; v ) to be the

the set of verti es dire tly behind

from
So

to

(s; v )

Intuitively,

B (v )

is

length of the shortest path

v.
an be formally dened as follows.


(s; v ) =

minu B (v )

mint (s;u) t + D (u; v; t)

if
if

v=s
v=s

(2)

ShortBusRide

In other words, the length of the shortest path from

t + D(u; v; t)

over all verti es

that are behind

is al ulated by minimizing

g.

t + D(u; v; t)
t = (s; u). Thus

Let's look at the part of (2) that reads mint (s;u)

FIFO property (1), this value is minimized when

(s; v ) =

to

greater than the

u.

minimum length path to

as follows.

and over all times

minu B (v ) (s; u) + D (u; v; (s; u))

if
if

Be ause

has the

we an restate

(s; v )

v=s
v=s

(3)

This implies the optimal substru ture property; that is, optimal solutions are built from
optimal solutions. Given the above result, the orre tness of TD-Dijkstra follows. The
proof mirrors the orre tness proof of Dijstrka.

jV j
jV j deletions from the priority queue, ea h taking O(log jV j) time.
As for updating the values of d[v , this is done at most jE j times (sin e every edge is visited
at most on e). Ea h update potentially requires a priority hange, whi h takes O (log jV j)
time. Thus the total time omplexity of Dijkstra is O (jV j log jV j + jE j log jV j).

Suppose Dijkstra is implemented with adja en y lists and priority queues. It does
iterations, leading to

If omputing

D(v; w; t)

is an

O(1)

operation, then TD-Dijkstra has the same time

omplexity (TD-Dijkstra repla es onstant time operations in Dijkstra with other

D(v; w; t) is
O( V log V + X E log E )

onstant time operations). If omputing

that TD-Dijkstra has

j j

j j

j j

j j

an

O(X )

operation, then it follows

time omplexity.

5 Simpli ations:
With limitations on getting data from Metro themselves the data used in the model is
very over simplied. This is due to the fa t that few stops are listed on Metro's web site.
Thus the model will only onsist of these few bus stops.
In the real world a person ould ride a bus to a ertain lo ation, get o and walk to
another bus stop.

However, in the model this is not a ounted for.

To take this into

a ount many variables would have to be taken in, whi h is far beyond the s ope of this
problem.

6 Improvements:
Many improvements an be made to this model. A person may want to nd the latest time
they would leave and still have the same travel time. This would in lude a ba ktra king
sear h of the graph in order to nd the maximum time in whi h this would still work.

ShortBusRide

The model ould also solve for the minimized travel time for any arbitrary time of departure. Thus a person ould nd the best times to leave during the day to minimize travel
time. However, to solve this problem would mean solving what is probably an NP-hard
algorithm sin e a bran h and bound approa h would have to be taken.
A person may also want to minimize the number of transfers between buses as well. This
ould be a large fa tor in pi king a path for a person who is handi apped. Where getting
on and o the bus is a time onsuming task.

7 Results
All your results are belong to us.

8 Con lusion
Our model ro ks.

ShortBusRide

Algorithm 1 initGraph

begin
TimeShedule t := LoadTimeS hedule()
Map sMap := CreateEmptyMap()
forea h Route r in t
forea h Stop s in r
if sMap[s 6= null
sMap[s = CreateNewStop()
endif
sMap[s.add(r)
endfor
endfor
end

ShortBusRide
Algorithm 2 sear h

10

Input: beginStop, /* origin */

endStop, /* destiniation */
startTime /* time of departure */
begin
PriorityQueue q
forea h vertex v in beginStop.inVerti ies
v.time := startTime /* the earliest we an arrive here */
v.prev := null
/* stop ba ktra king if we get to this vertex */
q.enqueue(v)
endfor
while !q.isEmpty()
v = q.deleteMin() /* get the vertex with earliest time */
if v.isAnInVertex
forea h vertex w in v.stop.outVerti es
w.prev := v
w.time := v.time + LookupTimeDifferen e(v.time,
v.route,
v.stop,
w.stop,
w.route)
/* Have we rea hed our goal? */
if w.stop = endStop
return w
endif
q.enqueue(w)
endfor
else
(w,timeDiff) := GetNextVertex(v.time,v.route,v.stop)
/* he k if this route terminates at v */
if w = null
/* Try another vertex */
ontinue
endif
w.prev := v
w.time := v.time + timeDiff
/* Have we rea hed our goal? */
if w.stop = endStop
return w
endif
endif
endwhile
/* If we got here, we didn't rea h our goal */
return failure
end