SCHOOL BUS ACCELERATION CHARACTERISTICS

Research was conducted to collect speed, time, and distance data for Type C and D (“full size”) school buses accelerating from a stopped position. Most of the tests were conducted on level terrain. By combining the knowledge of how quickly a school bus can accelerate with assumed speeds of oncoming through-street vehicles, the needed intersection sight distance can be calculated. Another application of the findings is analyzing departure sight distance at railroad grade crossings used by school buses.

This maybe useful for me to estimate the proportion of travel time v.s. dwell time.

]]>

One reason is transit service is more complex it seems. It might seems a bus service just hit all the stops in sequence. But the actual service has a lot of variables. The schedule is often different in weekend compare to weekdays. And so does the exact route that it covers. Sometimes a bus is scheduled to run a short route rather than covering the whole length. In more complex case there can be branching where there is a common main trunk and then the buses split to serve two or more alternative destination.

This is the reason why in GTFS one “route” may associate with multiple “shapes”. To find out what shapes are associate with a route, we will have to make a query like this

SELECT shape_id FROM route JOIN trips JOIN shape GROUP BY shape_id;

To find out the stops is even more complex. Here we need to join one more table the stop_times. It is also the biggest tables in the GTFS. So this is also the most computation intensive query to do.

SELECT shape_id, stop_id FROM route JOIN trips JOIN stop_times JOIN stops GROUP BY shape_id, stop_id;

Still most people have a clear concept of what a transit line is where it runs. It shouldn’t be such a pain to compute. A more useful structure should look like below.

GTFS More Useful Structure Structure route line | | | V | route* | | \ | shape | +-> route_shape | ^ | | | / | +-> route_stops* | / | V / V trips trips | | | stops | stops | ^ | | / | V / V stop_times stop_times

Here a shift the terminology a bit. The top level entity is a line (i.e. GTFS’ route). This is service that people know of, like a numbered bus line or a metro line. Below that is routes. These are the collection of alternative routes a line may run. The routes are not explicitly represented in GTFS. You can find that by querying all unique shape_id using the first SQL. Another missing piece is the stops. If we can pre-compute all the route_stops using the second SQL once, for the most part we don’t need the giant stop_times table. For applications that do not deal with scheduled time, this is a huge saver. The is one assumption my structure makes though. It is that different lines do not shape that same route. If should be a reasonable assumption. And if there is indeed share route and shape, we should just replicated them as two separate entities.

The original GTFS structure seems to have a transit operator centric view. It allows them maximum flexibility to author and publish their service data. But for application developers, it is not structured for easy traversal. By adding the route and route_stops tables as indicated, it will greatly facilitate the query and operation of transit information.

]]>

Define as the wait time when a person arrive the station at time t. The chart looks like a sawtooth. It is highest when the passenger arrive just after a bus has left, and it will be 0 when the passenger arrive . Here is when bus i arrives., is the headway to the next bus and is the sum of .

The expected wait time is given by this formula

is the probability density function of people arrive at time t. We assume people come uniformly. So is simply .

In general communication, it is often more natural to talk about frequency than expected wait time. For example we often say the bus arrive every 10 minutes. But it requires a little bit of math to translate it to 5 minutes of expected wait time. Since the expected wait time is just half of the headway, we can multiple the formula above by to get a effective frequency. We can implement a simple function to calculate the effective frequency below.

>>> def effective_frequency(times): ... h2 = sum(t*t for t in times) ... T = sum(times) ... return float(h2)/T ... >>> effective_frequency([10,10,10,10,10,10]) 10.0 >>> effective_frequency([10,15,5,10,10,10]) 10.833333333333334 >>> effective_frequency([10,10,10,28,1,1]) 18.1

As expected the last example give a much worst effective frequency 18.1 minutes than the baseline of 10 minutes.

It is interesting to study the relationship between expected wait time and the variance of the headway. This is given by the formula.

where

or = 2 × Expected Wait Time = effective frequency

