An enterprise GIS is an institutional effort to develop an integrated GIS database to meet the needs of GIS applications across agency departments. It focuses on the consistency, integration and extensiveness of agency-wide applications of GIS. If the project-oriented GIS is considered the first generation of GIS, the enterprise GIS can be called the second generation of GIS.

Several enterprise GIS efforts are under development. The Los Angeles Metropolitan Transportation Authority (MTA) is creating an enterprise GIS database to serve transportation modeling, planning, scheduling and operations, and benefits assessment (Hernandez 1995). GIS was used to track bus schedules and to analyze transit routes. The agency is also linking GIS and automatic vehicle location (AVL) technology with its computer-aided dispatch (CAD) system to maintain and update transit service routes. Expanding GIS services to many departments and providing a more comprehensive GIS database to larger end users in the agency is the strategy in the MTA at Los Angeles.

The city of Calgary in Alberta, Canada has adopted an enterprise approach to implementing GIS technology (Evans 1996). The city has developed a model of the integrated spatial data as a base for the citywide enterprise GIS database. It has also constructed a spatial data foundation to identify the core database and the method of access. An enterprise GIS has also been developed at Tri-Met, a transit agency at Portland, Oregon. A comprehensive GIS database has been developed to support agency-wide GIS applications. It has become a basis for several applications: scheduling, automatic trip planning, real-time bus dispatch and control by means of linkage to automatic vehicle location technology.

At the national and international levels, the Intelligent Transportation System (ITS) and the National Spatial Data Infrastructure movements are leading efforts in increasing interest in enterprise-wide and multiparticipant GIS databases.

At the national level, studies addressing a common database for transportation applications are on the way (Dueker and Butler 1998; Hickman 1995; Okunieff 1994, 1995; Vonderohe eta!. 1997). In November 1992, under the auspices of the Federal Transit Administration’s Advanced Public Transportation Systems (APTS) program and the Intelligent Transportation Systems (ITS) America APTS Committee, the Map and Spatial Database Working Group (MSDWG) was formed to define the requirements for the use of map and spatial data in APTS user service. After a two-year effort, the working group produced a specification for APTS map database-user requirements that provides standards for the transit industry to define and describe transit data elements in a consistent and transferable form. The specification addresses integration issues encountered by various transit database users, and suggests some common definitions, common data entities and common relationships between data (Okunieff 1994).

Several other efforts include location referencing methods for ITS user services (Okunieff 1995), National Spatial Data Infrastructure (Tosta, 1994), and the Spatial Data Transfer Standard (Volpe 1994). These studies address common data elements, structure, and transfer standard issues at the national level; most of them include street networks (Dueker 1995).

This paper examines general database design issues for transit networks, especially at the local agency level. It discusses the GIS database requirements of applications in a transit agency and the need for an enterprise GIS database. It addresses unique yet recurring issues in the enterprise GIS database design for transit networks, including the integration of spatial and temporal data structures, the use of dynamic segmentation, linear referencing and location referencing systems, and the relational structure linking transit networks with street networks. A mechanism to integrate spatial and temporal data to relate the transit route paths and stops with scheduling data is also discussed. The paper also presents some transit applications based on the developed GIS database.

Transit agencies have a wide range of functions such as service planning, operations, scheduling, marketing, customer services, facility maintenance and management, and transit service and land use development integration. These various functions in transit agencies demand a wide spectrum of spatial and attribute data. Service planning needs data on the transit network, location of stops and transfer points. Scheduling needs data on bus locations and scheduling time points. Facility management needs data on the location of stop shelters and conditions of facilities. Marketing needs data on neighborhood characteristics of transit service areas. Finally, customer services need data on transit travel time and the shortest routing given the trip origin and destinations.

Constructing a database to meet different data needs of various transit applications is a challenge. Fragmented databases designed to serve individual applications may result in redundancy and inconsistent databases and applications. This occurs when departments contract for applications developed by different vendors, each with different GIS database requirements. Different vendor products may require an agency to maintain and update different representations of the same street and transit system. What is needed is a common interface to a single representation of a common database of underlying geography. To achieve efficiency and consistency in serving different requirements of transit applications, an institutional coordination is needed to design a general GIS database: an enterprise GIS database. A well-designed enterprise GIS database can provide data to numerous applications.

