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.

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. 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. (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. 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. 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. 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. 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. 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