Proceedings of the 2007 IEEE Intelligent Transportation Systems Conference Seattle, WA, USA, Sept. 30 - Oct. 3, 2007
WeC2.4
A Google-Map-Based Arterial Traffic Information System Yao-Jan Wu, Yinhai Wang, and Dalin Qian
Abstract— Web-based mapping technologies have been utilized for traffic information systems. However, most such systems are for freeways and very few of them focus on arterials or urban streets. This paper presents a real-time Google-map-based Arterial Traffic Information (GATI) system for urban streets in the City of Bellevue, Washington State. Open source web tools and emerging web technologies, such as Ajax, are used in implementing the system to ensure its performance and minimize its cost. Convenient administrative functions are enabled through advanced database design and the Model-View-Controller (MVC) application. This GATI system, though presented and demonstrated by using Bellevue’s data, is a general technology that can be applied to any arterial network.
W
I. INTRODUCTION
ITH the new technology developments in Intelligent Transportation Systems (ITS), more effective solutions to transportation problems become available. For instance, increased deployments of traffic sensing technologies can easily provide a large amount of live traffic data necessary for real-time incident detection, traffic operations, and performance measurement. Since raw data from traffic sensors require further process to produce useful results for traffic management and traveler information systems, it has become a challenging issue to manage and utilize traffic sensor data effectively. For example, traffic sensor data must be processed before being transferred to Advanced Traveler Information Systems (ATIS). Well designed ATIS should present traveler information in an efficient way so that ATIS can help improve personal mobility, safety, and the productivity of transportation systems. An efficient and effective approach for traveler information organization and presentation is crucial for the success of ATIS. In the past a few years, more and more private and public transportation organizations have published their online traveler information systems to provide road users prompt access to real-time traffic network information for better travel decisions. The Washington State Department of Transportation (WSDOT) has published a real-time traffic
Manuscript received April 2, 2007. This work was supported in part by Transportation Northwest (TransNow), the US Department of Transportation University Center for Federal Region 10, at the University of Washington. Yao-Jan Wu is with the Department of Civil and Environmental Engineering, University of Washington, Seattle, WA 98195-2700, USA. (Corresponding author: +1(206)685-6817; fax: +1(206) 543-5965; e-mail:
[email protected]). Yinhai Wang, Ph.D., is with the Department of Civil and Environmental Engineering, University of Washington, Seattle, WA 98195-2700, USA (e-mail:
[email protected])
flow map for Seattle area freeways since early 1990s. Similar applications were implemented in other DOTs over the past decands, such as TransStar (Texas DOT), Caltrans Real-time Freeway (California DOT) and CoTrip (Colorado DOT) [1]. As for the arterial or urban street ATIS, little work has been done. The City of Bellevue’s traffic flow map is one of the few arterial traveler information systems developed to date [2]. The design of this system contained several creative ideas such as the one using inductive loop data for arterial performance measurement. Despite its achievements in on-line traffic information display, the system suffers from two main drawbacks. The first drawback is that it is difficult to locate positions on Bellevue’s traffic flow map. This is caused by the online map that is not drawn in scale. No point on such a map can serve as a reference point and this creates difficulties in estimating link length and travel time. The second drawback, which is common to most ATIS, refers to the lack of interactivity between users and the system. Even though these web-based mapping systems were designed to interact with users, changing scale and/or panning to a new spot may not be supported or requires a significant amount of time because of the less-responsive web designs. Therefore, some traffic flow map applications started using web-based mapping engines to increase the interactivity. For example, the Dallas transportation management center (DalTrans) recently developed a Google-based mapping system with improved web navigation capability to replace their previous dynamic freeway traffic information website [1]. Within a highly competitive marketplace, online mapping technologies have received popularity. Google Maps plays an indispensable role in the web-based mapping world. Hundreds of Google-map-based web applications can be easily accessed via any web browsers with an Internet connection [3][4]. In the field of transportation, Google-map is also increasingly utilized. On Feb. 28, 2007, Google introduced an embedded real-time traffic program that allows users to glance at the congestion conditions on major state routes and freeways in over 30 major US metropolitan areas, including Seattle [5]. At the current stage, most mapping systems focus on freeway applications and few address issues on urban streets. Moreover, these applications typically do not have archive systems that could be used to support future transportation research. This paper presents a Google-map-based Arterial Traffic Information (GATI) system which operates in the Apache server equipped with MySQL database powered by PHP Dalin Qian, Ph.D., is with the School of Traffic and Transportation, Beijing Jiaotong University, China (e-mail:
[email protected])
1-4244-1396-6/07/$25.00 ©2007 IEEE.
968
Hypertext Preprocessor (PHP). It incorporates real-time traffic data provided by the City of Bellevue, Washington, and also supports queries to find information from historical data. Users can query data of interest and efficiently display traffic flow condition on major urban streets and arterials within the scope of the city. The first section of this paper reviews related practice of mapping technologies commonly used in transportation. Next, the architecture of the entire system is introduced. This is followed by details of database design. The fourth section describes implementation efforts. The final section concludes findings of this study and recommends future work enabled by the implementation of this GATI system. The prototype GATI system can be accessed from the Smart Transportation Application & Research (STAR) Lab website located at http://www.uwstarlab.org.
asynchronous JavaScript and Extensible Markup Language (XML). Ajax, coined in 2005, is a growing web development technique for creating interactive web applications [6] and has been widely used in web-based systems. The power of Ajax is demonstrated in our system. Google Maps Application Programming Interface (API) is the core display engine of the system. It makes the map rendering and feature drawing feasible [7]. User Interface
System Server
CSS
Web Brower
HTTP
HTTP
Ajax Javascript
Web Brower
PHP
XHTML
FTP Apache Web Server
MySQL Database Server
HTTP XML
II. SYSTEM ARCHITECTURE The GATI system was developed to incorporate different types of data retrieved from the City of Bellevue. In addition to the capability of demonstrating traffic flow condition data, this system provides a function to interact with users. The GATI system primarily consists of three parts: a data server in the City of Bellevue, a system server and a User Interface (UI). The fundamental architecture for the GATI system is shown in Fig. 1. Each part is explained in detail as follows: A. Data Server The traffic flow condition data is stored in the data server and can be accessed periodically through the File Transfer Protocol (FTP) by a C# program developed specifically for this study. Traffic flow condition data is downloaded every minute and made available for system usage by this C# program. Details on data type, content, and format are explained in Section III. B. System Server The GATI system server contains a database server and a Hypertext Transfer Protocol (HTTP) server. In our implementation, the Apache HTTP server (version 2.2.4) was chosen as our web server because Apache has become one of the most popular HTTP servers and is highly configurable and extensible with third party modules. MySQL database server (version 5.1) is chosen as our database server. On the other hand, PHP (version 5.2.0) played an indispensable role for setting up a communication bridge connecting these two servers. They are all open-source (free) applications and under active development. Note that both servers currently reside in the same desktop computer for convenient maintenance. If necessary, they can also be installed and maintained separately. C. User Interface The client side mainly utilizes several web languages, such as Cascading Style Sheet (CSS), Extensible Hyper-Text Markup Language (XHTML) and Ajax, shorthand for
969
Google Maps API Web Brower Data Server ( City of Bellevue )
Fig. 1. GATI system architecture
III. DATABASE DESIGN The database system in the GATI program manipulates live and archived data from the City of Bellevue. In addition to the traffic data and its coding format, other information, such as the location of each intersection and link-intersection information were also collected from related documents provided by the City of Bellevue. All these data are stored in a database specifically designed to support clients’ queries at the front end of the GATI system. Since the database plays an important role for efficient operations of the GATI system, details on the design and implementation of the database are provided in this section. A. Traffic Data from the City of Bellevue According to [2], the City of Bellevue operates 177 signalized intersections and has 160 signals connected to a Traffic Management Center (TMC) where a centralized signal system is operated. In the City of Bellevue, traffic conditions and congestion levels are determined by the occupancy data collected from the advance loop detectors which are normally located at 130 feet back from the stop bar at each approach. In the TMC server, the congestion levels are further translated into color codes. On the Bellevue flow map, color codes are used to display six different congestion levels ranging from a low of 0 to a high of 5.. Thereafter, all data received and processed by the TMC server is compiled into a Comma-Separated-Value (CSV) file every minute. This data file can be downloaded by granted customers from the FTP server mentioned earlier. The same data set has been being used to display arterial traffic flow condition on Bellevue’s real-time arterial traffic flow map
(http://trafficmap.cityofbellevue.net/) since April 17, 2006. It has received broad attention because, at that time, few cities in the U.S. provided real-time traffic information for local arterials. More details can be found in [2]. The CSV file contains the real-time information for each roadway section, which is referred to as “link”. Fig. 2 shows the first six out of 469 link data in the one-minute CSV file displayed in MS Excel. From the left to the right are the link numbers, link IDs, smooth volumes, cycle lengths, cycle plan numbers, color codes, and incident codes. In the GATI system, columns A, B and G are adopted. Additional information is also stored in the database for future use. Link ID Link No.
Smooth Occupancy Smooth Volume
Cycle length
Plan # running
Incident code
Color code
Fig. 2. Data format
folders in an organized manner. A webpage written in PHP script can be accessed the database and inserted into every row into the traffic data table after parsing the CSV files. All tasks were completed in our system server. In the GATI system, a whole month of data was imported into this table. More data can be imported using the same manner. 3) Constructing an Intersection Table: According to the signalized intersections map, a physical map provided by the City of Bellevue, the locations of each intersection can be manually input by using the Google-map based intersection locator developed in this system. This web program employed the GXmlHttp object to enable asynchronous interactive locating tasks. Fig. 3 shows an example of input data for Intersection 26, the intersection of 8th Street and 112th Street in the downtown Bellevue. The user clicks the center of the specific intersection on the Google Map and an information window will appear that requests further information. After clicking the “save” button, a green traffic light icon will appear. Subsequently, the input data as well as the longitude and latitude information will be saved to an XML file in the server.
A FTP program written in C# language is used to download the one-minute CSV data feed in real-time and the data feeds are stored in the hard drive of our HTTP server in dated folders. The next step is importing all the data into our database for query use and rendering the color codes on the Google Map. B. Data Tables Before representing the flow condition on the Google Map, a database has to be built up in advance. Keeping all data in flat text files will not be efficient for constructing flow maps since it will take a long time to parse the files and might also flood memory buffers. As a result, the traffic data table has to first be imported. This table lacks location information for each link and for drawing a link between the start node and end node. The second and third table will support this idea. The following are the procedures used to create and import these tables and how they related to one another. 1) Assumption: We assume every link is straight since over 90% of links are visually straight on the map. Therefore, the link-node concept is adopted in this research. Herein, the node means the intersection. This assumption can smooth the progress of displaying flow maps and creating further applications, such as routing implementation. Note that if curved roads must be rendered on the map, the Google Maps API also allows us to represent curved lines or paths using encoded polylines, which specify a series of points within a GPolyline using a compressed format of ASCII characters [7]. 2) Constructing a Traffic Data Table: In order to import all the data into MySQL database, the most common approach is to use the server-side scripting language, PHP. Data downloaded from the FTP server has been stored in dated
970
Fig. 3. Locating intersections for constructing an Intersection Table
As shown in Fig. 4, when the user clicks a specific traffic light icon, the related information about the intersection will be retrieved from the XML in the server. The whole process utilizes the so-called Ajax technologies.
Fig. 4. Retrieved intersection data from the XML file in the system server using GXmlHttp object
In the GATI system, 150 intersections need to be located. When all the intersections are located, the XML file can be transferred into a CSV file by using MS Excel. Thereafter, the same PHP script will be executed to import all data into the Intersection Table. 4) Constructing an Intersection-Link Relationship Table: The purpose of constructing this table is to assemble the link-node relationships between every two intersections located in the previous step. The flow map data table has to be utilized to locate this link. Essentially, our application followed the naming convention of the City of Bellevue. Take the first two rows in column B in Fig. 2 for example. Link 15 is the eastbound link that ends at Intersection 1 and Link 16 is westbound link that also ends at same intersection. According to the signalized intersection map, we can further locate their starting intersections (a.k.a. nodes). For link 16, obviously it is Intersection 2. However, for Link 15, there was no intersection in its western side. Therefore, a pseudo-node has to be created and thus 6, 7, 8 and 9 are added to the first digit of each intersection number to represent the starting node of southbound link, eastbound link, northbound link, westbound link respectively. For example, the pseudo-node for Link 15 is 7001 since it is an eastbound link ending at Intersection 1. If Link 15 is south-east bound, the starting pseudo-intersection will be 67001. 5) Entity-Relationship (E/R) Diagram: Although it seems convenient to have to three tables in the database, when querying, it is not efficient because of redundancy and the additional time needed in searching. Building an ER-diagram can be helpful in deciding how many tables we should keep in order to limit redundancy. As shown in Fig. 5, after merging the Traffic Data Table, the Intersection Table and the Intersection-Link Relationship Table, the results showed that a link is composed of a from-node and an end-node. The rounded arrow entering the intersection entity from the link entity can be seen in the diagram. This arrow expresses the referential integrity constraint that every link has a front-node and end-node that exist in the Intersection entity set. 5) Joining Tables: In order to display the data on the Google Map, one can join tables by creating views and inserting all data into a new table. For demonstration, the new table contains the following columns: Link number, link ID, end node, end-node latitude, end-node longitude, from-node, from-node latitude, from-node longitude, color code and time stamp. 6) Performance Enhancement: Database performance is a crucial issue. During the developmental stage, the performance is improved step by step. Without enhancing the performance, it would take over an hour to finish the query process for the whole city. Choosing the right table engine is the first solution. In terms of querying performance, MyISAM is chosen for our
971
application as it is more efficient than other storage engines such as InnoDB, the most popular transactional storage engine. Indexing is another significant issue in performance enhancement. Since the flow map is shown with varying time, column “time stamp” is the first index column. The index type is B-tree. Based on these parameters, querying 469-row link data for a specific minute requires around 0.05 seconds within which nearly nineteen million rows of data are searched.
Fig. 5. E/R-Diagram
IV. IMPLEMENTATION After building up the database, a user-friendly interface was created to acquire users’ input. Next, the mechanism of the database-driven process will be explained. A. Interface Design As shown in Fig. 6, a user-oriented interface has been constructed. The map controls located in the top-left corner allow users to choose the level of detail by zooming in and out. Users can drag the map to any places of interest to see the variation of flow maps in detail after the query process. In the top-right corner, users can choose different modes of maps, including the map mode, satellite mode and hybrid mode. Each mode has its advantages of visualizing data to users. The rectangular sidebar on the right is the control panel that can handle the input from the user. It is divided into two parts. The upper part is used to display the original Bellevue Google Map, the Intersection Locator introduced in the Section III and the real-time flow map. The lower part is the historical flow map query interface. After selecting the specific time of day on the panel, by clicking on the button “show” the query process will be activated. One can view the flow map directly on the Google Map when the query is finished. Users can then easily refer to the traffic congestion legend to distinguish the congestion levels of each link. Another feature is the Google Maps build-in geocoder engine used to locate the address of interest. Geocoder is used to translate physical addresses into latitude and longitude coordinates. Basically, the user can either input the exact address or the zip code to locate a specific spot promptly.
The lower-left corner is the message board that can show the XML-type query results or error messages.
2) View: It is the root file displaying the GATI system control components that users can interact with. 3) Controller: This file can handle the request sent by the remote client from the UI. Essentially, the UI is the “view” component of MVC pattern. The advantage of this design pattern is that it allows the developer to make updates very easily without changing every class while it also allows individual part very simple and self-contained. In future applications, more functions can be incorporated into the system in an orderly manner. FTP Data Server (City of Bellevue)
System Server (STAR Lab) FTP Downloader (written by C#)
Fig. 6. GATI system user interface
B. System flow Fig. 7 depicts the flow chart of the GATI system. As mentioned in Section III, the traffic flow data downloaded form the data server in the City of Bellevue can be manipulated gracefully by using the PHP script to create the back-end database. Starting from the front-end of the system, while the user is clicking the “show” button on the UI, the Ajax request will be sent through the XmlHTTPRequest object and the PHP interpreter will be activated to send a query request to MySQL database. After the query process is done, the response will be sent back to server in XML format that can be easily processed by using XML-handling methods. Google Maps API can visualize the requested data in the correct manner. The real-time flow map mechanism is also incorporated into the GATI system. XML files are generated in real-time while FTP Downloader downloads the CSV files from the data server in the City of Bellevue. Users’ browsers can update the real-time flow map based on the up-to-date XML file. Our query process is implemented based on a Model-View-Controller (MVC) design pattern [8]. The goal is to produce a set of independent, modular components that allow updates while affording easy maintenance. MVC programs that separate web applications are a variation on the three-tier architecture and are widely used to describe database-driven web applications. In the GATI system, classes in our MVC application fall into three components in the following. 1) Model: A web services file contains the models, methods, and XML view classes. It can be broken down into separate files if more functions are needed for further application. Usually it is written in PHP code that should be executed on the server side to send the object back to the client side by using the control component. This component is in charge of handling the link objects retrieved from the database.
972
MySQL Database
Real-time traffic XML FTP files data (CSV file) XML files
PHP Interpreter
User Interface (Browsers)
Google Maps Engine
Display
XML XML XML files files files
Javascript Interpreter/ Ajax
User Input
Fig. 7. GATI system flowchart
C. Traffic Data Rendering The color scheme for displaying the congestion level is not the same as what the City of Bellevue uses on their website. This is simply because some colors are not obvious on the Google Map no matter which display mode the user chooses. Accordingly, different colors are specified to render different congestion levels, as shown in the legend on the UI. Note that the two links between two intersections will overlap with each other since they share the same two intersections. As a result, two links are shifted to one side according to the direction of the link. For example, the eastbound link will be shifted by a slight displacement to the north and westbound link will also shifted by the same degree of displacement to the south. D. Using the System After clicking the “show” button, the query result appears like that shown in Fig. 8. Thanks to Ajax technologies, the query process doesn’t freeze the screen while the database is querying the link locations. In the meantime, the user can
zoom and pan the Google Map. Engineers can use the system to see the variation in traffic conditions on the specific link in the city. By using this GATI system, the bottlenecks in urban streets can be easily identified by changing the time of day. After querying several times, we can observe that Intersection 26 (112th AVE & NE 8th Street) has recurrent congestion. Some malfunctioning detectors can also be visually identified. For example, the loop detectors on 8th Street between 116th AVE and 112th AVE malfunctioned frequently during peak hours.
algorithms should include travel time prediction, intersection performance measurement methods and urban street or arterial performance measurements. We can envision a more comprehensive GATI system. ACKNOWLEDGMENT The authors gratefully acknowledge the City of Bellevue for providing the real-time traffic flow data. We thank Mike Whiteaker, Mark Poch and Fred Liang for valuable assistance. REFERENCES [1]
[2] [3] [4] [5] Fig. 8. Traffic flow map displayed in the GATI system [6]
V. CONCLUSION AND FUTURE WORK This study focuses on displaying and organizing traffic flow data using the up-to-date web technologies driven by the database. The GATI system is presented by using Bellevue’s data. It also demonstrates a general technology that can be applied to any arterial network. The GATI system shows detailed information for all urban streets and it allows traffic engineers to query the data of interest to observe day-to-day or minute-to-minute variations in traffic conditions. The GATI system also allows users to smoothly manipulate the map while the query is processing in the background. Overall, the system is fairly robust and effective for querying data and displaying information. Some issues were encountered when the system was being developed. First, if the user turns off the JavaScript interpreter in the browser, interactive functions on the Google Map will not be able to work. So far all we can do is to notify the user if he/she doesn’t turn on the JavaScript. The current state of this GATI system is not complete. Other features on the map also need to be improved or added. These features include drawing turning movements, plotting curved roads, showing construction site information, and displaying the direction of each traffic flow. As for the query part, more query options on the interface should be added to the system even though complicated queries can be conducted by editing the PHP script on the server side. In the long term, adding routing information based on the historical and real-time traffic data is necessary. These
973
[7] [8]
E. J. Seymour, B. Miller, “Google-Based Mapping System for Traffic Management Center Web Navigation,” presented at the 86th Transportation Research Board Annual Meeting, Washington, DC, January 21-25, 2007, Paper #07-3384. Liang, F. "Development of Bellevue Real Time Arterial Flow Map,” presented at the ITE District 6 Annual Meeting, Honolulu, Hawaii, 2006. M. Pegg. (2007, March, 13). Google Maps Mania. [Online]. Available: http://googlemapsmania.blogspot.com/ M. Purvis , J. Sambells, C. Turner, “Beginning Google Maps Applicationswith PHP and AJAX: From Novice to Professional,” Apress, 2006 E. Malykhina (2007, February, 28).Google Mashup Helps You Avoid Traffic Backups [Online]. Available: http://www.informationweek.com/news/showArticle.jhtml?articleID= 197700147 J. J. Garrett, (2005, February, 18). Ajax: A New Approach to Web Applications [Online]. Available: http://www.adaptivepath.com/publications/essays/archives/000385.ph p Google Maps API, (2007, March, 13), [Online]. Available: http://www.google.com/apis/maps/. J. Loter, (2007,January, 30), Lecture 6 [Online], Available: https://faculty.washington.edu/loter/info344/calendar.php