An enterprise GIS database for transit applications should address, at the minimum, the following relational issues:

A wide range of transit applications can be built from three primary objects of concern to the transit agency:  transit routes, route segments, and stops. These spatial objects can be described in databases with thematic and temporal attributes (such as "the stop at Main and 10th street on Route 110, at 10:00 AM on March 20"). They can be linked by spatial entities such as points (the bus stop at Main and 10th street), linear features that identify the route (Route 110), and temporal elements that identify the time (10:00 AM on March 20).

A stop is a point that specifies a location where a bus stops to load and unload riders. A stop has its own geographic location that can be specified by a pair of coordinates (e.g. latitude/longitude, or (x, y) coordinates). It can also be specified by a linear-referencing location (e.g., the mileage point along a transit route). A time point is a location on a transit route that relates to the transit schedules. It could be a stop, a street intersection, or a landmark. Not every stop is a time point.

A segment is a set of street center-line links. In TriMet, a segment is defined as a discrete series of links that are composed of a set of time points. A set of segments represents all permutations of the route. Route segments are served by the route, but not every segment has transit service at the same time period. Some segments have more service than others in a day. For example, some segments are only served in the peak period.

One, or more than one, consecutive segment comprises a path or a pattern. A pattern or path refers to a unique one-way routing a bus takes on a transit route. (The term pattern is used interchangeably with path in this paper.)

A trip refers to a one-way bus routing that begins from the origin stop to the destination stop on a transit route. Transit trips depend on time and direction, each trip in a route may serve different segments at different tmes. That is, transit trips may take different patterns or paths. Each trip will take one route pattern or path, but one pattern or path may serve many trips.

 These spatial objects can be shown as in Figure 1. Route 110 is composed of four directional segments bounded by time points ABCD: Segment 1—AB, segment 2—BC, segment 3—CD, segment 4—BD. Each segment has two directions, so there are eight possible segments. Segments can be formed into patterns if the ending point of one matches the beginning point of the next. Some possible patterns in the example are:

The transit route, patterns, segments and stops that describe a transit service on a route need to be internally consistent. Of particular concern is the relationship between patterns and stops, because patterns and stops are basic units in transit planning and scheduling. Stops are not bound to segments; rather, they are associated with route and direction. Each route is composed of different segments, and the same stop will have distinct relationships with different routes. In other words, the relationship between patterns and stops of a particular direction on a transit route are dynamic. This common phenomenon is unique in transit and other routing database designs.

The dynamic nature of patterns and stops can be best represented by a linear referencing system using dynamic segmentation (Dueker and Vrana 1992). The distance of a stop on a particular pattern in a specific direction can be assigned by the process of dynamic segmentation, which is discussed in a later section of this paper.

The structure of spatial entities also needs to be externally coherent. One bus stop may serve more than one transit route. The relationship between different routes and stops has to be logically developed, so that it can provide transfer information for riders and better facilitate scheduling. This logical relationship will provide such information as the service overlap and the total quantity of transit service at a specific stop for transit planners as well.

Linear referencing provides a good tool to develop a logical relationship between a pattern and its associated stops in a specific direction. However, it cannot provide a logical relationship among bus stops on different routes and patterns. To identify the stop that serves more than one route and pattern, it is necessary to as-sign a unique identifier (a number, street number and name, or a street intersection) for each bus stop.

Segments contain a route identifier that persists in the aggregation of segments into patterns. The linear reference transformation process creates a scalar distance value from the two-dimensional coordinates of the stop. The remaining piece links the route identifier to the unique stop locations. This is implemented as two relationally joined tables; the route identifier table joined in a one-to-many relation to the stop locations table by a unique identifier referred to as location-id (LOCID). In performing the linear reference transformation process, the appropriate route is selected and joined to the stop locations; this set is then processed and scalar distance is derived. The directionality of the pattern along with a perpendicular distance tolerance is used to exclude those stops on the incorrect street side and other stops that may only be applicable for another pattern configuration (trip) on this route.

