Development of Web-Based Transit Trip Planning System Based on ...

DEVELOPMENT OF WEB-BASED TRANSIT TRIP PLANNING SYSTEM BASED ON THE SERVICE ORIENTED ARCHITECTURE Daniel(Jian) Sun*, Ph.D Assistant Professor School of Transportation Engineering TongJi University 4800 Cao’An Road, Jia-Ding District Shanghai 201804, China Phone: (86-21) 6958-3695 Email: [email protected] Zhong-Ren Peng, Ph.D, Chair and Professor Department of Urban and Regional Planning University of Florida P. O. Box 115706 Gainesville, FL 32611-5706 Email: [email protected] And Cheung Kong Chair Professor School of Transportation Engineering, Tongji University Shanghai, China Weiya Chen, Ph.D Assistant Professor School of Traffic and Transportation Engineering Central South University 932 South Lu-shan Road, Changsha 410075, China Phone: (86-731) 8876739 Email: [email protected] Xiaofang Shan, Ph.D Assistant Professor School of Economics and Management TongJi University Shanghai 20092, China Phone: (86) 133-1173-9866 Email: [email protected] Word count: 6,053 + 5 Figures + 1 Table = 7,553 Paper submitted for possible presentation and publication at the 90th Annual Meeting of the Transportation Research Board in response to the Call for Papers: Emerging and Innovative Public Transport and Technologies Call for Papers (AP020) Nov 15th, 2010 * Corresponding author

TRB 2011 Annual Meeting

Paper revised from original submittal.

Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

2

Abstract The majority of transit trip planners currently exist as proprietary systems based on particular vendor products. With more functional components incorporated, the system maintenance and regular transit information updates become burdensome tasks for the transit agencies. Additionally, the proprietary nature of the systems makes it difficult to take advantage of the rapid advancement of geospatial information and Web technologies. This paper proposed an open and interoperable transit trip planning system based on the service-oriented architecture (SOA), with the principle to reuse the existing modular resources, while providing friendly interfaces for future functionality expansion. The objective is to integrate geospatial services available online (such as Google Maps), open-source geospatial database technologies, and path-finding algorithms in a loose-coupled manner. The proposed system was developed with the spatial and temporal transit data from Waukesha Metro, WI. The search results were validated by comparing the outputs from the existing South-East Wisconsin Transit Trip Planner, and the route schedule matching. The comparison results show that the new service-oriented architecture provides a flexible and efficient mechanism for transit trip planners that takes advantage of rapidly changing online geospatial services, yet maintains the core functions of itinerary search that may be unique to each transit agency. Key Words: Internet GIS; Service-oriented architecture; Transit customer services; Transit trip planning system.



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

3

1. INTRODUCTION Disseminating transit-related information appropriately and timely is a goal that most transit agencies are striving for. Results from a survey on the effect of advanced transit indicate that about 38% of non-transit users would consider transit if appropriate information was available (1). Historically, transit agencies relied on call centers or route and schedule brochures to provide passengers the schedule and route information. However, this method is inefficient, especially in cases where the route network is complicated and in a grid manner. Moreover, transit schedules are changing regularly, which brings large redundant work in the brochure update and dissemination. This motivates the development of online transit trip planning systems to assist transit users to schedule trip itinerary and acquire instructive transfer and bus departure information before the trip begins. Web-based online transit information systems facilitate transit information update and dissemination, since the schedule and route information are typically stored in the data server, and only require to be updated once in a while centrally. Over the last twenty years, as technology changes, Web-based online transit trip planning systems have been evolving in three major aspects: path-finding algorithms, spatio-temporal data models and system architectures. Path-finding algorithms aim to develop efficient procedures to search for trip itineraries or paths in a transit network given the trip origin, destination and time of travel. Spatio-temporal data models aim to construct efficient and robust spatio-temporal data structure to better store and search transit schedules and route/stop location data. System architecture research is to develop efficient architecture to link end users, data, and path-finding algorithms together as a functional trip itinerary system. A considerable amount of research has been conducted in the development of path-finding algorithms and spatio-temporal data models (2-6), as well as on the system architecture (7-9). However, the system architecture seems to be the least developed and the most problematic one, especially in the environment of rapid advancement of Internet technology and Web applications. The main problem within the system architecture is the proprietary nature of the systems, which are based on particular vendor products, rather than an open and interoperable system. The challenge is how to design an architecture framework to largely utilize existing resources (i.e., proprietary components and online resources), while provide expansible and extensible interfaces for future functionality upgrade. This paper documents and reports our recent work in advancing the state of the art in transit trip planner architecture, which was built upon our work in this area over the last decade. Specifically, the paper describes the efforts to develop an interoperable transit trip planning system (Waukesha Metro Transit Trip Planner) based on a service-oriented architecture (SOA) by taking advantage of existing geospatial services that are available online. These include Google Maps, PostgreSql database management system, AJAX (Asynchronous JavaScript and XML) technology, as well as the existing path-finding components that were developed previously. The merit of this system architecture is in its interoperable and non-proprietary nature, especially in taking advantage of many existing resources and free services online. Even some services, such as Google Maps, are based on existing business models and are subject to change in the future, but still the potential cost savings in the



