Transit GIS Applications in Fairfax County, VA

Wenyu Jia, Transportation Planner

Fairfax County Department of Transportation

Phone: (703) 324-1158

Email:

Brendan Ford, Senior GIS Analyst

Fairfax County Geographic Information Services

Phone: (703)324-3792

Email:

Abstract

The Fairfax County Department of Transportation manages a fixed route BUS system (Fairfax Connector) which encompasses 54 routes on a daily basis. To better support the planning, operation, and marketing of this bus system, the Fairfax County Department of Transportation and the Fairfax County Department of Geographic Information Services formed a team to develop a series of GIS transit applications. These applications will allow end-users to automate, analyze, access, and plot transit-related data. To be successful, the applications must be cost effective and match users technical needs with their abilities.

Paramount to the success of this project is having a transit database capable of supporting all the applications identified by the development team. A number of problems had to be ironed out for the database to be finalized. In the old system, bus routes traveling on different paths could have the same route number. To effectively model this situation in GIS, each path must be uniquely identified. The database also needed to handle other complex problems such as BUS stops serving more than one route and route service depending upon time of day. A route database was built in a Dynamic Segmentation format using Arc/Info v.7.1. Based on this route system, a bus-stop database, stored as an Arc/Info coverage, was related to routes to support many of the queries required by the applications.

Over 15 applications were identified for the three areas of management: planning, operation, and marketing. Planning applications focus on transit service improvement and route restructuring. They include: route service adjustment, demographic and land use analysis within the selected transit shed area, calculating and reporting National Transit Data Base statistics. Operation applications are designed for daily service monitoring. They include: computing route running times, maintaining bus stops, and updating information for emergency service. Marketing applications focus on public outreach and include creating specialized route and stop maps (e.g.: Routes operated during snow emergencies) and publishing route information on the Internet. Most end user applications are built in ArcView 3.0a using Avenue and Dialog Designer. Some applications are built with ESRI’s Map Objects and Map Objects Internet Map Server.

This paper focuses on the applications designed to support the transportation staff and the general public. The effort required to build the database from existing sources will also be discussed.

Introduction

Initiation of Transit-GIS Pilot Project

Transit Operations in Fairfax County

Fairfax County is a fast growing county in the Washington Metropolitan area. Since 1990Since 1990, its population has maintained a steady growth of 2% from 0.8 million to 0.95 million in 1999. In the same time period, major commercial and employment developments have occurred in the county. In the past two years, employment in Fairfax County grew was growing with an annual rate of 5.7%. Growth was particularly strong , in particular, employment in telecommunication and information technology sectors. Growth and development,development coupled with worsen traffic congestion on major corridors to activity centers further pressed the need for the improvement of transit service.

Fairfax County provides its own fixed-route bus system, called FAIRFAX CONNECTOR. It iwas a privatized bus system under the management of Transit Operations Division of the County’s Department of Transportation (DOT). The Transit Operations Division is responsible for planning, marketing and management of private operators. Currently FAIRFAX CONNECTOR carries an annual ridership of over 4.7 million passengers on its 54 routes. With the upcoming major system expansion in the fall of 1999, there will be significant growth of ridership by year 2001. The issue of effective planning and efficient management therefore becomes critical.

Initiation of Transit-GIS pilot project

GIS has been long been applied in Fairfax County’s transit operations, mostly for mapping needs. But it was never intended to facilitate the routingroutine tasks. In May 1998, Department of TransportationDOT put forward the initiative of introducing pursuing GIS in transit. Input of applications was first solicited among staff in transit Transit operations Operations division Division and then a review was conducted between Department of Transportation (DOT) project staff and the County’s Department of Information Technology (DIT) staff. During the process, it was strongly expressed to develop a prototype for performing transit tasks through desktop GIS. A list of selected applications was finalized for the Transit-GIS Pilot project Project and the project team was formed comprising of staff from both between DOT and DIT. The team also defined the pilot area. It consists of three routes and their associated stops in the southern portion of the county. These routes represent three different levels in terms of route structure and performance, including the most complex and overlapping route in the system.

The objective of this transit-GIS pilot project is to demonstrate the potentials GIS could would play have in transit planning, marketing and operations in Fairfax County. Therefore, it is designed to cover all these three interest areas of interestmanagement in Fairfax County. Planning applications aims at service improvements andthe analysis of service area for service improvement. Operation applications targetsto facilitate service monitoring, and marketing applications concentrates on public access to transit information as well as customized mapping. This paper presents the results of the pilot project and discusses the systematic implementation that will follow the pilot phase.