The two-dimensional coordinates of the stop are placed to accurately model the location of the stop in reality, relative to the street centerline. The linear distance value combined with absolute coordinates provides maximum flexibility for producing a model of reality.

The linear referencing and the unique identifier provides two consistent ways to identify a particular bus stop: its relative positioning on a transit route and route pattern, and its absolute referencing to the geographic location and the street network. This two-way referencing is very efficient to relate a bus stop to both the transit network and the street network, and to identify the possible transfer points among different transit routes.

For many time-related applications, such as automatic trip planning, and transit scheduling and control, the spatial structure of transit routes, patterns, segments and bus stops have to be linked with scheduling. Of particular importance are the relationships between stops and time points, the identification of time-dependent trips, and how to handle express and limited service that bypass some normal stops.

Bus schedules are related to routes by time points. The physical relationship (distance and direction) between a bus stop and its closest time point can be identified by the assigned distances (mile points) in the linear referencing system.

Transit trips are time-dependent, and different trips may follow different patterns. Therefore, it is important to link the trip to the specific time points, so that the automatic trip planning can identify whether specific segments and stops have transit service. By linking the scheduling with trips, and linking trips with patterns, the temporal element can be consistently incorporated into the database.

In a transit system, there are often express and limited (or short trips) service that bypass some normal stops. A database that fails to recognize this phonemenon will lead to erroneous trip assignments for trip planning. This is handled by linking scheduling data with time points. Express and limited trips have different time points and patterns. Once the express and limited bus trips are identified, the time points and stops on those express and limited trips are compared with the normal time points on the route. If the normal time points do not show at time points on the express and limited trips, those time points and stops are skipped by the express and limited trips.

Linking trips and special services like express and limited service with scheduling has great advantages. First, there is no need to store extra information about the segments, time points and stops. For example, it is not necessary to have an extra item to identify if a time point is an express service time point. Second, the update and maintenance of scheduling and spatial stop location can be conducted independently. Changes in scheduling will not affect the spatial structure of stops and segments, unless the route configuration changes.

Vehicle locations differ from stop locations in that vehicle locations depend on time. Real vehicle location is automatically determined by transit-equipped Automatic Vehicle Location (AVL) through the global positioning system (GPS). However, if an AVL system is not installed, the vehicle locations need to be determined for the purpose of automatic trip planning. The vehicle locations can be estimated from the scheduling and the relationship of bus stops and time points. Even with AVL, this estimation of schedule time needs to be done to calculate schedule deviation, which is important information for bus dispatch and control as well as trip planning.

Assuming the vehicle is on time at each time point, the times at those stops that are not time points needs to be estimated. This can be done by considering the distance, speed and directions of the bus stop to the nearest time point. It should be noted that the estimated vehicle location is only approximate. The basic assumption that the vehicle is on time at each time point may not be valid. Furthermore, the speed between time points is also estimated or based on the posted speed; it does not take into account traffic conditions and other incidents like accidents.

 Linkages with Other Data

A fully integrated transit network database has to have the capacity to relate to other data sources, such as street networks, landmarks, park-and-ride lots, bus fare structure, demographic and land use characteristics. The unique identifier and the geographic location represented by the street address, intersection, permanent landmark, and (x, y) coordinates of each bus stop provide an easy mechanism to relate the locations of segments and stops to the street network and other geographic features such as landmarks and park-and-ride lots. The point and linear features of a transit network need to be related with areal data like demographic and land use data, which is why relating both transit data and demographic land use data to a common street center-line file insures spatial registration.

In summary, transit networks differ from highway networks in several respects:

The challenge for an enterprise GIS database design for the transit network is to address the various demands of applications and these unique characteristics of the transit network (Spear 1994). The following section describes the design of an integrative transit database at Tri-Met of Portland, Oregon to address those issues.