There is a very nice interpretation of effective frequency. First of all it is smallest when is 0. That is when the headway are evenly distributed, it will achieve the optimal frequency μ. Secondly effective frequency is larger than μ by . So the variance can be interpret as the penalty above the baseline frequency. In order to minimize wait time, it is necessary to minimize variance.

One implication is how to mitigate missed run. If it is necessary to skip a bus run due to equipment break down or availability of drivers, it is better to redistribute the remaining run evenly than to simply miss a run.

>>> effective_frequency([10,20,10,10,10]) 13.333333333333334 >>> effective_frequency([12,12,12,12,12]) 12.0

Using the formula above, dropping a run with headway 10,20,10,10,10 gives an effective frequency of 13.3. This is worst than if we can redistribute the remain 5 buses to get a frequency of 12.

]]>

Is there a standard order to express the coordinate in computing system? It seems the only way to make software reliable is to adopt a consistent order. So I looked at several software system. Here is what I find.

- Leaflet library
- Google Maps API
- General Transit Feed Specification – lat is listed before lon in the documentation.

- GeoJSON – The order of elements must follow x, y, z order (longitude, latitude, altitude, …)
- KML – <gx:coord> A coordinate value consisting of three values for longitude, latitude, and altitude, … Also the values are explicitly tagged as XML element.

There is not a consistent order used in the field. In addition there is also variation of the 3 letter shorthand for longitude – lng v.s. lon. Sigh… No wonder I have messed up.

This is what I’m going to use – **lat, lon**, so as to follow the verbal convention.

]]>

]]>

From Fu and Yang’s paper on Design and Implementation of Bus–Holding Control Strategies with Real-Time Information:

Bus operations in urban environments are often subject to significant variations because of a variety of complex factors such as dynamic and stochastic traffic congestion and passenger demand. These variations, if not offset by control actions, will cause bus bunching—a well-known phenomena contributing to increases in passenger wait time and uncertainty in bus arrival times (1). Controlling bus operations is a way to compensate and reduce the effect of such variations so that the planned headway and schedule can be maintained. Among many bus control strategies, holding control is one of the most effective and common strategies that can be used to regulate bus operations. By holding early-arriving buses, bus headways can be evened out and service reliability improved.

The paper was published in 2002. They believe real-time information system can improve the performance of their model. Of course today system wide real time information are available. It is time to implement these kind of control system to improve the bus performance.

]]>

GTFS describes every trip in a line scheduled to run. It turns out that bus with the same number may in fact run many variation of route. Regular riders may notice some bus runs a shorter route. A good example is the 30 Stockton line.

I plot each route variation using different color. The small hollow circle marks the origination point and a large solid circle marks the termination point. Furthermore, the width of line is proportion the number of run on such route. Thicker line depicts frequent and often the main route. As we can see, most bus terminate at the blue circle at Divisidero & Chestnut. However, there is also a second frequent terminal at Van Ness and North Point in orange color. If you look more carefully, you may also spot a very thin line terminate near Market St. According to the database, there are 10 trips with the head sign “Union & Columbus” terminate there. It is a curiosity that I have not investigated yet.

Another example that is depicted very successfully is the 38 Geary line. From the graph we can see 4 different routes 38 runs. They split off to terminate at 48th Avenue, VA Hospital or 32nd Ave. Furthermore, a thin red line is an alternate route that run thru VA hospital but terminate at 48th Ave. All routes are fairly thick, meaning each terminal are used almost as frequent. In contrast, the red alternate route is comparatively infrequent. Compare this to system map, I think this depiction of the variation is lot easier to understand.

One of the most helpful technique used is to vary the line width in proportion to the the number of trip run (i.e. the line frequency). For example, the map below shows 14X Mission Express as a thin line. While our first reaction to an express line is that it is fast and wonderful, this alert us that it is also a limited route that runs in commute hours only.

This is often a problem with the full system map. It shows a dense web of lines in equal width. Many of these lines are actually special commute hour or late night route that is irrelevant to most riders. Varying the line width help makes the main route stand out form these limited routes.

]]>