Data and, Software and Hardware

The project started with the identification of existing data sources in the County in order to minimize raw data collection efforts at this initial phase. Before starting the project, identification of data sources and selection of development software and hardware are critical for the success of the project.

Street centerline data, already digitized by DIT, is an excellent the base for route buildingdevelopmentapplications. It offers , offering higher level of accuracy than census tiger file, produced in 1995 from 1 inch: 4000 ft base maps. Land use coverage and data, important for planning analysis, is not readily available at this stage,; therefore are preferred for the analysis. Due to the absence of this data at this stage, we used a combination of the County’s public facility data, planimetric data, and oOrtho photo layer to identify land use features in service area. Census block group data is applied used to provide a fairly detailed level of analysis. Several transit data sources are used in the application, including transit ridership, and boarding and alighting activities. The bus stop database developed by the department DOT is used to develop create a bus stop coverage.

Arc-Info is used to develop the route layer and the bus stop layer, both of which provided as routes and stops are the base for the whole pilot project. Distance measures are required acquired for both route and stop layers using Arc/Info available functions, which can later will be used in the various applications. Development of route and stop layers will be discussed in detail in the section of Building Routes and Stops.

Arc-View, due to its window-based desktop characteristics, is applied used forin the development of final applications for end-users.

Building Routes and Stops

As is often the cases with suburban bus systems, one bus route can contain multiple paths usually depending upon the time of day to serve varying demand. Modeling this situation in a GIS requires that either each path (or route) is stored independently or that the bus route is broken down into its functional components and stored through a series of related tables. The project team contacted fellow GIS professionals with experience using the dynamic segmentation functionality in Arc/Info in the industry to find the pitfalls of using “out of the box” functionality of Arc/Info. The overhead required to store each path and to maintain the information seems to be one of the major differences between those groups who use Arc/Info dynamic segmentation and those who don’t. Therefore, the team decided to conduct route building in Dynamic Segmentation.

Creating Routes

One decision that must be made when creating routes is whether to separate routes into two paths for two directional travel. We found it much easier to break the overall bus routes down into one route feature for each direction. PACE bus service in Chicago actually includes the direction as part of the route naming convention.

Method Applied for the Pilot Project

Our initial method for creating routes was to use the SELECT, MAKEROUTE, REMEASURE, SUBSELECT, and APPEND commands in Arc/Info to create a bus route system. While this output from this method works wonderfully it appears a tedious process. This is possibly the main reason that dynamic –segmentation is not used in some transit agencies. There are also two other problems associated with creating routes in this fashion. First, any route with a loop is excessively time-consuming. Figure 12 gives an example of loop. The route must enter and leave at point A. To create the proper measurements, the user must first build the route up to point A and then use the APPEND and REMEASURE commands for further segments of the route. This is where we committed most of our errors in building routes. Second problem occurred when selecting arcs to include in a particular route, as shown in figure 23 (Illustration of A Possible Missing Link).

In the selection process it appears as though there is only one arc between points A and B. The blow up of that area however, shows there are really two arcs. Failing to select the smaller arc will ruin your route measurements especially when running the REMEASURE command in the loop building process. The simple solution to avoid this is to make sure node features are turned on but this will slow down the redraw process when panning across the network.

Preferred Method Learned over the Process

We found at the end of this project that Arc/Info’s PATH command provides a faster way of creating transit routes than the method previously describeddynamic segmentation. The PATH command uses either a designated file of node locations or a user selected set of nodes to generate route features. The PATH command uses a “shortest-path” algorithm to compute a route between selected nodes. This command eliminates the problems encountered in creating routes by arc selection. Because PATH uses a “shortest path” algorithm there will not be any gaps in the route created. Loops are also taken care of since the stops file will be visited in sequential order. Another advantage of the path command is that nodes used for a particular route can be saved and edited based on changes to a particular route. Recreating or altering routes becomes quite easy under this approach.

During the process, we also examined the possibilities of using Arc View to create routes and stops. With the Network Analyst extension to ArcView the user has the ability to quickly create Route features using the shortest path algorithm. Because route features created by Network Analyst are shape files and not true Arc/Info route systems, certain information necessary to develop applications are missing. As such we feel the main use would be in quickly creating proposed routes for use in project analysis or for mapping purposes, while Arc/Info would fit the best for route system maintenance.