Duplicated data management and maintenance make data exchange and sharing extremely difficult (Onsrud and Rushton 1995; Dueker and Vrana 1994). This was certainly true at Tri-Met. At an early stage in the history of Tri-Met the maintenance of transit routes and stops diverged into two disparate systems managed by two departments: the First Line Miles (FLM) file managed by the Department of Scheduling, and a stop table maintained by the Department of Facility Management.

The FLM system was created to maintain the route system at Tri-Met, and it has become an artifact. It has served the needs of the agency for an input to the schedule run-cutting process (RUCUS). The format of this file was standard text, manually edited. It contained a description of each time point, represented by a node, and intersections as descriptive data along routes in a particular direction, along with a measured cumulative and incremental mileage. Time points have node numbers. To these time-point nodes, the schedule times were linked. Intersections that are not time points are recorded to unambiguously describe the path of the routes.

The stop table was created and maintained by the Department of Facility Management at Tri-Met. It described the physical location of every bus stop by either street name, street intersection and/or landmark. It was associated with a number of other attribute data that are critical to the facility management, such as the existence of a stop shelter and lighting.

The FLM file and the stop table serve two independent applications that are separately managed and maintained. It seemed very difficult, if not impossible, to link these two systems together. Without a logical and relational linkage, the usefulness of these two systems is limited. To meet the increasing demand of advanced transit applications, it is necessary to link these two disparate systems in a GIS environment.

The original FLM file did not contain spatial elements. It could not be used for spatial display and spatial analysis. However, the underlying structure of the FLM contains elements that describe route segments. It was modified to include spatial elements by adding geographic references (x,y coordinates) and placed in a relational database. This resulted in more accurate versions of the FLM using the GIS editing environment in ARC/INFO. This database structure is hereinafter referred to as the Time-point table.

The initial task of obtaining a geographic reference for each time point and intersection point in the FLM file involved geocoding of these points from their text descriptions of geographic locations. The geocoding of the time points and intersections was conducted by using the enhanced TIGER file maintained by Metro, a regional planning organization in the Portland, Oregon metropolitan area.

Once the Time-points table was geocoded, the transit route system could then be constructed around it. The Route and Stop Description Application (RASDA) was created to utilize the Time-point table and the TIGER street network to create a route system based on the route, direction and segment. A graphic user interface (GUI) was created to allow users to customize transit route and node queries and displays, so that the user need only "point and click." By using the GUI system, the user can edit (add, delete and make other changes) the tabular data and spatial points in the Time-point table from within the GUI environment. The RASDA can automatically regenerate the route system based on the time points, intersections and TIGER street network using the pathfinding algorithms in ARC/INFO. The new route system represents sets of segments in a particular route and direction. Furthermore, the RASDA can automatically recalibrate the route system to a new street base. Old nodes are calibrated to new node position by rubber-sheeting link or "near" function in ARC / INFO. The road system is then regenerated using new nodes (time points). The RASDA is capable of being used in other ARC/INFO AML applications.

After the Time-point table and the RASDA were created, it was convenient to generate a route table that describes the shape and the spatial location of the transit route system. However, the Time-point table and the route table have no information about the stops. The time points and non-time-point intersections may not necessarily be transit stops.

The transit stop information was stored in two tables:  the Route/Stop table and the Stop Location table. The Route/Stop table contains an ordered set of bus stops for each route in each direction. Each bus stop was assigned a stop number and a location identifier (LOC_ID). The stop number identifies the order of the stop on the route by direction. The location identifier (LOC_ID) was assigned to uniquely identify the stop within the system. If one stop serves two on more transit routes, this stop will have two or more different route stop numbers but only one LOC_ID.

The Stop Location table describes all locations that have (or used to have) a transit stop and/or amenity. It describes where the transit stops are actually located by street addresses, intersections or landmarks. The Route/Stop table is linked to the Stop Location table in a many-to-one relationship by the LOC_ID.

