After a long wait for a bus, two arrive in quick succession: the buses are bunched. [1] Running in a group they act like they are running less frequently than they really are. I want a way to calculate 'bunchedness' from the buses reported GPS positions, both as a way to see how bad the problem is and as a potential way for a bus service to determine if a fix is working.

I think what we're trying to minimize is wait time. If a bus route has scheduled service every 10min then with perfectly spaced buses you get an average wait time of 5min, half the scheduled time between buses. If the buses are bunched in pairs but otherwise evenly spaced, this goes up to 10min. Let's define the bunching factor B at a stop in terms of the ratio between the mean wait time W and the scheduled service interval S:

    B = 2W/S - 1

A perfect route (W=5min, S=10min) would have bunching factor of 0 while as the route got closer to pairwise bunching we'd get up towards 1. We can average this to compare routes or bus systems. [2]

Measurement

You can pull vehicle locations as xml from NextBus's API. Let's say we pull and log once a minute. [3] Consider each route (dirTag in the feed) separately. To get stop arrivals we can pull the list of stops for that route and look only at sequential pairs of points where a bus went from being on one side of a stop to another. Make a giant list of (route, stop, time) triples.

If we were to run the calculation over the whole time period of logging we would see that the buses were all running during the day and especially at rush hour. We shouldn't be counting it as bad that the transit agency decides to run fewer buses at 1am than 5pm. Let's assume they're correctly determining the service frequency at each time of day. Using the historical data for each route we can figure out when they make shifts in frequency. Cluster the data into windows by service frequency: early morning, morning rush, midday, etc. For each time window of length T, if the number of buses arriving at a stop is N> then:

    S = T / N

Calculating W is trickier. We want to know how long you would have to wait for a bus if you showed up at this stop at each point during the window. Break the window down by bus arrivals into N segments. During each segment of length L_i you expect to wait for L_i/2 and we weight the segments as L_i/T [4], so we have:

    W = sum((L_i/2)*(L_i/T) for i in 1 to N)

Which gives us:

    B = N*sum((L_i/T)^2 for i in 1 to N) - 1

Does this sound right? Is there a better way to do it? The windowing makes me uncomfortable; I fee like there should be a continuous version.

[1] I'm not entirely sure why this happens. I think it might be that evenly spaced buses are an unstable equilibrium. If a bus gets behind schedule it picks up some people who might have been for the following bus, slowing it down and speeding up the following bus.

[2] If S=1hr and the buses are all running exactly 20min late, we'll still see W=30min and B=0, but that's not what we're trying to measure. Bus systems already track an "on time percentage" metric, which deals with this.

[3] You can't compute an instantaneous bunching factor from a single pull because you don't know if there are naturally slow (bad intersections) or fast (highways) parts of the routes.

[4] This adds to 1 because sum(L_i for i in 1 to N) = T.