7. TRANSIT APPLICATIONS

7.1 STATE-OF-THE-PRACTICE REVIEW

            Transit ITS has three components: (1) metropolitan, (2) rural, and (3) the Intelligent Vehicle Initiative. The metropolitan component focuses on urban and suburban transportation in the areas of Traveler Information, Transit Management, and Electronic Payment. The rural Transit ITS component addresses these same areas but emphasizes rural area applications. The Intelligent Vehicle Initiative pertains to automating transit vehicle control and safety systems.

            A state-of-the-practice was conducted to determine the use of data archived from transit ITS technologies. A growing number of transit service providers are using Automatic Vehicle Location (AVL) and/or computer aided dispatch (CAD) systems to better manage their bus operations. These systems help to circumvent traffic congestion and to meet passengers’ demand for more reliable service. Beyond the area of operations control, AVL technology holds great promise for improving service planning, scheduling, and performance analysis practices. In particular, AVL systems can collect substantial amounts of operating data at the spatial and temporal scales that are required for performance analysis. In addition, Automatic Passenger Counters (APCs) can collect and archive passenger activity data that are compatible with AVL operating data.

7.1.1 ITS-Generated Transit Data

            One hundred and ninety-six transit agencies responded to the 1999 Transit Management Survey. Table 7.1 demonstrates the propensity of data archiving by transit agencies. One in every three transit agencies did not archive any data collected (the “0" column), while more than one in every three archived all data collected (cells on the diagonal line).

            The most commonly collected transit data are: passenger counts and passenger information (Figure 7.1). Many transit service providers are increasingly equipped with ITS Advanced Public Transportation System (APTS) technologies. These include the Automatic Vehicle Location (AVL), Computer-Aided Dispatch (CAD), Fleet Management System (FMS), Automatic Passenger Counter (APC), and Automatic Fare Payment System (FPS) technologies.

The likelihood to install advanced technologies varies by the type of the technology. Almost all of the responding agencies indicated that they have or plan to have their vehicles equipped with ramp metering priority capability (Figure 7.2). Three quarters of them have (or plan to have) their operators/dispatchers report traffic incidents. This has safety implications by, for example, potentially facilitating the integration of the safety component into the transportation planning process. About forty percent of transit agencies that responded to the 1999 transit survey had information on transit work zones and one of every four such agencies archived that information.

Figure 7.2 Agencies That Have (or Plan to Have) Equipment Installed

(of 196 responding transit agencies in 1999)

7.1.2 Archiving of ITS-Generated Transit Data

            One in every three transit agencies did not archive any data collected, while more than one in every three archived all data collected. Based on discussions with a very limited number of transit agencies, the overarching reason for archiving data is to satisfy mandatory federal reporting requirements such as input to the National Transit Data Base (NTDB). A secondary reason for data archiving is for service planning, scheduling, and performance analysis.

7.1.3 Use of Archived ITS-Generated Transit Data

            A growing number of transit service providers use AVL and/or CAD systems to help circumvent traffic congestion by better managing their bus operations. Also pertinent to operations and maintenance applications is the archived information on work zones and scheduled work zones for transit.

            Archived transit data have the potential to provide more representative, comprehensive, and timely information on service scheduling, vehicle maintenance, transit management systems, evaluation, and capital planning. These advantages of archived data can fulfill some of the NTDB limitations identified in a recent evaluation^7.1: data timeliness, and data accuracy. In addition, archived data hold substantial promise for providing accurate and timely input to a number of funding apportionment formulae such as the Urbanized Area Formula Program funds, the Elderly and Persons with Disabilities Program funds, and the Metropolitan Planning Program funds.

            Staff at all levels of the public sector use ITS-generated transit data more frequently than those from the private sector, the media, or academia. This suggests that ITS-generated transit data are used to serve both the regional and local needs. Similar to the use of freeway and arterial data, archived transit data are most likely to be used for planning purposes, followed in frequency by dissemination to the public (Figure 7.3).

Figure 7.3 Uses of ITS-Generated Transit Data

(of 138 agencies responded in 1999 survey and 106 in 2000 survey)

7.2 CASE STUDIES OF TRANSIT APPLICATIONS

            Three ADUS transit applications are discussed here: the smart card and the transit signal priority projects in King County Metro of Washington State, the automated transit fare system in New York City, and the operations improvement in the Tri-Met Transit System.

7.2.1 King County Metro

7.2.1.1 System Description

            The King County Department of Transportation Metro Transit Division, commonly called the King County Metro (KCM), is located in Washington State. The KCM, with an annual ridership of over 75 million, operates in a 2,128 square mile area that includes Seattle. The KCM Transit service area is shown in Figure 7.4 in the central portion of the map. The KCM has a fleet of about 1,300 vehicles, including coaches, trolleys, buses, and streetcars.^7.2  There are about 1,000 peak-hour (i.e., rush hour in the morning and evening) buses. About 500 buses are in operation at noon. There is not a lot of coordination of the transit schedules with counties to the north and south; however, KCM tries to have a bus available when the ferry docks.^7.3 KCM and other transportation agencies work together to the extent possible to provide efficient transportation options to the public. For example, KCM feeds data to Smart Trek, a real-time traffic information on-line service for the Puget Sound region.^7.4 In addition, KCM provides options for internet users to view congestion, construction, and road condition information.^7.5 In 1999, KCM began collaboration with six other transportation agencies, including transit, ferries, and rail, to implement a regional Smart Card system. Under this system, the seven agencies provide riders with the option to use one fare card in four Puget Sound counties. Fare collection is done using the Smart Card to allow linked trips between the different agencies.^7.6 

 (Source: http://www.riderlink.gen.wa.us/rl_agency.html)

       The KCM is currently working with traffic engineers in partner cities (e.g., Seattle, Shoreline) to test Transit Signal Priority (TSP). TSP allows specially equipped buses to communicate with traffic signals to hold a green light until the bus passes through the intersection. This is similar to the system implemented in LADOT. The purpose of this system is to increase the efficiency of the buses and to provide a smoother ride for the transit passengers.^7.7 It is not known whether data will be archived from this project.

            The KCM transit system currently collects and archives two types of ITS-generated data and one non-ITS-related type of data. The ITS-generated data AVL data and APC.

7.2.1.2 Data Collection and Data Archiving

            AVL data record the actual time that a transit vehicle is at a specific point. About two years of detailed data have been archived, and there is storage space for about five more years of data. Only the detailed AVL data are stored; any summaries are produced as needed. Data are stored in flat files.^7.8 Real-time AVL data are centrally monitored. About four to five staff people are required to monitor buses during peak periods. If buses are off schedule, the drivers may be contacted via radio. Monitoring also serves to ensure safety and to identify incidents.

            APC data include on/off counts at all stops. The equipment includes a pair of pressure-sensitive mats placed on the steps of the bus. The count for whether a passenger is boarding or leaving the bus is determined by the order in which the mats are pressed when the passenger steps on them. The KCM has sufficient mats for about 15% of the buses; the mats are alternated among buses to collect counts for all routes. Data are manually downloaded once each week. KCM has been collecting APL data for about 15 years. Both detailed and summary data are stored. Archived data are retained in compact disc (CD) format.^7.9 These files represent the detailed (i.e., not aggregated across multiple dates) data level.

            Non-ITS data are incident data as reported by drivers or collected from police reports. Although these data are non-ITS in nature with respect to collection methodology, they are stored for potential future use.^7.10

            In addition, although there are currently no cameras on the buses, the KCM plans to add 200 Digital Video Recording Systems on transit buses in a few months. The systems will include storage devices; however it is not known how any of the camera-based images will be stored or used in the future.^7.11

7.2.1.3 Data Sharing

            The KCM owns the data stored from the transit data collection effort. Several potential opportunities exist for storing and sharing ITS-generated data from the KCM. For example, the DVRS data could be used for safety purposes, and TSP data could be used by traffic engineers for strategic planning and analysis.

            Currently, AVL and APC data are archived and used for multiple purposes. The AVL data are used by transit schedulers. One of the primary uses of the data are by KCM to check for schedule adherence. In addition, historical AVL data are run through a scheduling package called HASTUS^7.12 to analyze, and possibly revise, schedules to cover 80% or 90% (or whatever is desirable) of the riders.

            The AVL data are used to provide real-time arrival/departure times at two transit stops – a feature called TransitWatch. Actual arrival/departure times are also posted on the internet at two sites – “BusView” (http://transit.metrokc.gov/bus/busview.html) and “MyBus” (http://www.its.washington.edu/mybus/). The web sites allow slightly different methods for potential passengers to preplan their trips. This website information was programmed by and is currently managed by the University of Washington using real-time (i.e., not archived) KCM data. The University of Washington also used these archived data to develop an algorithm that predicts the arrival time of transit vehicles.^7.13

            The AVL archived data are combined with vehicle count data collected by the Puget Sound Regional Council to perform a congestion management analysis. This analysis is required by the Federal government and is also used by the Seattle Metropolitan Planning Commission (MPO).^7.14

            The APC are used by transit managers and planners to perform route productivity analyses, and to determine new routes and schedules.

            The incident data are recorded for future safety analysis. There is no interface with commercial vehicle operations. Table 7.2 shows areas of current usage.

            In general, the archived data are shared with anyone who makes a request. However, it was decided early on that the raw data will generally not be shared. Computer programs were developed so that appropriate data can be extracted for sharing.

7.2.2 New York City Transit Automated Fare Collection (AFC) System

7.2.2.1. Location and General Description

            The New York City Transit in New York is one of the largest and most complex public transportation systems in the world and has been in operation since 1904. The bus and subway services operate twenty-four hours a day throughout the city. The high point in ridership numbers was in 1946-1947 when there were about 8 million passengers per day. Ridership declined in the 1950's through 1970's but in recent years has been increasing. Currently, an average of over 6 million riders use the New York transit system daily. The New York City Transit includes 468 subway stations. Over 47,600 employees are needed to manage, operate, and maintain the many components of the system.^7.15

            The New York City Subway has an automated fare collection (AFC) system using fare cards. These MetroCards can be used on either the subway or the bus system. There are several types of MetroCards (e.g., unlimited rides, pay-per-ride, student, senior citizen). Purchasers can find out how much time or money is left on their fare card at MetroCard Readers, located at any Metro Station. Currently, about 80% of all subway riders use MetroCard.

            MetroCards are individually identifiable by a serial number. Data can be collected on card usage every time the card is inserted into a fare reader. For example, when a MetroCard is inserted into the meter at the entrance to the subway, the serial number, date and time of entry, subway booth number, type of card, type of transaction, and other details are recorded. No information is recorded when the rider exits the subway, because it is not necessary to insert the card into a reader when exiting.

            Three months of “active” transaction data are kept on line. After that time, the data are archived indefinitely and are retrievable if needed. The MetroCard system has been in operation for about four years. The transaction data have been extracted and studied extensively for about a year.^7.16

7.2.2.2 Uses of Archived Data

            The New York City Subway system needed to conduct an origin-destination (O-D) study to determine up-to-date ridership habits and future usage requirements. Rather than conduct a traditional O-D study, which is both expensive and time-consuming, transit authorities decided to use existing data available from the fare card transactions.

            Although entrance (i.e., origin) information is obtained by the fare card at the time it is inserted into the meter, exit (i.e., destination) information for a rider is not collected. Therefore, two key assumptions were made concerning how to determine exit locations:

     ●         “people usually return to the exit station of their previous trip to begin their next trip,” and

     ●         “a person’s last trip of the day very often ends at the station where his/her first trip of the day began.^7.17”

The assumptions were validated through use of a travel diary survey conducted by the New York Metropolitan Transportation Council that record actual origins and destinations of transit trips. The survey data showed that use of the MetroCard transactions to determine an O-D pair with the assumptions listed above would yield about 80 to 90% accuracy in determining O-D pairs.

            Two major results occurred from this shared usage of archived ITS data. First, the analysis provided detailed O-D tables by time of day to planners who are responsible for determining modifications to the existing service or for planning new and/or expanded services. Second, the analysis provided peak hour trip data for use with the travel demand forecasting model and other major investment studies. That is, the data could be used to calibrate the model, to look at demand on a zone level, and to supplement journey-to-work data for the Census Bureau.

            It is expected that this concept of shared data usage will be expanded to include bus, as well as subway, data. The results of these studies can be used for many purposes – for example, to identify separate trips, infer the end location of a trip, and allocate station and bus stop groups to O-D zones. In addition, special MetroCard types (e.g., student cards or senior citizen cards) could be studied to learn travel patterns of these special citizen groups. Research results will be beneficial for use by the following:

            ●          New York City Transit authorities to determine routes and schedules,

            ●          the New York Metropolitan Planning Council when examining congestion and traffic management tactics, and

            ●          public-private-educational agencies when desiring up-to-date travel information for various research needs.

7.2.3 Tri-Met Bus Dispatch System Data for Operations, Planning and Scheduling

7.2.3.1 System Description

            Tri-Met provides transit services to the Portland, Oregon, metropolitan area (Figure 7.5). It operates 105 bus lines, 2 light-rail lines, more than 800 vehicles and 9,000 bus stops. In a typical weekday, there are more than 270,000 boardings. Bus Dispatch System (BDS) was activated in October, 1996 with a few test vehicles. The main functions of the BDS are to: (1) improve dispatch capabilities, (2) enhance security, (3) provide real-time information to other systems, and (4) collect operating data.

            This system was implemented as a regular system in June, 1997. All of the vehicles are equipped with a satellite GPS-based AVL system, and half of the vehicles are equipped with light-beam APC. All of the vehicles have a CAD system with a CAD/AVL console. An on-board interface unit reports schedule deviation.

7.2.3.2 Data Collection and Archiving

            Every morning a driver inserts a PCMCIA Data Card into the on-board computer. The card contains schedule information such as routes and stops for the day. In addition, it records (in hexadecimal format) all of the stop data and event data. Stop data include those data elements that are automatically recorded at every bus stop and every door opening, and are listed below:

            Route                                           Ons (Boardings)                     Offs (Alightings)

            Direction                                      Passenger Load                       Door Opening

            Trip                                              Lift Operation                         Dwell Time

            Date                                             Maximum Speed                    Latitude

            Vehicle ID                                   Operator ID                            Longitude

            Stop Location                              Actual Arrive Time                 Actual Leave Time

Scheduled Leave Time

There are 500,000 stop records generated daily.

            Event data include data elements that are collected at the discretion of the operator such as:

            Pass Up/Overload                        Traffic Delay                          Bridge/Train Delay

            Deadhead Delay                           Route Blocked                      Fare Evasion 

            Securement Refused                     Silent Alarm                           Medical Emergency

            Accident                                       Mechanical: Blocking             Mechanical: Lift Problem

            Bill/Coin Jam                                Restroom Break                     Operator Ill

There are about 25,000 event records recorded every day.

            At the end of the day, the driver downloads the data. These data are then matched against the schedule data and stored in ORACLE tables which can be queried for additional analyses. Raw stop data are kept online for 6 months. However, they are not accessible to the public without special arrangement. After the data are downloaded, the PCMCIA card is completely wiped clean and a new route-schedule is stored in the card for the next day.

7.2.3.4 Using Archived Data

            A metadata file (Figure 7.6) that “describes” the data elements in the archived files (a portion of the BDS_Data in Figure 7.7) facilitates the use of the data. The agency uses these data extensively for: scheduling, service planning, operations (for training, fare inspection, and special service planning), project development (including signal priority), streamline, real-time customer information evaluation, facilities maintenance, customer service, and legal matters.

Figure 7.6 Example of Tri-Met Metadata File

Figure 7.7 A Small Portion of the Archived BDS Data

            Furthermore, data are used to monitor on-time performance (Figure 7.8). Between 1997 and 2001, Tri-Met’s overall on-time performance improved from 78% to 83%. The agency attributes this improvement to the use of the archived BDS data.^7.18  Specifically, the agency lists the benefits of using archived data as:

            1.   Reduced and eliminated manual counts,

            2.   Improved data reliability,

            3.   Reduced staff time and cost,

            4.   Complete and timely operational data,

            5.   Improved statistical evaluation,

            6.   Better incident tracking,

            7.   Data available for field personnel,

            8.   Rapid schedule modification,

            9.   Improved schedule reliability, and

            10. Informed service reallocation.

 There has not been much interest expressed from outside parties seeking access to the data with the exception of researchers from the University of Washington. In this case, data access was granted.

7.2.3.4 Barriers to Using Archived Data

            Tri-Met archives its raw bus data and schedule-matched data to tapes (in a Jazz drive). Recovering old data is easy. However, using these data is non-trivial because with the constant changes in bus schedules, stops, and routes, time references have to be established that correspond to the data. Even with the correct time references, any analyses involving a span of time can be very challenging because the changed schedules and routes do not allow for data continuity.^7.19 This example confirms the challenge of integrating data archived from different sources.

7.3 BARRIERS AND SOLUTIONS

 7.3.1 Privacy Issues and Barriers

            The most commonly collected transit data are passenger counts and passenger information, followed by incident information, vehicle time and location, and work zones for transit. One third of transit agencies archive all data elements that they collect, while another third archive none of the data elements collected. The remaining one third of transit agencies archive only some of the data elements they collect. This final group of transit agencies who archive only some of their data elements are of particular interest because they clearly have the capability to archive data, but choose not to. When a number of these agencies were contacted, most of them explained that they had no long term need for the data elements that they chose not to archive.^7.20

            Archived transit data are most likely to be used for planning and scheduling purposes and for performance analysis. Traveler information is another common use of ITS-generated transit data; however, this dissemination of information to the public for this purpose is most often real-time data rather than archived data.

            Two specific transit applications were examined – New York City Transit and King County Metro (Washington State). The ITS data collection feature, selected from the New York City Transit, was use of archived data from the fare card payment system. Although the cards are identifiable by serial numbers, the serial numbers are not identifiable to a particular individual. Therefore, they are not considered a privacy violation.

            King County Metro collaborates with partner cities and agencies with a joint fare card system and to provide real-time traffic information to the public. The King County archived ITS-generated data include automatic vehicle location (AVL) data and automatic passenger counts (APC). Currently these archived data sets are analyzed for trends which are then used by transit managers and planners to perform route productivity analyses in order to optimize transit utilization. They are also used by the Metropolitan Planning Organization to perform a congestion management analysis. The data are shared with anyone who makes a request.

            There are no apparent privacy barriers to sharing the transit data currently collected and archived by the King County Metro. In the future, however, plans call for installation of digital video recording systems (DVRS) on transit buses. The purpose will be to monitor the bus as a safety feature.

            Several cities’ public transit systems, both bus and rail, have used surveillance cameras for a number of years in an attempt to prevent incidents of fraudulent claims, passenger harassment, and vandalism. Nieto notes that video recording devices are generally accepted as being successful in preventing crimes and helpful in prosecuting persons caught on film while committing a crime^7.21.

            Although surveillance cameras are generally accepted by the public when used by transit officials to ensure public safety, it remains to be seen what attitudes will be regarding the sharing and use of transit data outside of the official transit environment.

7.3.2 Technical and Technological Issues and Barriers

            ITS-generated data are used by planners, managers, and schedulers to produce mandatory reports and to improve service and productivity within the transit business community. The greatest barrier to the use of transit data for these purposes is the failure of transit providers to archive the data. Only a third of all transit data collected is archived.

            Another barrier to the use of stored transit data is that other users have not seen the value of the transit data. For example, transit data could be used to coordinate emergency management and evacuation plans – for example in rural areas, nursing homes, and other emergency services. Transit data have not been widely used by academia for research, possibly because research projects using transit data have not been defined.

            Finally, video-based data, as already noted, have large storage requirements and content searches are, at this time, not automated.

7.3.3 Institutional Issues and Other Barriers

            The institutional and other barriers associated with implementing ADUS are largely the same among the different focus areas of ITS. These common barriers such as cost, proprietary rights, politics, and a lack of understanding or knowledge about ADUS are covered in further detail in Chapter 2. Transit faces an additional barrier if competing agencies are unwilling to cooperate in data sharing for fear of losing a “market share” of ridership. The example provided by KCM and adjoining transit providers is a positive example of how sharing benefits customers as well as original data collectors.

7.4 OPPORTUNITIES

            As depicted in Figure 7.3, archived transit data are used more frequently by public agency staff than by the private sector, the media, or academia. ITS-generated transit data are used primarily for planning, route scheduling, vehicle maintenance, informing the ridership, traffic and analysis. All of these uses are valuable to the transit community.

            Case studies and results from our literature review suggest that the transit community has extensively been, and continues to be extremely active in, archiving and using archived ITS-generated data to meet its information needs. That said, opportunities for using ITS-generated data to improve transit operations, maintenance and planning are still plentiful (Table 7.3).

Table 7.3 Potential of Archived ITS-Generated Transit Data

            Rather than try to identify all possible opportunities, this section identifies those that are (or appear to be) feasible, can be quickly deployed, and are most likely to produce immediate benefits/results. The rationale for identifying these “low-hanging fruits” is that the sooner that quantifiable benefits of using ITS-generated data for transit operations improvement are demonstrated and disseminated, the sooner additional deployments will be stimulated. Any of these opportunities identified below can be developed into an FOT with public and private partnership.

7.4.1 ADUS for Assessing Security Vulnerability of Transit Systems

            The terrorist attacks on September 11, 2001 deepened the security concern that transit agencies and transit management have faced since the development of modern public transportation in the mid-1800s. To prepare for future threats, it is critical to assess the vulnerability of our transit infrastructure, identify the weak links, and develop strategies to reduce the vulnerability.

            A digital multi-modal transportation network that is populated with archived data from AVL and APC systems, trip origins and destinations, non-transit traffic flow, facility capability information, and other transit operation characteristics can provide valuable information to assess the vulnerability of the nation’s transportation system and to identify the weak links. With suitable algorithms and software (many of which ready exist), the vulnerability, resilience, and redundancy of our nation’s transit systems can then be assessed.

            It should be emphasized that ADUS alone can not satisfy all of the information needs for an assessment of our transit security vulnerability. However, when integrated with other data sources (e.g., highway monitoring data, remotely sensed data) and tools, ADUS can provide an indispensable base to do so.

7.4.2 ADUS for Emergency Management and Preparedness of Transit Systems

            In order to reduce the vulnerability of transit infrastructure to the consequences of intentional harm to the system, its employees and its users, all transit systems are encouraged to develop and implement a proactive system security plan. Furthmore, all transit systems are encouraged to develop this plan that also ensures that the community's transportation needs continue to be met during and after the emergency. Therefore, it is crucial to develop this proactive security and emergency preparedness plan based on realistic, system-specific data. ADUS data can help meet this information need.

            The aforementioned digital multi-modal transportation network can also be used to evaluate the consequences and feasibility of alternative strategies on evacuation and re-routing. For example, if a link(s) were to be closed or destroyed, do alternative, parallel routes exist to accommodate the lost service? Are there adequate equipment and operators to accommodate the lost service? How should these equipment be routed and the drivers be scheduled to ensure that mobility needs are met? How long will it be before these alternative routes reach their capacities? What will then be the alternatives to these alternative routes?

            During transit emergencies, personnel from many agencies must come together to manage the incident, performing such tasks as rescuing or evacuating passengers, extinguishing fires, controlling crowds, repairing track and wayside structures, and restoring service. Under these circumstances, a seamless integration among these agencies is crucial. Archived information from integrated ITS deployments such as ramp metering preemption, signal priority and route guidance for emergency vehicles and transit vehicles can help evaluate how well the local law enforcement, fire departments, medical emergency services and transit services work together to respond to emergencies.

7.4.3 ADUS for Transit System Operations and Maintenance

            Planning for transit operations and maintenance can progress from a reactive mode to a proactive one by continually adapting and learning from historical patterns and trends. For example, the variance between the actual and scheduled locations of transit vehicles can support decisions to improve schedule adherence. Traffic and signal timing data, in conjunction with other available transit priority and locational data, can help develop preferential signal timing and routing strategies, and evaluate the effectiveness of these strategies.

7.4.4 ADUS for Paratransit for Special-Needs Groups

            Almost one quarter of the transit vehicles operated by the 78 most congested areas have the capability to provide demand responsive flexible routing and scheduling.^7.22 Archived data from AVL can support the development of proactive demand-responsive computer-aided routing and scheduling algorithms that can optimize vehicle assignment and routing to meet non-recurring public transportation demand. Archived transit data can further assist in determining priority programs (e.g., the elderly, students, handicapped, or rural passengers).

            As previously mentioned, any of these opportunities can be developed into an FOT with the goals of:

            ●          identifying technical and institutional barriers to archiving, using, and sharing ITS-generated data;

            ●          developing solutions to overcome these barriers;

            ●          identifying issues pertinent to standards development;

            ●          examining the feasibility of integrating ITS-generated data with data collected from traditional and emerging technologies (e.g., highway monitoring data, remotely sensed data);

            ●          identifying and quantifying costs and benefits;

            ●          disseminating lessons learned, and

            ●          sharing the developed procedures and software in an open-source environment. Some examples of these procedures and software are: those developed to convert raw ITS-generated data into formats acceptable to existing and/or off-the-shelf data management or analysis software, check the quality of the data, impute missing data, correct questionable data, abstract information suitable for data analysis from “text” files, estimate potential recurring and non-recurring traffic delays, and other applications. The benefit of sharing these procedures and software in an open-source environment is that it reduces the “re-inventing the wheel” thus enabling more efficient use of resources.

ENDNOTES:

Return to Table of Contents