To integrate the Route/Stop table and the Stop Location table with the route table and Time-point table in the RASDA environment, it was once again necessary to add a spatial component to the existing data by adding (x,y) coordinates from the enhanced TIGER file to the Stop Location table. The addition of the Stop Location table to the RASDA environment makes it easier to update stop information. A change of (x,y) position in the RASDA environment would update the coordinates in the location table. The RASDA essentially became a geocoding front-end for these stop tables. Additional functionality was added to the RASDA to display stop locations by route, on simply by location or location identifier. This facilitates querying which transit route(s) a particular stop serves, and which laid a strong foundation for scheduling the timed transfer system and automatic trip planning.

An important difference between transit networks and highway networks is that the service and physical layout in transit networks is separated. The previous discussion focused mainly on the physical locations of routes, time points and stops. There has been no information regarding whether and when the route has service yet. As discussed before, transit service in a transit route will serve different route segments at different time periods, especially for some shorter trips and some trips that deviate from the main route. In other words, transit trips depend on time; each trip in a route may take different unique routing patterns or paths at different times.

The route pattern or path is identified by extracting a list of segments and time points in a particular direction. The process for doing this is to form records consisting of a pattern designator with a list of segments that comprise that pattern, so that the endpoint of the previous segment matches the beginning point of the current segment. An interface was constructed to produce a file containing information about ROUTE, DIRECTION, PATTERN, SEGMENT for each list of segments that form that pattern. These data are imported to construct the Pattern Correspondence table. The aggregation of segments into patterns proceeds according to the order of entries in the Pattern Correspondence table.

Once the route patterns are identified, the time-dependent trips are controlled by the scheduling data. The scheduling data determine which pattern a particular trip takes at a specific time point through linkages to time points.

The ability to recognize trips and patterns at a particular time point provides a tool for displaying transit trips by time of day and for assisting real-time applications on trip planning, customer information service, and real-time automatic vehicle location.

For performance considerations and to maintain division of data maintenance responsibilities, no attempt has been made to snap stop locations to the route segments or to time points. This task is left to the linear reference system. A linear referencing process is performed to relate stops, time points and route patterns together. This process establishes a commonality between stops and time points to determine the distance of each stop and time point along a route pattern, and the relative relationship among stops and time points.

Linear referencing of stop time points in a route pattern was completed by the use of dynamic segmentation functionality in ARC/INFO. The dynamic segmentation process assigns a distance value to a set of points for a given linear feature—in this case the distance of the stops and time points along a particular route pattern by each direction.

To produce a system suitable for display as well as analysis, a complete set of time points and stop points must be provided in the linear reference data set. To this end, the time points, stops, and shape points (nodes that define the turning points of the route arc that were generated from the TIGER street network) from the RASDA environment were extracted for each route pattern.

The dynamic segmentation process generates three distance tables that describe the distance of time point, stops and shape points on every bus route pattern and direction staring from the beginning of each trip.

The dynamic segmentation process assigns distance values to time points and stops along a route pattern, so the relative relationship between stops and time points can be easily identified. However, trip planning and bus dispatch may need to know the location of a bus on a transit route in addition to the location of a bus stop. Before an automatic vehicle location system is installed, the bus location at a particular time can only be approximated from the scheduling data. The outputs of the dynamic segmentation can be used to rectify disparate transit data elements and to determine the approximate bus location by assigning a time to each stop based on a sparse set of time points, accounting for layovers, and limited and express routes.

Before assigning a time to a bus stop, it is assumed that the bus gets to the time point on time. That is, the scheduled time at a time point is the real time a bus gets to that point. To assign a time to each stop, it is necessary to know the direction and distance of a stop to a time point where the scheduled time is known, as well as the speed of the bus between two time points. The distances of each time point, stop, and shape point on each trip has been obtained from the dynamic segmentation. Therefore, the distance and the direction between a stop and a time point can be identified.

To take into account variable service, such as limited/express service and shorter trips, each stop a bus visited must be explicitly stated in this table. The dynamic segmentation process will add the distance of each appropriate stop to this table.

The eventual goal is to produce an earliest and latest time a bus may get to each bus stop. The earliest and latest time provide a deviation window for the time a bus may be at a stop. They are based on the minimum and maximum velocity possible through the network. The amount of interpolation introduced is in direct proportion to the distance to a time point.

