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.
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
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
TRB 2011 Annual Meeting
Paper revised from original submittal.
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
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
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.
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
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
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
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
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.
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
TRB 2011 Annual Meeting
Paper revised from original submittal.
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.
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
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
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.
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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.
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
TRB 2011 Annual Meeting
Paper revised from original submittal.
Sun, Peng, Chen and Shan, 2011
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
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
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.
TRB 2011 Annual Meeting
Paper revised from original submittal.