Sun, Peng, Chen and Shan, 2011

4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

immediate near term are very real and thus worthy of consideration as proposed. The general purpose of this research is to present an interoperable Internet GIS approach in developing an online transit trip planner by adopting the service-oriented architecture and computing environment. More specifically, three sub-objectives are:

26 27 28 29 30 31 32 33

This section starts by reviewing several widely studied and used online trip planning systems from the perspectives of path-finding algorithms, spatio-temporal data models and system architectures. Next, Web service based SOA, as a new approach to address distributed computing, was introduced as a potential solution to improve and organize the existing systems. Finally, the application of SOA technologies in building a trip planner system is proposed.

34 35 36 37 38 39 40 41 42 43 44

Many Web-based trip planning systems, from simple static text schedule display to more sophisticated real time trip estimation, have been built during the last twenty years (10, 11). Peng and Huang (8) classified the online transit information systems from two dimensions: information content and system functionality. The content information ranges from static information to dynamic real time information:  Type A, basic information about the agency and services;  Type B, static information about transit routes, service schedule and fares;  Type C, trip planning and itinerary information; and  Type D, real time information about bus locations and the expected arrivals The system functionality ranges from information dissemination to interactive communication and online transaction. By this classification, many existing online trip

 To develop a new system framework and introduce SOA for the existing components reuse and future functionality expansion;  To design an interactive graphic user interface (GUI) with embedded geospatial analysis and map rendering components from PostgreSql database and Google Maps; and  To improve and implement a schedule-based path-finding algorithm based on a pattern-centered spatio-temporal transit network model The remainder of this paper is organized as follows: Section 2 reviews the literature on the existing transit trip planning systems and SOA. Next, descriptions of the system framework and the basic functional components implemented are presented in Section 3, where the feasibility and necessity of SOA are discussed, with a focus on implementation details. In Section 4, the key functionalities, such as the start/end bus stops positioning, geospatial operations and transit network analysis components are explained, followed by discussions on encapsulating them as online services. Finally, conclusions and recommendations for future work are provided in Section 5. 2. LITERATURE REVIEW

2.1 Web-based Transit Trip Planning Systems



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

5