Once the time is assigned to each stop, it is a simple matter to generate the extract files necessary to assemble data for application systems such as trip planning and bus dispatch. Furthermore, it makes the spatial query and display of bus locations more convenient. By selecting a time point, for example at 8:30 am, the system can display all the estimated locations (approximate to a time point) of all the buses on service in the network. With the installation of GPS-equipped automatic vehicle location system, the system can display the exact location of every bus in real time, and determine schedule adherence and on-time performance.

The bus dispatch system has on-board units (OBIU) with global position systems (GPS) and data logging via Personal Computer Memory Card International Association (PCMCIA). The memory cards record data for each stop with the following data items: bus arrival and departure time, stop distance from the start of the trip, and the longitude and latitude of the stop location (from GPS).

The logging proceeds when a door opening occurs, or when the vehicle passes through a known stop. In the latter case a log record is generated with no door opening flag, and arrival and departure time will be set equal in translation to the RASDA table.

The data items logged on the memory cards serve a number of critical functions. Data from the PCMCIA logs are utilized to locate stops missing in the database, to connect physical location of stops, to identify topological inconsistencies, to detect out-of-synch Geobase/ OBIU data sets, and to detect route inconsistencies/ missing street segments. Furthermore, they can be used to check for schedule adherence. In a word, the PCMCIA logs are used for feedback to correct the ground locations for the stops, and pinpoint errors in the route network/street base. The corrected data are then loaded back into the on-board units and the process continues.

By building a spatial model from the log data, stop location can be statistically determined over time, enabling the rectification of the location errors. This method may drastically reduce the need for manual correction of physical locations of stops in the geobase.

The enterprise GIS database developed at Tri-Met has become a foundation for several applications in the agency An automatic trip planning system has been developed to provide trip planning information for customers. A bus dispatch and control system is in operation based on the enterprise GIS database and the automatic vehicle location (AVL) system. Transit service planning uses it to conduct service analysis and plan network routing. Many other applications, such as the integration of demand-responsive service (paratransit) scheduling are being implemented.

An important function of traditional customer information systems is to provide customers information about routes and schedules by offering route maps and printed transit schedules. Either customers or customer service has to plan a trip based on the printed map and schedules. However, the customer and the customer service has little knowledge whether the planned trip is the optimal one.

The designed automatic trip planning (ATP) system in Tri-Met offers customers optimal trip plans on demand. When a customer calls, the ATP system can automatically direct the customer to a bus stop of a transit route and plan an optimal trip based on the shortest trip time which includes walking, waiting and in-vehicle time.

Because the GIS database has a dual reference system of identifying bus stop locations, the ATP system has been able to easily identify the locations of the origin and destination of a customer, and the relationship of those origins and destinations with bus stops and routes.

Traditional transit dispatch and control rely on the direct communications between the driver and dispatcher via two-way communication channels. Drivers are required to monitor their own arrival times, and to call into the dispatch center for time checks. The dispatcher has difficulties in monitoring and controlling the bus operations because there was no capability of viewing bus locations on the screen. Tri-Met is using the computer-aided dispatch (CAD) coupled with an automatic vehicle location system, which provides an effective and efficient tool in bus/rail dispatch and control.

With the CAD system, each bus or rail is equipped with an on-board intelligent vehicle logic unit. The on-board processor is linked with the dispatcher center. Once the driver logs on with an identification number, vehicle number and route code, he/she can immediately receive his/hen route assignment with schedule details on the on-board processor.

As a bus on rail moves along its scheduled route, a GPS receiver on the vehicle provides current position in-formation to the vehicle’s on-board processor, and a location report can be transmitted from the vehicle to the dispatch center by short-wave radio communication. At the center, dispatchers monitor the real-time progress of buses on digitized maps displayed on computer screens. The real-time information is then disseminated to the public kiosks and other systems such as the Internet. The developed GIS database became the backbone of this CAD information display and storage.

