GIS Application to the Monitoring of Bus Operations
GIS Application to the Monitoring of Bus Operationsby C. S. Papacostas, Department of Civil Engineering, University of Hawaii
In most urban areas, public transportation service is provided by fixed-route bus systems. From the perspective of the bus operator, a basic unit of analysis is the bus-trip. Although varying in format, each bus property maintains a complete list of bus trips for each of the several regular schedules it accommodates (e.g., weekday, Saturday, Sunday, holiday, etc.). For a given schedule, it is common to assign to each vehicle in service a "block," i.e., a sequence of revenue and non-revenue (deadheading) trips that the vehicle must complete during the day. Real-time adjustments to these assignments in response to unanticipated events (e.g., bus breakdowns, non-recurrent congestion, etc.) are performed by supervisors in the field and, increasingly, via centralized automatic vehicle location and control systems. Longer term and systemwide assessments of operational performance require the collection of vast amounts of data that must be organized to reflect complex temporal (e.g., morning peak, base, evening peak) and spatial (e.g., in-bound by route or corridor) patterns. Automated data collection techniques are slowly replacing manual methods in this area as well. One consequence of automated data collection is the added volume of information in need of processing and analysis. Thus, bus operations analysis is a data-intensive area that can be substantially enhanced by the topological overlaying capabilities and spatial visualization afforded by a well designed and methodically developed Geographic Information System (GIS) framework.
I conducted this work with my student Illias B. M. Abdul. We looked at the major types of data usually collected by bus properties and the typical uses to which these data are put, identified spatial and attribute data organization requirements that are of particular relevance to bus network structures, developed a prototype GIS application to the monitoring of schedule adherence, and examined the advantages offered by the proposed specification with respect to potential integration with other bus-specific and general transportation engineering and planning applications.
Two commonly used methods for collecting ridership and schedule adherence data are ride check surveys and (load) point check surveys. In the case of ride check surveys (also known as on-off counts), surveyors ride selected bus-trips and count the passengers that board and de-board the bus at each bus-stop. Running time checks and bus arrival/departure times at selected bus-stops visited and at other schedule timepoints are sometimes taken in conjunction with ride check surveys. Point check surveys are taken at a few points along each route, often at the maximum load point, or at selected major checkpoints where multiple routes can be observed.
Continuous ride check data collection protocols based on specified sampling methods are required by the Federal Transit Administration (FTA, earlier UMTA) to arrive at estimates of annual systemwide unlinked passenger trips and passenger miles that must be reported under the Section 15 requirements of the Urban Mass Transportation of 1964, as amended. Minimum sample sizes for this purpose depend on the sampling technique used. They range from about 200 to about 600 bus-trips spread throughout the year). Ride and point checks are also conducted for the purposes of comprehensive operations analyses (COAs), individual route studies, subsystem studies), and in response to localized problems. COAs are typically conducted at 3-5 year intervals and are intended to provide a detailed assessment of the operation. Since they aim at a level of detail down to the route level, they involve larger sample sizes than the minima specified for annual systemwide estimates. For example, a COA for Madison, Wisconsin, sampled 100 percent of all bus-trips for a "typical weekday," whereas a COA for the larger bus system in Honolulu, Hawaii, surveyed (over a two month period) more than half of the 3,500 regularly scheduled weekday bus-trips. These types of studies generate enormous amounts of data that are not typically used to their full potential because of a lack of a systematic organizing framework.
COAs employ additional types of data collection, e.g., on-board, household, and bus-driver surveys, because their scope extends beyond strictly operational issues. Much of this information may be available from other transportation and planning agencies within the service area of the bus system. For example, on-board and household survey data may be collected by the regional Metropolitan Planning Organization (MPO) to support the development and application of travel demand forecasting models.
Reporting requirements related to the compliance of transit properties with Title VI of the Civil Rights Act constitute a particularly onerous task). Among these data collection and reporting requirements are the following:
In addition, the FTA guidelines identify "five indicators considered to be significant to monitor public transit system's compliance with Title VI." These are: vehicle load, vehicle assignment, vehicle headway, distribution of transit amenities, and transit access. The precursory nature of these aspects to computer-based GIS functionality is inescapable. Indeed, the technical literature contains descriptions of several GIS implementations that address these reporting requirements. Several of these applications incorporate elements of topological analysis, such as buffering around the skeletal transit network to measure accessibility by various market segments. However, these endeavors are mainly single project applications, and represent only modest achievements. They fail to take full advantage of the potential of GIS technology. To unleash this potential beyond the obvious, it would be necessary to explicitly incorporate in the design of the spatial database certain specifications relating to special of transit network elements and operating procedures.
The first problem involved location referencing systems, specifically the choice between link-node and route-milepost notation. The former method describes The latter method is an extension of the traditional practice of maintaining highway data by referencing locations linearly on continuous chains of links. These "inventory" routes may or may not coincide with the route numbers shown on roadway signs (see also the discussion of route overlaps below). Initially, most state transportation departments opted for the route-milepost method since this was the employed in existing inventory systems. Moreover, it was not unusual to encode mileposts as nodes. This resulted in networks that contained inefficiently large numbers of nodes and links.
The second requirement was the need to define a new GIS entity to represent features such as routes (or chains). Routes are typically defined as lists containing sequential links.
The third common requirement for transportation network analysis arises in connection to the designation of roadway segments. The development of pavement management systems provides a classical example. In that case, segments of roadway having the same pavement type or condition must be identified. Each of these segments may or may not begin and/or end at explicitly encoded nodes; they may even extent over adjacent links. Other examples include the designation of speed limit zones and encoding variable geometric features such as gradients or laneage. Segments are sometimes called "events" as they also include point features (e.g., accident or bus-stop locations). The term "dynamic segmentation" refers to the functionality of accounting for such events without having modify the underlying network.
Dealing with overlapping routes and associating "events" with subsets of these routes is a requirement that developers of GIS-T applications have often ignored. For example, an accident occurring on a network link is associated with all the routes sharing that link. Similarly, the pavement condition of a link segment applies to all routes that use that link. A careless analyst of accidents or pavement condition can easily run into the problem of counting each "event" several times if s/he pursues a route-by-route analysis and then accumulates the results. Directional signs represent a case where "events" are associated with only one of the routes sharing a link.
The most appropriate GIS software for network-based transportation applications must provide full dynamic segmentation functionality and the means for obviating the need for duplicative digitizing when specifying overlapping routes.
Focusing at the route-level is common in the case of fixed-route bus system scheduling, analysis, monitoring and evaluation. Typically, a primary route and a set of subroutes (either branching lines or short-run lines) receive the same route number. They are distinguished from each other by their route descriptions (e.g., destinations) in each travel direction. On the other hand, routes with extensive overlaps often carry different route numbers, even though their relationship is similar to the route/subroute case. Bus routes or subroutes that follow distinct paths could be considered to be separate routes when specifying a transit route structure. However, these elemental routes should not be digitized independently on separate GIS layers as has been the practice in some instances but should be defined by reference to the base street network. Provisions should be made so as to be able to combine "elemental" routes for the preparation of reports that are consistent prevailing route numbering practices, for undertaking longitudinal comparisons using historical data that are maintained at the "traditional" route level, and for investigating special subsystems, e.g., express bus coverage or service within a corridor.
The specification of bus-stops and the association of routes with stops merit particular consideration. This is a special manifestation of the "event" problem described in connection with GIS-T. Bus-routes do not necessarily service all the bus-stops that lie on their paths, and many bus-stops are serviced by more than one route. It is, therefore, necessary to devise an efficient way by which stops can be specified and associated with their respective. The first issue relates to an effective way of digitizing bus stops. One method used in the past explicitly coded each stop as a node on the base street network. This method suffers from several drawbacks. First, it requires modifications to the underlying street network (similar to the mileposting question discussed above). Moreover, any changes in transit stop locations would require redigitizing the underlying street network. Second, the path specification of transit routes becomes less efficient as it requires a longer list of links than would otherwise be the case. Third, routes that do not serve certain have to be processed through these stops since they are an explicit part of the designated paths. A much preferred method is to place all stops on a separate point layer. One advantage of this approach is the clean linkage of additional stop attributes, such as type, weather protection, and maintenance history. The geographic referencing of each stop may be accomplished by specifying its x- and y- coordinates and/or by linearly referencing the location of the stop to the underlying street link in a manner similar to address matching, the well-known early form of dynamic segmentation. Subsets of stops can then be associated with routes in the nonspatial database. This can be accomplished via a route-stop association array that identifies the sequence of stops (columns) that belong to each route (rows). In this manner, the spatial and attribute data structures of the base street network remain intact. Assuming the presence of cooperative institutional arrangements, the base street network may be shared with other GIS-based applications
The concepts described above have been incorporated in the development of a prototype application concerned with bus-schedule adherence. The Sun workstation version of the Arc/Info GIS software package was used for this purpose. The development of the prototype coincided with the conduct of the latest COA by the Honolulu Public Transit Authority (HPTA) through consultants. This afforded an excellent opportunity to interact with HPTA personnel in identifying special requirements and peculiarities associated with the Honolulu system.
The basic operational data incorporated in the prototype were in the form of ride checks collected as part of the COA. The operator of the Honolulu bus system (Oahu Transit Services, OTS) employs the "bus run" method of identifying regularly scheduled bus-trips. This entails assigning a "key" to each vehicle dispatched to a particular route. Each "key" is assigned a number of "runs" on that route. Consequently, a concatenated code consisting of the route number, the key and the particular run of that key uniquely identifies the bus-trip. Certain data rearrangements became necessary to correctly reflect the disaggregation of "traditional" to "elemental" routes as described earlier.
For each of the approximately 1800 bus-trips sampled, the survey data were to be computerized by the HPTA consultants in a particular format and placed in a separate ASCII file. Each bus-trip file contains general information (for example, date of survey; checker name; route, direction, key and run; bus ID number and seating capacity). A list of bus-stops on the itinerary along with the corresponding arrival times and the on/off counts followed this data block. A special-purpose computer program written in C as part of our project converted these data to a format acceptable to Arc/Info. The corresponding scheduled arrival times are obtained when needed from OTS timetable files. The C program also derives certain variables (such as weekday or weekend service) from the data available in the survey files. Program modules were written using the Arc/Info Macro Language (AML}, and AML's menu capabilities were used to develop an end-user GUI.
The GUI provides a menu system that can be used to plot or draw the base street network and bus routes, to select peripheral devices including plotters and printers, and to perform a schedule-adherence analysis.For example, the "analysis" submenu of the GUI that aids the selection of runs, keys (all runs) or routes (all keys and runs) is illustrated. The analysis program obtains and processes the necessary data (e.g., arrival and schedule times) for the required runs. For example, when the user selects a route key, the program identifies the route structure and its corresponding stops. It then searches the database for all scheduled runs associated with that key, obtains the necessary raw data and stores them in a temporary file for further processing. Any requested displays appear in separate windows on the output device. Hence, they can be viewed and examined jointly.
This work developed a route structure specification scheme that can form the basis of a comprehensive GIS framework for fixed-route bus systems. The proposed specification requires a relatively sophisticated software package that allows for dynamic segmentation and provides programming functionality. This paper also described an initial implementation of this framework and a GIS application to fixed-route bus system schedule adherence monitoring. The extension of this prototype to the charting of passenger boarding and alighting activities, as well as to the plotting of running times, along transit routes is relatively straightforward. The same framework can enhance other applications, including the efficient identification of complex transit paths), improved scheduling and run-cutting procedures), and the extraction of abstract networks at various levels of aggregation as required by regional travel demand analyses and forecasts. By retaining the integrity of the base transportation network, the framework described in this paper can reduce coding redundancies. It can also facilitate database integration with other transportation-specific applications. A related paper has been published in the 1995 Compendium of Technical Papers, Institute of Transportation Engineers.