Creating Bus Stops
Our bus stop information currently exists in a paradox database. The stop information is stored with intersection attributes as well as near-side and far-side information. The intersection attributes consisted of two fields, “on-street” and “at-street”. The results from geocoding by intersection are that the stop features are located in the middle of an intersection. Some stops were also located 200-300 yards from the nearest intersection meaning that geocoding by intersection could be misleading as to where the actual stop really is located. Furthermore, during the geocoding process a number of stops were not geocoded because they contained information such as the following: “On-street: Candlewood Dr., At-street: In front of Power plant.”

For two of the routes in the pilot area the team evaluated the approach of using a hand-held GPS receiver for stop data collection to obtain location information. It also allows the user to collect field data other than locations. The results were excellent. Figure 3 presents the result of GPS data collection. The ortho photo in background shows the actual location of the stops collected with GPS vs. the same stops geocoded by intersection. The stars in the upper left of the image represent 2 stops geocoded by intersection attributes. The flags in the center of the image represent theThe flags are actual locations of the 2 stops as collected with GPS receivers. bus stThe flags in the lower right are stops collected with GPS receivers that were not in the original stoops and the stars indicate the stops locations geocoded by intersectiondatabase.

Relating Stops to Routes

Once the stop and route information, they were related in Arc/Info by the ADDROUTEMEASURE command. The only drawback to this method is that stops are related to every route within a user specified search tolerance. For example, although 5 routes may pass a particular stop feature, in reality it might only be a stop for three of the five routes. It is necessary for the user to “clean up” these extra info records. We found this to be relatively easy and possibly something we could automate.

Planning Applications

Purpose of Planning Applications

Transit planning requires planner to have good knowledge of services provided and areas served. Field trips, thus, therefore haves become an inseparable part of a transit planner’s job so that they can visually inspect the services and the served areas, providing visual base for the service and the served area. However, this approach itself would not fully assist planners into acquiringe an in-depth knowledge of the social, economic, land use, and transportation features of the service area. Furthermore, it is not capable of providing a theoretical systematic ground for service justification.

With the development of GIS technology, especially desktop application of ArcViewDesktop GIS applications can , various data sources could be better integrated and utilizedvarious data sources in the analysis and planning of transit service. The prospect of supplying transit planning with powerful and user-friendly tools becomes is feasible and can provide planners with important information promising. Over the years, many transit agencies have used ArcView to develop a profile analysis of service areas.

The planning application developed by the Fairfax County DOTthe Fairfax County Department of Transportation, while focusing on demographic and land use profile, is unique in its own features. It creates an integrated planning process, it provideses planners with user-friendly tools with minimum GIS training required, and it enhances the analytical function by combining decision-making process in the design. Therefore, in addition to achieving a better understanding of existing service, the application will also contribute toin the design of new service by assisting planners’ decision on the optimal service.

Structure of Applications

The planning application is structured as a 5-step model with steps grouped under the planning analysis sub-menu. Users can go through steps in a sequence depending on the type of analysis required. Figure 41 lays outs the structure of the 5-step model.

FIGURE 1: PLANNING ANALYSIS MENU

Figure 4: Menu for Planning Analysis

Analysis of existing service

This analysis only requires deploying steps 2, 3, 4 and 5 under planning analysis. Step 2 creates a shed around routes or stops within user specified buffer distance (Figure 52).

Figure 5: Dialog for Creating Shed


InFollowed by step 3, users can clip any themes within the shed generated, including census, public facilities, and planimetric layers. However, the clipped themes contain data from original the original attribute data in spite of the set disregarding change change to the original unit size. For example, in the case of Use census block census block group as an example, buffer areas may only covers a small portion of a block group and the clipped data actually presents data for a much larger area beyond the shed. Step 4 thus functions to update data with its clipped size. By using Update Info in step 4, all the relevant information will be updated based on the portion of clipped area over original area size. The arithmeticarithmetic is based upon the assumption that the events are evenly distributed within the original spatial unit and the update operation should only be applied for “count” data, and should not be used for density and intensity attributes. Once the data is updated, a dialog will indicate that “The table has already been updated” whenever step 4 is repeated. At this point the user also has the option to view digital ortho photography as a means of visually verifying computed results.