Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 73
73 In some analysis databases, records are only partially trip is departure or arrival time at a designated key point, matched. For example, they may indicate the timepoint, but which may be different from the starting point. On radial not the scheduled trip. This kind of record can support many routes, the time at which a trip enters or leaves the down- types of analysis, such as analysis of running time between town may be a more meaningful choice for categorizing timepoints. However, without matching to scheduled trip, it by period than the time it began; this distinction can control time cannot be inferred because it becomes impossi- be especially important if a system has a mix of short and ble to know whether a bus was running early. (In principle, long routes. one could analyze schedule adherence by comparing the array As mentioned in Chapter 8, several transit agencies are of scheduled departures with the array of observed depar- hoping to move to trip-level passenger count screening and tures; however, the reality of missing data makes a simple correcting as part of entry processing. If that is done, the comparison impractical.) number of inherited and bequeathed passengers determined Including a field for scheduled departure time enables for each trip can be incorporated as fields in the trip header selection based on scheduled times. Without scheduled depar- records. ture time as a field in a stop or timepoint record, one can select data for analysis based on a range of actual departure 11.3 Associating Event Data times (e.g., analyze all the trips that began between 7:00 a.m. with Stop/Timepoint Data and 9:00 a.m.); that kind of analysis is often done for run- ning times. A disadvantage of selection based on actual run- For most routine analyses of AVL-APC data, the funda- ning times is that the set of trips included on any given day mental record type is the stop or timepoint record. However, can vary depending on whether trips near the period bound- several analyses involve data from other types of event ary departed before or after the period boundary; such vari- records or from interstop records. Examples include infor- ation in the numbers of trips included in a day's analysis can mation about pass-ups or wheelchair lift use (which occur distort results. at stops but may be recorded as a separate event), and max- imum speed or drawbridge delay (which occur between stops). One database issue is how to associate data on those 11.2.2 Trip Parsing kinds of events with stop or timepoint records so that they Matching also involves parsing the data stream for a given can play a part in passenger count or running time reports, block/day by trip. Many of the issues involved in identifying for example. trip endpoints have been discussed in Section 2.2.5. Parsing passenger counts at trip ends is discussed at length in Chap- 11.3.1 Adding Fields to Enrich Stop ter 8. One common parsing operation is converting a single or Timepoint Records record indicating the end of one trip and start of another into two records, one for each trip. One way of associating the information contained in other types of records with stop records is to add to stop or time- point records fields summarizing information from other 11.2.3 Trip Header Records record types. As an example, stop records in Eindhoven's Tri- Entry processing can involve the creation of header records TAPT database include fields for segment delay and control for trips and blocks. (Trip summary records, which serve a (holding) time. Segment delay is calculated as part of the different purpose, are described later.) Header records, which entry processing of AVL data, using records of buses crossing are part of TriTAPT's data structure, help organize the data- a crawl speed threshold to calculate the amount of time base and make selection quicker. The header record for a trip between a pair of stops spent stopped or below crawl speed, contains pointers to that trip's stop records, as well as trip- excluding time spent at the stop. Likewise, control time is cal- level information such as route ID, trip ID, and scheduled and culated based on whether a trip was early and how long its actual trip departure times. These header records make dwell time was. Because each TriTAPT stop record contains queries faster, as the query only has to determine which trip information on both a stop and the segment following it, it is headers meet the selection criteria. Many databases, includ- called a "stop module" record. ing Tri-Met's, function without trip headers, including all the In Tri-Met's database, a field for maximum speed achieved header information in each stop record. Queries directly on each preceding segment is part of the stop record. In fact, select stop records, which can make queries slower in a large this field is filled on board when the stop record is created, database. rather than as part of entry processing. For a trip header, an alternative (or supplement) to Because AVL systems in the United States record a variety scheduled and actual departure times from the start of the of event types that can be relevant to operations analysis, part