planners, including the trip planning systems to be reviewed, focus on disseminating or providing interactive static transit information or trip itinerary information. Google Transit Trip Planner (http://www.google.com/transit) has been used in many cities to access public transit schedules and routes, and to plan trips (12). Transit information provided by this system includes: 1) the upcoming departures, step by step directions for the entire itinerary, and travel time and transfer information; and 2) the recommended bus route drawn along the streets on Google Maps, which provide free quality maps with automatic Geo-spatial features update. In view of path finding, Google Transit requires users to input the origin and destination locations, together with the scheduled departure/arrival times to obtain the trip route(s) and schedules. The spatio-temporal data structures of Google Transit are largely dependent on Google Maps, for both search results display and users’ point-and-click on the map to define the origin and destination. One disadvantage is that the transfer points of search results are not marked out on the map. Moreover, the system architecture and path-finding algorithms of Google Transit are sealed in a black box, and hidden from the users with no detailed technical “white paper” available. The system is not designed to connect with existing transit trip planning systems that many transit agencies have already. Other limitations include that Google Transit only supports “shortest-path” searches with specific departure time or arrival time, with no other search options (e.g. minimal transfers) provided. Cherry et al. (13) designed an interactive online trip planner for the Sun Tran bus network in Tucson, AZ. In view of path finding, users of this system can prepare the trip origin and destination from three options: manually typing in text addresses, selecting from landmark pull-down menus, or clicking the geospatial locations directly on the map. A forward-searching algorithm was implemented and executed either from the origin to the destination, or from the destination back to the origin (14). With each O-D bus stop pair, the algorithm traces a minimal possible time path from node (bus stop) to node along the transit network. If the system cannot find a path to the destination bus stop on the same route as the origin, it then looks for transfer nodes, which are defined as time points in the schedule serving multiple routes. Once a transfer node is found, the algorithm begins to perform a similar search along the new route toward the destination. In this algorithm, all possible routes are considered and the one with the shortest travel time is selected. Finally, the users have the option to determine the optimal path from the existing schedule or from historical bus arrival time data, which is presented in both text instructions and vector route overlapped on the base map. As indicated, commercial GIS software - ArcGIS and ArcIMS were adopted to provide map-based GUI. This means the transit agency has to prepare the spatio-temporal data in the form of both schedule files and the GIS map layers, such as the city streets, bus routes and bus stops, and maintain these files accordingly. The trip planner is strictly dependent on ArcIMS for the three stages of site development: map composition, Web service creation and publishing, which is not flexible and interoperable for the regular maintenance and system upgrade. Lastly, the proposed GIS functionalities were not available online at the time of writing this paper. By going through the website (http://infoweb.suntran.com/hiwire?.a=iTripPlanning), it was found that the existing system only generated text-based instructions without map renderings.



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

6

Another example for the map-based interactive online trip planning system is the South-East Wisconsin Transit Trip Planner (http://128.127.160.20/transit2/) (5). This system provides interactive map-based search, inquiry and analysis of trip itinerary planning, with expandable interfaces for real time transit information. The system takes either street addresses, or street intersections, or landmarks as the user input origin and destination. The trip searching options include planned departure time, preferred arrival time and minimal number of transfers. A general description of the path-finding algorithm can be found in (4). The initial output result from this trip planner is a list of text-based instructions for the trip itineraries. By choosing to “view map and trip details,” the street map and bus route with transfer points are presented. The system, similar to the Sun Tran trip planner, provides the spatio-temporal data in the form of bus schedule and separate map layers for the city streets, bus routes and bus stops. One of the innovations is that the system adopted a spatio-temporal relational database to store the bus schedule, as well as the topological relations between the various spatio-temporal components (6). The Structured Query Language (SQL) was used to conduct the optimal path finding on the database, which greatly improved the search performance. The system adopted a three-tier architecture as Web server (IIS 6.0), map server and database server. ESRI products, such as Map Objects, MO-IMS and Net Engine, were used to provide GIS functionalities. Disadvantages, with relation to the map service and the system performance, were found as follows:  Map files for city streets, bus stops and bus routes are provided as the base layers, and each update of these maps should be modified and uploaded manually.  The system depends largely on ESRI products. Every update of the adopted products may result in inevitable modification and configuration of the system.  Search options are not sufficient. For example, no minimal walk time is provided. Although the minimal transfer search algorithm was designed, it has not been fully integrated into the existing system. Other trip planners, such as ATIS product by Trapeze Software Products, Inc., Transport Direct in England (http://www.transportdirect.info) and ENOSIS in Greece (11), offer additional advanced trip planning services with user-friendly interfaces. The results are versatile, including route segment, cost, travel news and up to date information on train times, with different perspective of map views. However, the typical problems are: 1) the inputs are neither simplified nor unified, and users have to handle complicated settings to initiate a search, 2) no real graphical routes was generated, e.g. Transport Direct only connecting the start point, to the transfer point and then the end point directly, and 3) the map quality is not good, especially comparing to Google Maps. As it can be seen, most existing Web-based transit trip planning systems adopted monolithic architecture, wherein all components were implemented and integrated together. One significant limitation is that the functionally distinguishable aspects (e.g., user interface, data processing, error handling and output) are not architecturally separate




7

1 2 3 4

components but are all interwoven. This brings burdensome tasks for system maintenance and routine transit information update, and thus limits the expansion of the system.

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

In distributed computing, the definition of service is closely related to the functionality of component or module (15), and SOA is essentially a design philosophy independent of specific technologies, which is becoming a standard framework for better integrating existing distributed resources (16). The aim of SOA is to reuse the components (services) within the existing systems and provide interoperability among modules built with different programming tools, or even across platforms (17). Web services are believed as one of the most appropriate technologies for implementing SOAs on Internet (18), upon which services are loosely coupled.

44

Given the disadvantages of the existing proprietary and monolithic trip planning systems,

2.2 Service-Oriented Architecture and Its Applications in Transportation

Slavick (15) presented guidelines to build a joint Web-based common operational picture (JWC) by distributing GIS processing to multiple locations using SOA. ESRI products (ArcIMS and ArcGIS Server) together with standard geospatial Web services, such as Web Map Service (WMS) and Web Feature Service (WFS), were used to build up SOA. The distributed services provided include data retrieval and filtering, map rendering and geographic analysis on separate servers. The JWC built an open, extensible and loosely-coupled architecture to be shared across platforms. Amirian and Alesheikh (19) used a service-oriented framework to organize and disseminate geospatial data to mobile, desktop and web clients. WMS and WFS were adopted as the distributed technologies to handle cross platform scenarios. Testing results showed that the proposed framework provided an efficient solution for sharing and accessing geospatial data. By adopting SOA, each implemented geospatial Web service is related to a self-encapsulated functionality, which can be imported to any existing geospatial or non-geospatial software systems without affecting other components. As shown in the applications mentioned, a major advantage of SOA is to provide an architecture, in which one service can communicate with another without concerns or even knowledge of the underlying interfaces and connections. This merit suits perfectly to provide a distributed computing infrastructure for the existing transit planners. First, by providing the trip planning functionality in the form of Web services, users can access complex services by a simple Web client, such as Internet Explorer, or Firefox. Second, each component in the transit planning system is loosely coupled, which increases the interoperability of the system. Consequently, the existing components can be easily reused or upgraded, and the new features, including the third party service plug-ins, can be conveniently integrated. Lastly, since the mechanisms within SOA are clear and understandable, researchers can easily comprehend others’ work and utilize each other’s results, which in return facilitate further transit trip planning research. 3. SYSTEM ARCHITECTURE AND COMPONENTS



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

8

and the favorable merits of SOA, we propose a service-oriented computing framework for Web-based transit trip planning systems. The new architecture provides an efficient and cost-effective means in implementing a transit trip planning system with an interactive and easy-to-use GUI through the Web. Two potential architectures were proposed as shown in FIGURE 1. FIGURE 1a presents a framework based mainly on ESRI’s product components, in which ArcGIS 9.3 and ArcObjects APIs (Application Programming Interfaces) are used in the application server layer, and ArcGIS Geodatabase is used as the data storage. The majority of the development effort by adopting this architecture is the pooled or non-pooled server object functions performed within the server object container (SOC). By using the ArcObjects controls and plug-ins, geospatial analysis can be conducted directly on the shape files including bus stops, transit routes and landmarks. These geospatial layers are stored in the Geodatabase, and can be accessed through ArcSDE. The disadvantage is that the framework depends largely on the ESRI products, and requires additional software installations on the server system. Moreover, as the ArcGIS Server framework is neither open nor flexible in the client requests handling, any simple request must be forwarded to the server object manager (SOM) by IIS, and then be dispatched to individual services within the corresponding SOC. SOM and SOCs are two different components in ArcGIS Server, and may not be installed in the same computers, which can result in unnecessary routings. Furthermore, ArcGIS Desktop or application development framework (ADF) has to be installed for the ArcGIS Server administration purpose, which consequently brings additional development and maintenance effort. FIGURE 1b presents an alternative system architecture and implementation framework that incorporates third party online services (Google Maps) add-on, along with open source geospatial packages. Comparing to ESRI products, Google Maps are known for better price-performance ratio, which provide many geospatial functionalities, such as address geocoding and base map rendering, free of charge. JavaScript APIs are also provided by Google Maps to facilitate the development of web applications. In this architecture, three tiers were designed as: web client, application server and geospatial data storage. A dual role service aggregator is proposed by combining the roles of service requester and provider. First, it acts as an application service provider to offer a complete solution to service clients by creating composite, higher-level services, such as origin/destination (O/D) bus stop positioning and optimal route mashed up. The mash up procedure added the additional route information upon to the base map. Second, it acts as a service broker to request and reserve services from other service providers. In addition to the service aggregator, the development effort for this architecture is mainly on the WFS-related service providers, which correspond to the pooled or non-pooled server object functions in the ESRI’s SOCs. Comparing to the ESRI-based framework, this architecture has an additional development effort on the service aggregator, serving as a web transaction management middleware for request management and dispatching. A local registry is used to locate and invoke different services. The whole process is transparent to users since the aggregator acts as an omnipotent service provider to all web clients. All geospatial information is stored in the geospatial database, and can be retrieved directly through the API provided by ADO.net.




9

Internet IE, Netscape, etc. Web Browsers (GUI)

IIS

VS .net 2008 + ArcObjects

Web Server

Map Server

DB

Web Browsers (GUI)

SOM

. . .

SOCs

ArcGIS Geodatabase

ArcGIS Server 9.3 SOM: Server object manager SOC: Server object container

Web Browsers (GUI)

1

ArcSDE

Client

Application Server

Database Server

(a)

2

Internet

IE, Netscape, etc.

Google Maps Server

Web Browsers (GUI)

VS .net 2008 IIS ADO.net

Web Browsers (GUI)

. . . Web Browsers (GUI)

3 4 5 6 7 8 9 10 11 12 13 14 15 16

Client

Web Server Aggregator

Provider Requester

Map Server WFS Provider

DB

Geospatial DBMS

WFS: 1. Bus stops positioning, 2. Optimal path finding, 3. Route generating, and 4. Others.

Application Server

Database Server

(b) FIGURE 1 Two potential architectures of transit trip planning systems: (a) architecture for an ESRI-based trip planning system, and (b) architecture for a Google Maps add-on trip planning system. Based on the merits, the Google Maps add-on architecture (as shown in FIGURE 1b) was chosen for this development. Comparing to the ESRI-based counterpart, it’s more cost efficient, with a rather clear interactive mechanism between individual internal components. Since the service aggregator was self-developed, the request and response flows (including management and dispatching) are rather open, which provides a clear platform for further research and development. In this framework, the geospatial operations were either encapsulated in the client side by using Google Maps APIs or conducted within the geospatial DBMS. Therefore, the application server can focus on the optimal path finding



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8

and request/response flow organizing. By not relying on the ESRI components, the maintenance task was simplified, and the costs, both in monetary and system computational, were consequently reduced. Table 1 compares the two architectures on measurements of various aspects, which shows that the Google Maps add-on architecture is superior, in terms of development cost, maintenance effort and cost, user interface, and system performance. TABLE 1

Comparison of ESRI-Based and Google Maps Add-on Architectures

Measurements Development Effort Development Cost Maintenance Effort Maintenance Cost User Interface System Performance 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

10

ESRI based

Google Maps add-on

Development of service functions ESRI products, and VS .net 2008; costly Platform upgrade, database update and shape files update ESRI products, IIS, and database

Development of service aggregator, and service functions VS .net 2008, comparably cheaper Platform upgrade, and database update IIS, and database (could be freeware)

Easy to use but plain

Easy to use and vivid

Many spatial operations, slow

Many database operations, fast

By adopting the Google Maps add-on architecture, an implementation framework for the transit trip planner was provided in FIGURE 2. To be compatible with the Google Maps JavaScript APIs, the jQuery JavaScript library was selected for the Web client GUI design (client-side). The MS IIS 7.0 was introduced as the Web server platform. In the server-side, VB.net was selected as the programming language, while several small plug-ins were developed with C#. A registry table was designed for the service aggregator to dispatch the request to corresponding services. PostgreSQL, an advanced open source geospatial database, was chosen for storing the geospatial data because it’s fast, stable, open source and has well accessible online resources (20). The services can connect and retrieve data from the PostgreSQL database through the ADO.net APIs provided by the .NET framework. Two categories of services, the major functional services and the auxiliary services, were implemented. The major functional services include positioning origin and destination bus stops, searching schedule-based optimal path (with the shortest trip and wait time), with given O/D pairs, and generating geospatial route information and mashing up on Google Maps. The auxiliary services, such as user authentication and load balance, have also been implemented for system management purpose. A detailed design and implementation of the major functional service components were provided in Section 4.




11

auxiliary services User authentication, Load balance, etc. jQuery lib Service Requester

IIS 7.0 .Post .getJSON

Web Server

registery

Provider Requester

Aggregator

major functional services Bus stops positioning

Optimal path finding

Route generating

PostgreSQL Database ADO.net

VS .net 2008 (VB.net + C#)

1 2

FIGURE 2

3 4

4. SYSTEM COMPOENNTS AND IMPLEMENTATION

SOA for the trip planner implementation.

5 6 7 8 9 10 11 12 13 14

The proposed architecture has been implemented in the Waukesha Metro Transit Trip Planner (http://transit-dev.dcp.ufl.edu/index.html), an upgraded version of the existing South-East Wisconsin Transit Trip Planner (http://128.227.160.20/transit2/). The trip planning procedure starts from user input (O/D, trip time and preference). Next, the start and end bus stops are chosen based on the geographic locations of the O/D, followed by optimal path finding. Finally, the geospatial information for the route are obtained and mashed up on the base map. This section presents the GUI implementation details, along with other major functional services.

15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

To use an online trip planner, users have to prepare the origins, destinations, time of trip and search option to guideline the path search (5). Users of the new map-based trip planner may click on the map to determine the O/D. The map rendering functions from Google Maps, such as zoom and pane, can be used to assist the pointing-and-clicking selection. Other O/D input modes include manually typing in detailed street addresses or landmark names. More details on the interactive GUI can be found from the trip planner website online.

4.1 Google Maps Based Graphic User Interface (GUI) Design

As pointed out in (8), users may either not know the exact address of the O/D or not always enter the address correctly. Instead of providing the pull-down list control, the AJAX technology is used to enable the “automatic search result listings” in this system. The city landmark information is stored in a database table. Starting from the first input letter, all matched landmarks are retrieved and appeared in a pull-down list, which can be selected by a single click of mouse or keyboard. Furthermore, Google Maps provides javascript APIs for spatial inquiry and search to assist address positioning. When users input a particular




12

1 2 3 4

street address, the trip planner automatically centers base map (from Google Maps) at the location, with a pop up information box.

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Geocoding and address matching are the key functionalities to validate the user input for path-finding. This capability in the new trip planning system is handled by Google Maps geocoding APIs. Given that the geocoding functionalities from Google Maps are not inclusive enough to recognize all input addresses, the geospatial coordinates of landmarks and bus stops, along with their associated relationships, are stored in the database as a supplement in locating the appropriate bus stops. More detailed steps in the O/D bus stop positioning are provided as follows.

4.2 Trip Origin/Destination Bus Stop Positioning

First, the trip origins and destinations are not necessarily located exactly on the transit network. All nearby bus stops within walking distance are considered as candidates, since the stops within the walking distance passed by the optimal path may not necessarily be the closest one. In this system, the spatial constraint is the distance that users are willing to walk from the O/D to the transit stops, which was initially set as 0.4 km (or 0.25 mile). As some addresses may not have stops within this buffer distance, an increment of 0.2 km is appended until the maximal walking distance (0.8 km or 0.5 mile) is reached. The walking distance is measured along the street network by Google Maps APIs. FIGURE 3 presents a decision tree for processing and validating user input O/D information. Screen locating

User typing input

Addresses

Landmarks

Geocoding Geocoding

N From database

Coordinates (X, Y)

Distance < 0.4km

23 24 25 26 27

Has stops ?

Database

Y From database

Stops in the vicinity

Output collection of stops for origin or destination

FIGURE 3

Decision tree for the origin/destination bus stop positioning.

The process starts with the location of trip origin or destination, and the output is the collection of stops in the vicinity of each given location. If the location is selected by



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

13

mouse pointing-and-clicking or user typing street address, the Google Maps geocoding functions are used to obtain the geographic coordinates, so that the bus stops within the walking distance can be obtained. Otherwise, if the input is a particular landmark, the landmark-stop relationship table in the database is used to decide whether the landmark has associated stops or not. If no bus stop is associated, the geographic coordinates of the landmark are used to locate the bus stops in the vicinity. The bus stop searching process as proposed previously is then conducted to obtain the stops within the given spatial constraint (0.4 km to 0.8 km). Only after deciding the start and end transit stops, the shortest path analysis is able to be carried out on the transit network. 4.3 Schedule-Based Path-Finding Algorithm The shortest path-finding algorithm is the key functional component to provide trip itinerary planning. A significant amount of studies have been conducted to formulate models for the transportation network analysis (2, 21). However, the majority was focused on highway routing and assignment (22), and is inadequate to be applied to the transit networks. The schedule-based path-finding algorithm used in this development (including forward, backward and minimum transfers search) was originally proposed for the South-East Wisconsin Transit Trip Planner. The algorithm is based on a dynamic transit network consisting of active nodes and patterns. Only the active components, i.e., with transit services available, were used to construct the network topology. FIGURE 4 provides the explanation on the definitions of patterns and nodes used in the algorithm. A node is a single or group of stop(s) that transfers may take place. A pattern is a spatial layout of a route, but not bus route itself, since a bus route may include several patterns to serve various stops at different time, such as the weekday schedule or weekend schedule. As shown, Route 2 has two patterns, inbound and outbound, while Route 1 has four patterns because it has different drive routes for weekday and weekend. By using transfer nodes instead of bus stops, with only the active components modeled, the complexity of network topology was greatly reduced, which consequently enhances the search efficiency of the algorithm. The core algorithms and implementations can be found from (4). In this research, based on the time-dependant node/pattern network, three path-finding algorithms, namely shortest trip time forward search with scheduled departure time, shortest trip time backward search with scheduled arrival time, and minimum transfers search with scheduled departure time were developed. The new system kept the main search algorithms in the previous system, while improves the start and end nodes setup. As the collection of start and end stops may not be transfer nodes, in the previous algorithms each bus stop was treated as a separate node. The one (origin) to one (destination) shortest path problem was then derived to an m-start-nodes to n-end-nodes shortest path problem, with the computational complexity of the algorithm increasing m*n times (from O(1) to O(m*n)). In this implementation, only one start/end node is created by including the collection of start/end stops, so that the shortest path can be found by running the algorithm only once. The search performance is consequently improved.




14

for weekend

for weekday 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

FIGURE 4 Definitions of nodes and patterns used in the path-finding algorithm (source: (6); modified by the authors). 4.4 Path Generation, Map Mashups and Visualizations The principle of SOA is to reuse the existing modular resources, while providing friendly interfaces for future functionality expansion (23). In this development, functionalities of geospatial analysis and mapping operation are provided either by freeware (from Google Maps) or open source packages (PostgreSQL). The geospatial information, including bus stop/landmark locations (to position start and end bus stops in the vicinity of the O/D) and bus route layouts, are stored as points and polylines in the PostgreSQL database, without using any raw map files. The geospatial analysis functions embedded in the PostgreSQL DBMS are used to obtain necessary geospatial information from the corresponding database tables. In addition to the spatial data, the temporal data, in form of transit trips and schedules, are used. The trip data include the service time (start time and stop time) for each pattern, while the schedules provide more detailed departure time at each bus stop for each run. The operating schedules, including weekday, Saturday, Sunday and holiday schedules, are provided through different patterns. The temporal data have to be updated regularly according to the changes of bus schedules, while under special situations, the spatial data, such as transit stop position and transit route, may be altered. In this system, the spatial data were used largely in O/D bus stop positioning and route mashed up on Google Maps, while the temporal data were used to assist shortest path finding. The descriptive data, including the names and directions of bus routes, were used to generate the text instructions from the search results and the related landmarks/stops. The partition and relationship among geospatial data, temporal data and descriptive data are presented in FIGURE 5. The “Links” table stores the link sequence relationship for each pattern. The “Stops” table stores the stop sequence along the route. At the beginning of the path-finding process, the start/end stops are determined as part of the input. After completing the search algorithm, the results are stored in a node-based manner, which along with the total travel distance, is used to generate the text guidelines for the users.




15

Descriptive data Route Info (bus route related information)

Temporal data Trips (with operational start time and end time)

Schedules (with departure time at each stop)

Directional Bus Route (Pattern)

Bus Link Sequence Typology

Links (spatial polylines)

Bus Stop Sequence Typology

Stops (spatial points)

Spatial data

Lankmarks (spatial points)

1 2 3 4 5 6 7 8 9 10 11 12 13 14

FIGURE 5

15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

This paper presents an open and interoperable architecture for an online trip planning system by using the service-oriented computing architecture to link with legacy path-finding components, Google Maps APIs and open source PostgreSQL database. The advantages of the new system are: 1) to take advantage of the existing path-finding service components; 2) to use Google Maps’ geocoding and mash up APIs for user input and output display; and 3) to introduce PostgreSQL geospatial database to store and handle the geospatial data. The architecture separates the geospatial operations and the geographic information mashed up from the optimal path-finding procedure, and thus increases the reusability of each service component. Such architecture improves the development efficiency, and brings convenience for future system expansion. With a pre-defined interface, each service component can be debugged, modified, and even removed without affecting others.

Table structure and relationship in PostgreSQL database.

To visualize the searched bus route on the base map, additional geospatial information is required. As the shortest path consists of one or more patterns with transfer node(s) in between, the spatial layout of each pattern, which is a sequence of directional road links, should be obtained from the database. The geospatial information for each link is retrieved as a set of geographic points. As the start and end bus stops may not be the end-point of a link, the portions of the start and end links that the route does not cover were excluded from the results. Additionally, the walking path from the O/D points to the bus stops are drawn along the street by Google Maps APIs, with the text instructions and walking distance accompanied. 5 CONCLUSIONS AND RECOMMENDATIONS

The new system was tested, and the results were validated with those from the existing system (South-East Wisconsin Transit Trip Planner) that has been in operation for more than seven years. Most of the search outputs were consistent except for several special scenarios, in which different start or end stops were identified. The reason is that the “old” system sets the general walk distance as 0.25 mile and the maximal distance as 0.5 mile




16

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

instead of the 0.4 km (general distance), 0.6 km (acceptable distance) and 0.8 km (maximal distance) set in the new system. However, the new settings tend to generate results with more reasonable walking distance. The new system was implemented in a running environment as: OS - MS Windows 2003 Server R2, Hardware - Intel® Xeon® Processor L5335, 2G RAM. The general “inquiry” time is 3-6 seconds, which is better than the average running time of the “old” system (6-9 seconds).

19 20 21 22 23 24 25 26

This research was partially supported by: 1) US National Science Foundation award BCS-0616957, 2) the Young Excellent Faculty Plan in Tongji University, China 2009KJ056, and 3) the award from the Bureau of Science and Technology in Shanghai for new transportation technologies in Shanghai Expo 2010 (10dz0581405). Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the sponsors.

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

