A GOOGLE MAPS-BASED APPROACH TO REAL-TIME
           TRAFFIC AND TRAVEL INFORMATION (RTTI)
             DISSEMINATION OVER...
1. INTRODUCTION


Travel time is an important issue in our everyday schedule. Prior and accurate real-
time information on...
(closed, chains required). For every traffic event the following data is also provided:
province, city, road name, start-e...
The previously described data sources are homogenised by specific TIC server input
modules that have been coded to transla...
3. THE TRAFFIC INFORMATION CHANNEL ATIS WEB PORTAL


To a large extent, the perceived usefulness of a traffic and travel i...
3.2. Custom algorithms for efficient representation of data


To use markers (to represent dynamic traffic-related or stat...
Figure 2 – Cluster marker dynamic grouping of data




  Search engine bar            Enable / Disable all layers



     ...
The user can use the zoom window functionality provided by the Google Maps API
[1]. Dynamic data related to the current zo...
Upcoming SlideShare
Loading in …5
×

A Google Maps-based approach to Real-Time Traffic and Travel Information (RTTI) dissemination over the Internet

3,326 views

Published on

This paper presents the architecture of an Advanced Traveller Information System which disseminates RTTI through a highly interactive web interface. The presentation layer relies on Google Maps and the use of cutting-edge AJAX techniques, while the underlying core technology is the traffic aggregation server. The server applies several ad hoc algorithms to normalize each traffic data feed, both for dynamic (road congestion, road works, accidents) and static data (black spots, speed cameras, risk mapping per road stretch as provided by the EuroRAP programme). Static data is also encoded in order to be easily downloaded and displayed in most GPS units.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,326
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
94
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A Google Maps-based approach to Real-Time Traffic and Travel Information (RTTI) dissemination over the Internet

  1. 1. A GOOGLE MAPS-BASED APPROACH TO REAL-TIME TRAFFIC AND TRAVEL INFORMATION (RTTI) DISSEMINATION OVER THE INTERNET Josep Laborda 1*, Lluís Puerto 2, Pere Sauret 3 1 RACC (Royal Automobile Club of Catalonia) Telematics and ITS Manager, Av. Diagonal 687 08028 Barcelona (Spain), +34 93 495 50 00 (5294), josep.laborda@racc.es 2 RACC Road Safety Manager 3 RACC Head of Technical Department ABSTRACT This paper presents the architecture of an Advanced Traveller Information System which disseminates RTTI through a highly interactive web interface. The presentation layer relies on Google Maps and the use of cutting-edge AJAX1 techniques, while the underlying core technology is the traffic aggregation server. The server applies several ad hoc algorithms to normalize each traffic data feed, both for dynamic (road congestion, road works, accidents) and static data (black spots, speed cameras, risk mapping per road stretch as provided by the EuroRAP2 programme). Static data is also encoded in order to be easily downloaded and displayed in most GPS units. 1 Asynchronous JAvaScript and XML. 2 The European Road Assessment Programme - EuroRAP - is an international not-for profit association which aims to provide independent, consistent safety ratings of roads across borders. This assessment is yearly undertaken by RACC in 20.000 km of the major Spanish road network. KEYWORDS RTTI, ATIS, Google Maps, RDS-TMC, real-time traffic data, traffic data aggregation, live traffic camera, speed camera, black spot, dynamic data, static data, Point of Interest, GPS unit, AJAX. 1
  2. 2. 1. INTRODUCTION Travel time is an important issue in our everyday schedule. Prior and accurate real- time information on the traffic conditions and possible incidents in our planned itinerary can be very useful for the travellers to avoid getting stuck in gridlock, minimize their travel time and improve their comfort. In the most optimistic scenario such information should persuade drivers not to take roads that are beginning to get congested (but not yet saturated) and choose alternative routes, contributing to avoid future congestion. In any case, an awareness of the current traffic conditions and a qualitative description of the road provides the travellers with the perception of a safer, more secure trip and plays a key role in making journeys more efficient and comfortable, reducing the driver's stress. 2. DATA COLLECTION, AGGREGATION, TRANSFORMATION AND DISSEMINATION The quality and high availability of traffic data sources, especially when the systems are reporting current conditions, is essential in a traffic information system. Given the lack of standards and the complexity of collecting data in a harsh and inconsistent environment, it is a difficult technical and business challenge to collect and disseminate aggregated traffic information. The challenges associated with traffic data feeds are twofold. Each data feed is uniquely formatted and, once consolidated in the server database (aka Traffic Information Channel, TIC) conversion needs to be made in order for the heterogeneous live traffic information and static road-related data to be correctly mapped and viewed in the selected GIS (Google Maps). Thus, the TIC server applies specific algorithms to normalize data and enhance or discard the vast amount of erroneous, obsolete or useless data. In our case, the TIC server collects an HTTP plain text feed from the DGT1 (http://www.dgt.es/gsmplus.txt) and an XML feed from RACC proprietary emergency roadside assistance system2. This is what we call dynamic data (real-time data). Static data as provided by the DGT through their website (black spots, speed cameras) and by the EuroRAP programme is encoded using an ad hoc protocol. An automated data collection process has been set up to check the DGT URL every ten minutes for updates and/or new traffic-related information. Each line in the input text file corresponds to any one of these types of information: traffic congestion (due to accident, peak hour traffic jam, temporarily blocked road, flood, landslide, vehicle breakdown, sport event, public holiday and others), weather-related road conditions (heavy fog, rain or wind, icy or snowy road), road works, mountain pass information 2
  3. 3. (closed, chains required). For every traffic event the following data is also provided: province, city, road name, start-end km mark, level of service, road lane (driving direction: north, south, east, west; ascending/descending; both directions), next city in the driving direction. Events reported by RACC members to its emergency call centre are filtered so that only events that do cause (or may cause) traffic congestion are mapped to XML messages and aggregated to the TIC server database. On taking a call, the call centre operator gathers information about the position of the car relative to the lane. This information is used to filter events in the source (for example, a correctly parked vehicle that reports breakdown will obviously not affect the traffic conditions and will generate no XML message towards the TIC server). Every time a new RACC-XML message is stored into the dedicated TIC server folder the corresponding input module processes it. All static data is manually gathered from different sources (the DGT website, EuroRAP results in Spain) and manually mapped to a common text file format. This file is then copied by the TIC operator into a dedicated TIC server folder and automatically processed by the corresponding input module. This process being partially manual is not a problem, while static data is not expected to vary too often (once a year at most). DGT plain txt feed USER / TIC OPERATOR Visualize [Events, Maps, Traffic Cameras] Edit Querying RDS-TMC (RNE3) TX TIC SERVER http://dgt.es/gsmplus. txt T DISSEMIN ATION COLLECTION MAN AGE MENT •TIC Indicators Speed Cameras (Radars) Processing Processing Conversion Conversion •TIC System Messages Reception Emission Black Spots TXT •TIC Statistics TIC-XML TIC-XML JSON •TIC Reports Processing Storing Input Modules Monitoring Output Modul es L XM RACC XML feed ATIS web portal TIC ADMIN Import/Export Configuration Backup System restore ASC, CSV, GPX, KML, OV2 POIs download Figure 1 – TIC server architecture: data sources and dissemination channels 3
  4. 4. The previously described data sources are homogenised by specific TIC server input modules that have been coded to translate every data feed into a common XML schema (TIC-XML). The generated TIC-XML file is then automatically aggregated to the TIC server database. Several processes have been defined at the database level to resolve whether to insert a new record or update existing data and to undertake high performance resources storing, computing and analysing. To disseminate the TIC server data, output modules have been defined to convert the database consolidated data to the required output formats (JSON3 so to be published in our AJAX-driven Google Maps web application). Rules for parsing and transforming data have been implemented as XSL patterns in both the input and output modules. The designed input modules apply ‘TMC coding’ to every dynamic data source. The DGT data feed is not originally formatted according to the TMC events and Spanish location tables. Neither is the RACC feed. One of the main goals of the TIC server is to amalgamate data in such a way that further dissemination is possible by multiple channels, for example RDS-TMC4. Thus, all traffic events are translated into the equivalent TMC event and geo-located according to the approved Spanish TMC location table. A noteworthy feature of the designed TIC server output modules is that static data is also encoded into the most popular POI (Point Of Interest) file formats (ASC, CSV, GPX, KML, OV2) and stored in dedicated web server folders so that they can easily be downloaded from the web portal and displayed in most commercial GPS units or popular applications such as Google Earth. After all, no such traffic information system can operate entirely autonomously. Dynamic data must be constantly checked for validity and manually edited by TIC operators when required (a user friendly wizard lets any TIC operator easily create or edit any traffic event in several steps; this event is then automatically published into the ATIS web portal). Intelligent automatic expiration processes have also been defined to automatically delete events from the TIC server database after a given timeout. 1 Dirección General de Tráfico (Spanish Traffic General Directorate). 2 Several enhancements had to be introduced in this application in order to provide traffic-related and not only assistance-related information when reporting an incident involving a RACC member (accident, breakdown). 3 JSON stands for JavaScript Object Notation and is a lightweight way of describing hierarchical data. That makes it an ideal candidate for AJAX applications (such as the presented system) as a data-interchange language. 4 Radio Data System – Traffic Message Channel. The RDS-TMC service is available in Spain on RNE 3 radio station (Radio Nacional de España 3) with DGT traffic information. RACC has set up a dedicated Point to Point data line with RNE to broadcast TMC data (both urban and inter-urban), but the service is not operative yet. 4
  5. 5. 3. THE TRAFFIC INFORMATION CHANNEL ATIS WEB PORTAL To a large extent, the perceived usefulness of a traffic and travel information web portal depends on the availability of highly accurate information about the real-time situation of the road network (dynamic data). However, additional information on the permanent road conditions (static data) on a given route can also be extremely useful. The presented system goes one step further and lets the user download the POIs into the file formats managed by all the major GPS manufacturers (TomTom, Garmin, Mio, Navigon and others). At the same time, as much important is the ease of use of the application which, in our case, is ensured by the well-known Google Maps user interface. Extensive research has been done in the programming phase in order to overcome the technical issues inherent to any web application (Google Maps in particular) aiming to display large amounts of time-varying data on a digital map: a reasonable performance and the implementation of efficient scale-related algorithms for the representation of data. 3.1. The performance issue Performance is a common problem in rich web applications communicating with complex databases and displaying a great amount of live, changing data (as traffic information data is). In order to overcome this technical issue and improve the user experience, layers of different types of data can be enabled/disabled, thus generating asynchronous remote AJAX calls (XMLHttpRequest) to a proxy service that parses tailor-made JSON responses towards the Google Maps layer. The designed proxy service reads data from files updated by complex queries in the web server database. The selected data is automatically updated into Google Maps every five minutes. Manual update is also available. The use of an AJAX approach to the performance issue allows the presented ATIS to be highly interactive and behave like a local application. AJAX allows the web page to retrieve small amounts of data from the TIC server and serve them to Google Maps without reloading the entire page. If we had not used AJAX, any retrieval of data from the server would have required the entire web page to be refreshed in the user's computer. As a result, our system would permit far less interaction. AJAX systems can validate one or two items at a time "behind the scenes" without making the session cumbersome, especially over slow connections. 5
  6. 6. 3.2. Custom algorithms for efficient representation of data To use markers (to represent dynamic traffic-related or static road-related events, in our ATIS) in Google Maps is fairly trivial, at least when you have a reasonable amount of them. But once you have more than a few hundred of them (which actually is our case), performance quickly starts to degrade, and this links with the previous point, obviously. Most web sites powered by Google Maps use the Marker Manager utility library provided by Google as a first approach to solve this problem. The Marker Manager keeps track of all your defined markers. By defining at which zoom-levels each marker should appear it is possible to cluster the markers to reduce the amount being shown at a time. This is an easy, yet useful, technical approach to the problem. But not enough, in our opinion. We thought the user may have a wrong impression that there is a lack of information when viewing the map with an inappropriate zoom- level. In other words, if you don’t happen to select the right scale, then you may not visualize that information that is truly relevant to you. An even more efficient way of using the Marker Manager, and our finally chosen approach, is to use ACME labs Clusterer. This is a third party JavaScript library that offers a faster way of adding markers. It is released under the BSD license, is freely available and allows faster performance by doing two things. On the one hand, only the markers currently visible get created. On the other hand, if too many markers would be visible, then they are grouped together into cluster markers. This lets you have literally thousands of markers on a map while maintaining decent performance (even more when enhanced with AJAX). We could test and realise that this approach is significantly faster than the Marker Manager approach. In our ATIS, when clicking on a given cluster marker the custom visualization algorithm shows which the underlying data is. Every link to the grouped items (see Figure 2: three live traffic cameras, two radars and three EuroRAP stretches are embedded under the cluster marker) automatically centres the map to the latitude and longitude GPS coordinates of the selected item, sets the zoom level to an optimal scale and displays the extended information as stored in the server database: the TIC server output JSON modules (built using XSL patterns) obtain the GPS coordinates for every DGT traffic event from the TMC location points (location of RACC-reported traffic accidents is originally GPS coded). All traffic events are represented in Google Maps using the GPS latitude and longitude coordinates. 6
  7. 7. Figure 2 – Cluster marker dynamic grouping of data Search engine bar Enable / Disable all layers Dynamic data layers and manual refresh button Cluster Marker POIs layers and download button Zoom Window Direct links Dynamic data text-mode panel Weather web service Figure 3 – Main features of the ATIS web portal 7
  8. 8. The user can use the zoom window functionality provided by the Google Maps API [1]. Dynamic data related to the current zoom setting can be viewed both in text mode (in the bottom panel) and visual (map) mode. Weather conditions in the current map-centred city are provided by the free ‘weather.com’ web service when available. Last but not least, an advanced search engine has been implemented that can do a complex search on the Google Maps database and direct links to the major Spanish cities and parts of the country are also available. 4. FUTURE WORK Historical and live loop sensor data (available from the DGT in many Spanish cities) could be used to build traffic forecasting services, improved real-time traffic information and dynamic routing. Floating Car Data from the RACC roadside assistance vehicle fleet (which is currently collected and stored at the emergency roadside assistance system database but not yet exploited) could be used to provide estimate travel times. On the other hand, Phone FCD from RACC Virtual Mobile Operator users could be broadcasted by a custom built-in application and collected in the TIC Server for the same purpose (in this case, the required critical mass of RACC VMO users willing to switch on the application when driving and provide continuous location data is expected to be far enough to have satisfactory results). In the programming side, use of the more specific GeoJSON (a format for encoding a variety of geographic data structures) as a data exchange format will be studied. Native JSON is a new feature to IE8 and Firefox 3.5. Built in serialization and deserialization in the browser will make evaling JSON text a thing of the past, thus contributing to enhance performance. User experience can be dramatically improved at a low cost with the addition of 3D capabilities to our Google Maps-based ATIS via the Google Earth plug-in and the Street View service in urban areas. The modular and scalable architecture of the TIC server makes it possible for further traffic data feeds to be seamlessly aggregated into the server database and disseminated through the current ATIS, RDS-TMC, SMS/MMS or other broadcast channels in the future. 5. REFERENCES [1] http://code.google.com/intl/es-ES/apis/maps/documentation 8

×