The CAD system is very useful for checking route and schedule adherence, and improving on-time performance. When the bus goes off the scheduled route, the on-board processor will notify the dispatch center immediately. Dispatchers can track current bus location and status on the display screen through colored icons. Throughout the scheduled route, the driver and dispatcher receive updated messages of schedule status automatically, which helps to check and evaluate the route schedule.

The CAD system can also be used to display real-time bus status messages on electric signs or touch-screen kiosks on bus/rail stops and park-and-ride lots, in conjunction with "static" information, such as bus route maps and schedules. Real time information dissemination through the Internet is also under way (Vorvick and Dueker 1998). We felt a good spatial database is the key for the efficient map display of real time locations of transit vehicles. This is echoed by the Federal Transit Administration’s conclusion that spatial data are considered to be the most important issue that defers a number of transit agencies from implementing the CAD system (Federal Transit Administration, 1994). An efficient database can facilitate and accelerate the use of the CAD system throughout the United States.

Transit service planning and scheduling deal with service demand and supply, as well as the spatial equity and efficiency issues of service allocations. This analysis of the transit demand and supply is accomplished by identifying spatial distribution of transit service, rider-ship, and their interaction with demographic and land use characteristics (Peng and Dueker 1995).

The developed GIS database provides transit planners a tool for planning analysis and performance evaluation. For example, service planners can use the database to identify and display major sources of transit ridership (boarding and alighting) by time of a day at the stop level, route segment level or route level, so that they can determine the level of service on the route level and evaluate the route on route segment performance based on the observed ridership. The identification and display of major sources of transit ridership along with underlying demographic and land use information are also of interest for market analysis. Market analysts can use this information to target the major market areas to market transit services and to attract more transit users.

The challenge for route planning is to cover as many transit origins and destinations as possible while providing users with direct routings. The GIS database allows planners to identify potential transit stops to be served and to generate transit routes automatically. Transit planners can use the GIS data to identify the demographic and land use characteristics within walking distance of a proposed transit route and can then estimate potential transit ridership at the route-level (Peng et a!. 1997). Every time planners lay out a new route or intend to make a route configuration change, they can know the demographic and land use characteristics of the route coverage area, and the potential ridership changes.

The GIS database has many other potential applications in Tri-Met, notably, the schedule coordination of fixed-route service and door-to-door paratransit service. Paratransit vehicles are most likely to use streets not assigned to fixed routes. Door-to-door service requires address, intersection, and landmark geocoding in the street network, with grouping and routing procedures for scheduling (Dueker and Vrana 1991). The full integration of fixed transit routes with the street network provided in the GIS database afford an optimal coordination in scheduling the paratransit service with the fixed-route services. Paratransit service may be provided as a feeder service to fixed routes, so that paratransit riders can transfer to fixed routes at the transfer point. Timed transfer scheduling is particularly important here. With the schedule time and location of a fixed route, and with a known geometric and topological relationship of the fixed routes and the street network, the GIS database makes paratransit scheduling more efficient.

The GIS database is also useful to schedule transit service to accommodate a planned event, such as a special event or large festival. Once the location of a special event is identified and geocoded, the GIS is capable of scheduling a special bus service to link the event location with the fixed route service, as well as to make adjustment on the level of service on the original fixed route service.

The prosperity of GIS implementation at transit agencies demand an integrated enterprise GIS database to meet the needs of a wide range of applications. The challenge of the transit GIS database design is to integrate spatial features in the transit network and the temporal service variations. The GIS database design described in this paper offers a general solution to this challenge.

The spatial features in the transit network (route, segments, patterns, stops and time points) are logically linked by the dynamic segmentation process and the dual reference systems (linear referencing and location referencing). The dynamic segmentation in the linear referencing system links bus stops and time points within the same route and trip. The location reference system links stops across different routes. It also registers the transit network to the street network and other geographic features like landmarks, which provides the basis for online geocoding and trip planning.

The temporal service variations were integrated with the spatial structure of transit features by relating the service scheduling with transit trips and patterns. This provides an efficient way to handle temporal and spatialservice variations in the transit network, such as service routing deviations, shorter service, and express service. No extra item is needed to identify if a stop is an express stop. The update and maintenance of service scheduling and spatial locations of stops and routes can be conducted independently. The integration of service scheduling and spatial variations also provides a basis for service scheduling and control to plan timed-transfer service, and to estimate the approximate bus locations relative to time points.