1. Abdel-Aty, M.A., 2001. Using Ordered Probit Modeling to Study the Effect of ATIS on Transit Ridership. Transportation Research Part C 9(2), 265-277. 2. Wong, S.C., and Tong, C.O., 1998. Estimation of Time-Dependent Origin-Destination Matrices for Transit Networks. Transportation Research Part B 32(1), 35-48. 3. Smith, B.L., 2000. Using Geographic Information Systems and the World Wide Web for Interactive Transit-Trip Itinerary-Planning. Journal of Public Transportation 3(2), 37-50. 4. Huang, R., and Peng, Z.R., 2002. Schedule-Based Path-Finding Algorithms for Transit Trip-Planning Systems. In Transportation Research Record: Journal of the Transportation Research Board 1783, 142-148. 5. Huang, R., and Peng, Z.R., 2002. Object-Oriented Geographic Information System Data Model for Transit Trip Planning Systems. In Transportation Research Record: Journal of the Transportation Research Board 1804, 205-211. 6. Huang, R., and Peng, Z.R., 2008. A Spatio-Temporal Data Model for Dynamic Transit Networks. International Journal of Geographic Information Science 22(5), 527-545. 7. Chapleau, R., Allard, B., and Trépanier, M., 1996. Transit Path Calculation Supported by a Special GIS-Transit Information System. In Transportation Research Record: Journal of the Transportation Research Board 1521, 98-111.