The database developed at Tri-Met has become a foundation for several applications. The automatic trip planning uses it to conduct online geocoding and to plan optimal trips for customers on demand. The GIS database is used by bus dispatch and control for efficient display and query of bus locations. It is also used by scheduling to manage and update changes in scheduling and locations of routes, segments and stops. A well-designed enterprise GIS database can provide an efficient solution to meet the needs of a wide range of transit applications.

 References

Dueker, K.J. and R. Vrana 1991. "GIS Applications in Urban Public Transportation: A Case Study of Tri-Met, Portland, Oregon." In Proceedings of the 1991 Geographic Information Systems for Transportation (GIS-T) Symposium, ed. by D. David Moyer and Barry L. Larson. Orlando, Florida, pp. 277—292.

Dueker, K.J. and R. Vrana. 1992. "Dynamic Segmentation Revisited: A Milepoint Linear Data Model," URISA Journal, Vol. 4 (2): 94 —105.

Dueker, K.J. and R. Vrana. 1994. "Sharable Digital Road Map Databases: Functional, Representational, Institutional Issues." In Proceedings of the 1994 Korea-U.S. Symposium on IVHS and GIS-T,Seoul: Korea Transportation Research Society, pp. 131—148.

Dueker, K.J. 1995. "Access to Data: National Spatial Data Infrastructure." Presented at the 74th Annual Meeting of Transportation Research Board, Washington, D.C.

 Evans, D. 1996. "Enterprise GIS: You Take the High Road In Proceedings of URISA 1996 Annual Conference, Volume 1, pp. 424 —429.

Hernandez. 1995. "Enterprise-wide GIS Reduces Traffic Congestion." GIS World, Vol 8, No. 4., pp. 48—51.

Hickman, CE. 1995. "Feature-Based Data Models and Linear Referencing Systems." Presented at the 1995 Geographic Information Systems for Transportation (GIS-T) Symposium, Reno, Nevada

Okunieff, P. 1994. "APTS Map Database User Requirements Specification: Version 1.0." Unpublished.

Onsrud, H.J. and G. Rushton (eds.). 1995. Sharing Geographic Information, Center for Urban Policy Research, New Brunswick, NJ.

Peng, Z. and K.J. Dueker. 1995. "Spatial Data Integration in Route-Level Transit Demand Modeling," URISA Journal, Vol. 7(1): 30—41.

Federal Transit Administration. 1994. "Advanced Public Transportation Systems: The State of the Art Update ‘94," Washington, DC, FTA-MA-26-0007-94-1, DOT-VNTSC-FTA-938.

Spear, B.D. 1994. "GIS and Spatial Data Needs for Urban Transportation Applications." In Proceedings of the 1994 Geographic Information Systems for Transportation (GIS-T) Symposium, ed. by D. David Moyer and Tom Ries, Norfolk, Virginia, pp. 31—41.

Tosta, N. 1994. "Continuing Evolution of the National Spatial Data Infrastructure," In GIS!LIS Proceedings, Washington, D.C.: ACSM, pp. 769—777.

Volpe National Transportation System Center. 1994. Spatial Data Transfer Standard: Transportation Network Profile: Version 1.0

Vonderohe, A. 1997. "A Generic Model for Linear Referencing Systems." Research Results Digest 218, NCHR~ Sept. 1997.

Zhong-Ren Peng is assistant professor of urban planning at the School of Architecture and Urban Planning, University of Wisconsin-Milwaukee. His research interests include Internet-based GIS, spatial database design, and GIS applications in transportation and urban planning.

Jonathan N. Groff is a geographic information systems engineer for Tri-County Metropolitan Transportation District of Oregon. He has created several GIS projects to serve AVL bus dispatch, automated trip planning, and production scheduling environments. His works include spatial data structures, linear reference systems, and distributed geographic databases.