Furthermore, SOA allows for incorporating real time automatic vehicle locator (AVL) data or global positioning system (GPS) data to display bus locations and predict arrivals. Within this framework, the link and route travel times can be calculated dynamically, so that travelers can choose appropriate route according to the real time demand. As the bus schedules change regularly, and even the bus route layouts or the bus stop positions may be altered, maintenance tasks are required. A systematic data maintenance tool is going to be developed to keep the integrity of geospatial topology and the data consistency of the database. The User-friendly Desktop Internet GIS (uDig) infrastructure is considered as an appropriate platform. ACKNOWLEDGMENTS

REFERENCES



Sun, Peng, Chen and Shan, 2011 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

17

8. Peng, Z.R., and Huang, R., 2000. Design and Development of Interactive Trip Planning for Web-Based Transit Information Systems. Transportation Research Part C 8(5), 409-425. 9. Trépanier, M., Chapleau, R., and Allard, B., 2002. Transit Itinerary Calculation on the Web, Based on a Transit User Information System. Journal of Public Transportation, 5(3), 13-32. 10. Rehrl, K., Bruntsch, S., and Mentz, H.-J., 2007. Assisting Multimodal Travelers: Design and Prototypical Implementation of a Personal Travel Companion. IEEE Transactions on Intelligent Transportation Systems, 8(1), 31-42. 11. Zografos, K., Spitadakis, V., and Androutsopoulos, K., 2008. Integrated Passenger Information System for Multimodal Trip Planning. In Transportation Research Record: Journal of the Transportation Research Board 2072, 20-29. 12. DTA, 2008. http://www.duluthtransit.com/news/news.aspx?pid=1002, accessed on Apr. 22, 2009. 13. Cherry, C., Hickman, M., and Garg, A., 2006. Design of a Map-Based Transit Itinerary Planner. Journal of Public Transportation 9(2), 45-68. 14. Hickman, M., 2002. Robust Passenger Itinerary-Planning Using Transit AVL Data. In: Proceedings of the IEEE 5th International Conference on Intelligent Transportation Systems. Sept. 3-6, Singapore. 15. Slavick, D., 2004. Utilizing C/JMTK to Build a Web-Based Common Operational Picture (Joint WebCOP), http://gis.esri.com/library/userconf/proc04/docs/pap1613.pdf, accessed on Apr. 17, 2010. 16.Papazoglou, M.P., and Heuvel, W.J., 2007. Service Oriented Architectures: Approaches, Technologies, and Research Issues. The VLDB Journal 16(3), 389-415. 17. Papazoglou, M.P., Traverso, P.D., Dustdar, S., and Leymann, F., 2007. Service-Oriented Computing: State of the Art and Research Challengers. IEEE Computer 40(11), 38-45. 18. Ramaratnam, R., 2007. An Analysis of Service Oriented Architectures. MS. Thesis, Massachusetts Institute of Technology, Cambridge, MA, USA. 19. Amirian, P., and Alesheikh, A., 2008. A Service Oriented Framework for Disseminating Geospatial Data to Mobile, Desktop and Web Clients. World Applied Sciences Journal 3(1), 140-153. 20. Racicot, A., 2007. Open Source Geospatial Tools: Enabling Coastal Decision Makers. In Proceedings of Coastal Zone 07. Jul. 22-26, Portland, OR, USA. 21. Zhan, F.B., and Noon, C.E., 1998. Shortest Path Algorithms: An Evaluation Using Real Road Networks. Transportation Science 32(1), 65-73. 22. Bar-Gera, H., 2002. Origin-Based Algorithm for the Traffic Assignment Problem. Transportation Science 36(4), 398-417. 23. Agrawal, R., Bayardo, R.J., Gruhl, D., and Papadimitriou, S., 2002. Vinci: A Service-Oriented Architecture for Rapid Development of Web Applications. Computer Networks 39(5), 523-539.



Development of Web-Based Transit Trip Planning System Based on ...

Development of Web-Based Transit Trip Planning System Based on ...

Suggest Documents