TrafficPulse : A Mobile GISystem for Transportation

Ren-Yu LiUniversity of Calgary

500 University Drive N.W.Calgary, Canadarli@ucagary.ca

Steve H.L. LiangUniversity of Calgary

500 University Drive N.W.Calgary, Canada

steve.liang@ucalgary.ca

Dong-Woo LeeGulf University

for Science and TechnologyP.O. Box 7207

Hawally 32093, KuwaitLee.d@gust.edu.kw

Young-Ji ByonKhalifa UniversityPO.Box 127788Abu Dhabi, UAE

youngji.byon@kustar.ac.ae

ABSTRACTToday municipalities around the world spend millions of dol-lars to understand the dynamics of their transportation in-frastructure. Traditional approaches for traffic data collec-tion rely on a fixed sensor infrastructure (e.g., inductive loopdetectors), and because these sensors are expensive to de-ploy and maintain, the traffic data coverage is limited tomain highways and major intersections. This limited in-formation hinders municipalities to achieve efficient trafficmanagement and control. To address this problem, we de-velop TrafficPulse, a mobile GISystem platform for trans-portation applications. For the client front-end, we developthe TrafficPulse mobile application that collects traffic databy integrating participatory sensing, opportunistic sensing,and offline data collection module. For the server back-end,we develop Geopot cloud, a cloud-based geo-location dataservice for mobile applications. In order to demonstrate thepotential benefit of this system, we also develop a carpoolingrecommendation system to analyze user-shared content andprovide a recommendation service to TrafficPulse users. Inthis paper, we describe our system architecture and experi-ences, allowing our paper to be used as a reference for otherdevelopers who want to develop their own transportationapplications.

Categories and Subject DescriptorsC.3 [Special Purpose and Application-Based Systems]:Miscellaneous

General TermsDesign

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ACM SIGSPATIAL MobiGIS’12, November 6, 2012. Redondo Beach, CA,USACopyright (c)2012 ACM ISBN 978-1-4503-1699-6/12/11 ...$15.00.

Keywordsvolunteered geographic information, transportation, systemarchitecture

1. INTRODUCTIONAccurate and real-time traffic monitoring is essential for

controlling traffic flows. Municipalities around the worldspend millions of dollars to understand the dynamics of theirtransportation infrastructure [25]. Traditionally, traffic datacollection methods rely on road-side inductive loop detectors[8]. These techniques are expensive to deploy and maintain,and they are not scalable, nor economically sustainable forrapidly growing cities. As a result, existing systems onlycover small regions of the city.

Now, more than 4 billion people are carrying mobile phones.The Smartphone adoption rate has reached over 27 percentaround the world [4], and the number continues to rise. Also,a Smartphone has sensors such as a GPS receiver, a com-pass, accelerometers, and a camera. The high penetrationrate and the sensing capability of Smartphones have movedmobile phones from pure communication tools to networkedmobile sensing devices. Moreover, people with Smartphonesspend twice as much time on social networking applica-tions such as Facebook, sharing knowledge, events and in-terests through the Internet [10]. The increasing popular-ity of Smartphones in recent reports suggests that collect-ing data from Smartphones has been growing several timesfaster than from fixed sensors [18]. Using cellular phonesas traffic data probes could be one of the most promisingmethods for traffic data collection. We envision a mobileGISystem for transportation, in which users can contributespatio-temporal traffic information and visualize the dynam-ics of urban traffic through the use of Smartphones.

To put the idea into perspective, imagine the followingtwo scenarios: 1) the surge of oil prices has increased trans-portation costs, and a user wishes to start carpooling to savemoney. She queries the system for carpooling recommenda-tions. In response, she receives a list of candidates thathave similar routes as her, and she can contact these users.2) a user is walking on a road and find that it is too icy fordriving, so he takes a photo of the road to warn other peo-ple. The system rewards him with Green Karma points andnotifies the public about the potential occurrence of hazard.

We design TrafficPulse as a mobile urban sensor plat-form and build a system to assemble traffic informationprovided by users (i.e., volunteered geographic information).The proposed platform provides a cost effective approach tosolve traffic problems; the high penetration rate of Smart-phones guarantees high spatio-temporal resolution informa-tion about traffic, and the low cost of Smartphones ensuresthat using Smartphones as sensor probes is an economicallysustainable approach for rapidly growing cities. We alsouse user-shared traffic data to provide services to benefitusers (e.g., carpool recommendations), so that TrafficPulsebecomes a two-way system for transportation. Our systemarchitecture and our experiences could also be references forreaders to develop their own system for transportation.

VGI and TransportationVolunteered geographic information (VGI) is the harnessingof tools to create, assemble, and disseminate geographic dataprovided voluntarily by citizens [15]. VGI consists of rich-context data such as photographs and information that can-not be sensed through conventional sensing approaches (e.g.,contextual information, such as human feelings, emotions,etc). Examples of systems that collect VGI are Ushahidi[6], OpenStreetMap [3], and Google Map Maker. VGI canbe potentially very valuable for dynamic traffic manage-ment because the collected data has high currency, differentspatio-temporal scale and density [22, 23]. However, VGIcontains noise and is highly heterogeneous and inconsistent.Data processing and data cleaning are required to filter non-reverent and incorrect information.

To collect and use VGI to solve traffic problems, we havedeveloped a mobile application, a scalable Geopot server, aswell as a carpool recommendation system. The rest of paperis organized as follows: Section 2 addresses the challenges ofdesigning and developing a mobile and server application,as well as the challenges of using VGI for transportationapplications. Section 3 reviews the existing transportation-related mobile applications and details the limitations of ex-isting systems, and Section 4 describes our solutions. Ourwork is summarized in Section 5.

2. CHALLENGESThis section describes the challenges of designing and de-

veloping a mobile GISystem for transportation. We dividethe challenges into three separate parts: mobile applicationdesign, data storage and query performance, and the use ofVGI for transportation applications.

2.1 Mobile application designA Graphical User Interface (GUI) for a location-based mo-

bile application must first and foremost be as easy and in-tuitive to use as possible. When users are in a rush, orwhen they are on buses, it is difficult and sometimes danger-ous for them to handle complicated interactions (e.g., press-ing small buttons). Designing a user-friendly GUI is im-portant for increasing users’ interests. Alongside good GUIdesign, features of mobile applications should always be con-sidered to provide satisfactory user experiences. For exam-ple, foursquare is famous in that its front-end is presented tothe user as a game, using a reward system to motivate usersto accomplish things. Google Maps is one of the most pop-ular mobile applications because it enables real-time mapnavigation [5]; maps therefore become core features for lotsof applications. In addition, Augmented Reality (AR) real-

izes the concept of ubiquitous computing: making the realworld in a computer. AR has been applied to the trafficto provide different user experiences: mainly implementedby overlaying objects on camera screens. Making the mostof mobile devices in transportation applications and provid-ing special user experiences to arouse user interests are twobig challenges for designing a mobile transportation system.Moreover, privacy issues should be carefully considered inapplication development, too.

2.2 Data storage and query performanceTo turn mobile devices into sensor probes, volunteers should

be able to share geographic information (GI) or check-in lo-cations at anywhere (spatial), anytime (temporal). In addi-tion, due to the limitation of the bandwidth, each requestshould only involve a small amount of data being trans-ferred. Moreover, the request to server can be frequent (e.g.,user’s trace), and the data contributed are geographicallymeaningful. Naıve solutions for data storage are realized viaconventional spatial database such as Oracle and PostGIS.These relational databases are not suitable for VGI appli-cations because they involve a lot of relational operationsand schema-based relational data model, which degrade thescalability when the data size grows [20].

User-shared GI will become stale at some point. For ex-ample, a user that queries near-by traffic condition meanshe/she only cares about the current traffic dynamics, notabout yesterday’s traffic conditions. By storing data in aconventional spatial database, we mix stale and fresh infor-mation in the same database. When running spatial queries,the increasing number of stale tuples lowers the query per-formance. Designing a data service that preserves the spatialrelationship between GI while keeping up with fresh infor-mation enables a better index of raw data and better queryperformances. Designing a new spatial storage system fora VGI application is therefore an interesting research chal-lenge.

2.3 Use VGI for transportation applicationsIt is important to create incentives for users to contribute

data. Providing recommendation services derived from user-shared contents can be one way to motivate users; analyz-ing VGI is necessary to achieve the goal. VGI consists ofheterogeneous data [24]. Data contributed for traffic canbe a series of location points, texts that describe events orfeelings, as well as photos taken to record traffic accidents.Since data contains noise and can be inconsistent, data un-certainty is an issue to be addressed [16]. For example,non-intentional errors may occur due to the system failure(e.g., coarse GPS accuracy and weak cell phone tower signalstrength); or limited knowledge about the environment (e.g.,mistaken place names). Because of noise and inconsistencyin the data, it is difficult to analyze VGI. Besides, the useVGI for transportation applications may involve the inten-sive processing of large amounts of point data; conventionalorigin-destination (O-D) matrix [27] is not efficient for stor-ing and analyzing VGI data. To overcome the uncertaintyand volume issue, a more sophisticated approach is required.In a later section, we will use carpooling as an example toshow how we use VGI collected by our system to provide arecommendation service.

These three challenges must be solved in order to builda VGI system for transportation. Before further discussing

our system architecture, we require to understand what arethe limitations of existing systems.

3. EXISTING SYSTEMS AND LIMITATIONSExisting VGI systems for transportations, such as Google

Map Mobile [1], IntelliONE.com, Microsoft Research Ner-icell [21], MIT CarTel [17], regard mobile devices as pas-sive data collectors (i.e., opportunistic sensing), and humando not participate in data collection (i.e., no participatorysensing). CarTel, an opportunistic sensing example usesprobe vehicles with GPS receivers to monitor their move-ments, and report data back through opportunistic networkconnections. Another example is the NeriCell project, andit focuses on monitoring road and traffic conditions usingSmartphones. These systems task sensors that are equippedon mobile nodes to collect desired information, and there isno human interpretation involved in data collection.

Among the existing systems, Waze.com [7] is the mostsimilar system to TrafficPulse in term of its focus. It con-tains both opportunistic and participatory sensing compo-nents; it supports “pave” function to record traces and pro-vides a navigation system for guiding a mobile unit througha route to a destination. It as well provides a user-friendlyGUI to allow users to contribute and visualize traffic data.In addition, it integrates foursquare to enable check-in. How-ever, it still has the following limitations.

It does not collect offline and Wi-Fi location data.Waze targets only online users and it only collects GPS lo-cation data. That is, when there is no Internet accessible, orwhen a user is indoor, he/she is not allowed to check-in orpost comments. However, not every Smartphone supports3G or Edge network, and most of the time, users are notaccessing GPS signals. Information collected under offlinemode as well as Wi-Fi locations collected indoor, are ex-cluded but potentially valuable to traffic management. Forexample, a Smartphone can receive GPS signals and collectgeo-locations without accessing the Internet. Since offlinedata collected could be uploaded later after access to theInternet is available, this information is still valuable formonitoring traffic dynamics although it is not published atnear real-time. Also, we not only want to monitor dynamictraffic flows, but are also interested in understanding thetriggers of traffic congestions. Examples of these triggerscould be indoor activities such as sales for big brand of lux-ury products, or big concert, etc. As a result, it is necessaryfor a transportation system to collect offline and Wi-Fi lo-cation data.

It does not utilize existing mobile sensors for nav-igation and transportation-related applications. Todate, GPS map navigation is the most popular feature fortransportation applications. However, it is not the only waywe can realize navigation. By using a compass, a GPS re-ceiver, and a camera, we can use AR for navigation. AR isan extension of one’s perception of reality: objects are over-laying on the camera screen and information is perceivedthrough the way we live. AR potentially provides very use-ful way to direct users. In addition, camera is not onlyuseful to realize AR; it is also useful for reporting traffic ac-cidents and events. Ushahidi is one VGI application thatconsiders photographs as one type of VGI resource. Othersensors such as accelerometers can also be used for decetingtransportation mode and road condition.

It provides foursquare’s check-in to record loca-

tions and “pave” function to record new roads, butthey are not for traffic management. Users’ check-insand paths are very valuable information for municipalities.By knowing users’ paths and their favorite check-in loca-tions, we have more insight into users’ behaviors (e.g., pref-erences and driving behavior), as well as traffic dynamics(e.g., average speeds of roads). We will be able to bene-fit the public by providing useful services derived from datacollected, creating a feedback loop for the system. For exam-ple, after the increment of oil price, carpooling is currentlybecoming a popular commuting mode for American workers[26], it would be helpful to provide carpooling recommenda-tion by analyzing user-shared information.

TrafficPulse tackles the limitations mentioned above. Itsupports both opportunistic and participatory sensing mod-ule to collect VGI as Waze, and it collects offline and Wi-Filocation data. It provides photo up-loader, AR-based navi-gation and transportation mode detection. It also providesextra service derived from user-contributed data. Moreover,different from Waze, our raw data is available to the publicand city managers for research and our system is extensibleto develop more value-add features. Details of our systemare described in the next section.

4. SYSTEM ARCHITECTURETrafficPulse’s vision (Figure 1) is to design a system that

enables the opportunistic and participatory sensing tasks:to allow mobile devices to automatically collect sensor data(e.g., GPS, accelerometer data) and to allow users to check-in their locations; to share sensor data; to text traffic condi-tions and to upload photos through the use of Smartphones.To motivate users to contribute data, TrafficPulse’s clientfront-end is presented as a “Green Karma” game. By shar-ing data, users are rewarded with Green Karma points; userscan compete to be the “Green-est”. After obtaining user-contributed data, the system is able to conduct social net-work analysis, crowd analysis, as well as sensor data analysis.Then results are used to provide recommendation servicesto users, making TrafficPulse a personalized traffic system.We wish to use user-shared contents to benefit the publicand provide a pain-free approach to solve traffic problems.

To achieve our goal, we present a unique system architec-ture. Figure 2 illustrates the TrafficPulse architecture. Oursystem has 1) a User Experience Layer, in which differentmodules are provided allowing users to publish and visualizetraffic data, 2) a Sensor Layer, which represents the sensorsof a mobile device, 3) an Application Layer that manages toexecute applications, including opportunistic sensing tasks,participatory sensing tasks, and offline data collection, 4) aData Service Layer that handles security issues, as well asrequest/response to/from the back-end server, 5) and finallya Data Layer that handles data storage and manages datainsertions and retrievals.

To describe the architecture clearly, we divide the discus-sion into three separate parts: Client, Server, and Applica-tion. In the Client section, we detail User Experience Layer,Sensor Layer, Application Layer and Data Service Layer. Inthe Server section (i.e., Data Layer), we describe the designof data storage and indexing system of TrafficPulse server.In the Application section, we provide an example to showhow we enable a personalized transportation system throughanalyzing user-contributed information.

Social Network Analysis

Crowd Analysis

Sensor Data Analysis

geo-locations

user-shared contents

sensor data

* Friendship recommandation

* Carpool recommandation * Crowd topic discovery

* Road condition analysis

* Traffic congestion detection

* Route suggestion * Traffic event predition

Figure 1: TrafficPulse concept

4.1 Client

4.1.1 User Experience LayerTo allow users to contribute traffic information through

the use of TrafficPulse mobile application; we have four mod-ules in the User Experience Layer to accomplish jobs. Theyare described as follows:

Reporting module.This module allows users to share sensor data, current

road conditions, and traffic events to the public throughparticipatory and opportunistic sensing. Users can reporttraffic information at different levels of detail through par-ticipatory sensing; they can simply click buttons to reportdifferent traffic conditions or comment traffic details in textboxes, and they can take photos to record events and sharethem to the public. These user-generated contents will pub-lish to server along with geo-locations (Figure 3 (b)-(d)).In addition, users can also share their traces and sensordata through opportunistic sensing. Sensor data such asgeo-locations, speeds, and accelerometers will be automati-cally collected and published.

Rewarding module.Gamification is the use of game design techniques that ap-

plies to non-game applications, in order to encourage peopleto adopt them [12]. An example of a system that uses Gam-ification is foursquare. Motivated by foursquare, we presentTrafficPulse front-end as a “Green Karma” game and de-sign the rewarding module to motivate users to participate.We reward users with “Green Karma” points every timethey contribute data. Users’ Green Karma values are ac-cumulated and ranked, so that users can compete to be the“Green-est” (Figure 3 (e)). In order to make the game moreinteresting, we also update the colors of the Green Karmaicons based on users’ scores.

Visualization module.This module provides the users with four mapping func-

tions: mapping near-by users, mapping latest trace, map-ping near-by public transit stations, and mapping events(e.g., accident, traffic congestion). Mapping near-by usersallows users to update their current traffic condition at near

Mobile Device

Privacy

Data Service Layer

Local cache

User Experience Layer (GUI)

Rewarding module

Reporting module

Guiding module

RESTful service interfaces

Mapping module

Application Layer

Opportunistic sensing

Data Layer

Participatory sensing

Offline application

Local Data Service

Cloud storage (AWS S3)

R-tree index Local hash table

Sensor Layer GPS

Camera

Gyroscopes

Compass

Figure 2: TrafficPulse architecture

real-time. Mapping latest trace enables users to review theirlatest traces and their times spent on last travels. Mappingnear-by public transit stations allows users to visualize therelative orientations between transit stations and their cur-rent locations, so that they can find the nearest stationsfaster. And mapping events allows users to keep up withtraffic events easily. This module mainly helps users to makefaster decisions and prevents them from getting into trafficcongestions and potential hazards (Figure 3 (f)-(g) and Fig-ure 4 (a)). In order to protect privacy, we only allow users toview their own trace in mapping latest trace; to view points(i.e., users’ geo-locations) in mapping near-by users; and toview texts (i.e., shared contents) in mapping events. With-out showing users’ names and identifiers, we ensure that anypersonal information is secured.

AR Guiding module.In TrafficPulse, we create a public transit AR module to

allow users to visualize near-by public transit stations anddetails information such as distances from users’ current lo-cations to stations. This public transit AR also navigatesusers to stations; the information show on camera screenupdates while users move. Users can also the use publictransit AR (Figure 4 (b)) and the mapping near-by publictransit stations (Figure 4 (a)) together at the same time,so they can find stations faster. This feature benefits thosewho are not map-readers and those who are new to a place.We are planning to include bus schedules to increase thefunctionality.

4.1.2 Sensor LayerTo make the most of mobile devices to better understand

(a) Log in (b) Report buttons

(c) Report textbox (d) Photo up-loader

(e) Green Karma (f) View near-by

(g) View latest trace

Figure 3: Screenshots of TrafficPulse GUI - 1

(a) Map-based view of public transit sta-tions

(b) Augmented Reality of public transitstations

Figure 4: Screenshots of TrafficPulse GUI - 2

city dynamics, TrafficPulse uses GPS, camera, compass, andaccelerometer data. GPS is used for navigation and formarking check-in and event locations. The camera providesa different way to navigate users and record real-time events.Compass data helps to realize the AR application by deter-mining the relative orientation from objects to users’ loca-tions. Accelerometers are used for detecting users’ trans-portation modes. For example, if a user were driving fast,the values of accelerations would be high; the system shouldtrigger operations such as locking the screen, so the usercannot use our mobile application. Accelerometers can alsobe used for detecting road conditions [21]. Sensor Layer hasclose relation with User Experience Layer, and these sen-sors support the sensing tasks designed in User ExperienceLayer.

4.1.3 Application LayerThe Application Layer manages to execute three types

of tasks: opportunistic sensing tasks, participatory sensingtasks, and offline data collection. The objectives for eachpart are described as follows:

Opportunistic sensing.Opportunistic sensing in our application refers to task-

ing users’ sensor-equipped mobile phones to report infor-mation from their locations. We allow users to contributegeo-locations, speed and accelerometer data automaticallycollected by their mobile devices. We can derive traffic con-ditions simply from this type of numerical data. We can alsouse the opportunistic sensing data to derive users’ trans-portation modes, driving behaviors, etc.

Participatory sensing.

We provide participatory sensing methods to allow usersto participate sensing tasks and to report information aroundthem. For example, a user makes comments or takes photosof current traffic conditions, identifying whether the trafficis moving smoothly. This type of data provides insight intothe environment at that location. We use the participatorysensing data to derive real-time events and potential haz-ards, etc.

Offline and Wi-Fi location data.Unlike foursquare, we collect data shared by users who are

temporarily offline or are temporarily not accessing GPS sig-nals. Instead of rejecting VGI collected under Wi-Fi locationmode, we do post processing. For example, to remove errorsin a user’s trace (i.e, a series of geo-locations), we examinethe distance and time-interval among near-by locations, andeliminate points with distance to time-interval ratio lies out-side a reasonable range. In addition, to differentiate betweenInternet conditions, when a user reports a traffic condition,the system checks if the Internet is accessible and if not,activates an offline process (Figure 3 (b) grey Wi-Fi icon).Upon activating an offline process, the system stores users’offline data temporarily in the local cache of mobile devices;whenever the system accesses the Internet, stored data willbe uploaded to server.

4.1.4 Data Service Layer

RESTful Service Interface.Any mobile client can communicate to the TrafficPulse

server (i.e., Geopot server) with its HTTP-based REST-ful APIs. For client-server communication, TrafficPulse en-crypts all client requests with MD5 authentications. This isto secure user-provided information and prevent user-sharedcontents from being acquired for illegal use.

Local Cache.The local cache of a client consists in two parts: preference

document and in-memory SQLite database. The preferencedocument stores user’s preferences; whenever the user re-turns to TrafficPulse, TrafficPulse retrieves the preferencesand update the GUI accordingly. The in-memory SQLitedatabase manages the offline data and locations of publictransit stations.

4.2 Server: GeopotTo keep high query performance, to minimize the cost

of building and maintaining data storage, and to keep upwith fresh geographic information in database, we designour Geopot server architecture to be tightly coupled withspatial indexing method. In this paper, we concisely de-scribe Geopot architecture. Because Geopot uses databaseand cloud technology, as well as R-tree indexing, readerswho are interested in knowing details can refer to our pa-per published in [20], which is a comprehensive discussion ofGeopot.

Figure 5 demonstrates the implementation of the Geopotserver. We design the system to have two parts: a local dataservice and a Cloud-based data service (i.e., Amazon SimpleStorage Service). Local data service uses an in-memory R-tree and a local networked in-memory hash table to indexand store recent spatial data. The Cloud-based data serviceis applied to store and access stale data, that is, once spatial

data is stale, Geopot uploads it to Cloud space.Volunteers publish their mobile data through RESTful

APIs. Each user request contains geo-location (i.e., latitudeand longitude), and information required to query server.Geopot server’s front-end receives users’ requests and dis-tributes them evenly to the internal threads by using shard-ing method [11], which partitions incoming requests to in-ternal threads horizontally. Each thread has its own R-treefor spatial data indexing. In order to maintain a lightweightspatial index database, instead of inserting each raw datuminto R-tree, we perform a modified online Leader-Followermethod [14] to group geographically close data into clusters,only information for each cluster is added into the R-tree.Each cluster has information consisting of centroid coordi-nates; a hash key generated by its centroid, and the radiusencompassing its cluster. The centroid of a cluster is used asa spatial index of R-tree, and hash key generated is used toaccess the local networked hash table in which the membersof clusters are temporarily stored. This model is to ensurethat each R-tree is always a compact size that fits into themain memory to keep pace with growing data volume.

Because it is impossible to store all GI in the local dataservice as the data volume increases, we design the localdata service to store recent data only (i.e., data within aparticular time window). When a new cluster is created, acorresponding Time-to-Live (TTL) value will be attached.A TTL value is used to update a cluster when its content inlocal hash table is regarded stale. Hash tables of clusters aredeleted when they are expired. Upon deleting a local hashtable, the contents of a local hash table are published intothe external Cloud storage.

Figure 5: Geopot server implementation

From:D. W. Lee and S. H. L. Liang. Geopot: a Cloud-based geoloca-tion data service for mobile applications, International Journal ofGeographical Information Science, 25(8):1283-1301, 2011.Retrieved 14 August 2012, from Taylor Francis Online. Imageused with permission.

4.3 Application: Carpooling RecommendationTrafficPulse collects GPS data from volunteers. This data

can be users’ traces, traffic events and traffic conditions.By analyzing the sharing data and providing personalizedrecommendation services; we can motivate users to partic-ipate in data sharing and create a feedback loop for oursystem. Here we use carpooling recommendation as an ex-ample. Similar to Section 4.2, we briefly describe the imple-mentation of the carpooling system; readers who are seekingdetails of this research can refer to our paper published in[19]. We held a data collection campaign to collected VGI

and recruited 50 students on University of Calgary campusto be TrafficPulse users. Trace data collected from Traf-ficPulse users reflects most of the city’s road network (Fig-ure 6). Due to lack of battery power or GPS signal blockage,data streams contributed by users can be either continuousor discrete. Although the collected trajectories may be in-complete, they are informative enough for carpooling rec-ommendation.

To perform carpooling recommendation, we need to deter-mine trace similarities between users, and the most commonsolution is to compare O-D matrices that record traces. O-Dmatrix of a traffic network is successfully applied to Intelli-gent Transportation Systems (ITS) strategies such as trafficcongestion relief and dynamic traffic management. SinceO-D matrix records geo-locations of paths as a matrix, itis not suitable for large-scale trajectory profiling, which isrequired for determining similarities among driving routes.We propose a carpool recommendation process consistingof two parts: 1) crowd-sourced data generalization, and 2)building a prefix-tree for simplified user trajectories [19].

Data generalization is a process to get a broader view ofhigh-density data, which can retain important feature pointsof a trajectory that preserve the sequence of movements. Inour data generalization process, we split each trajectory intomultiple line segments using a time and distance limit. Eachline segment has its own timestamps and geo-locations forits end-points. We use Douglas-Peucker [13] model to elimi-nate midpoints of straight roads, so that feature points thatare essential to identifying the trajectory similarity, such asintersections and frequently traveled road corners, will beretained.

To ensure a more compact trajectory profile, feature pointsare mapped into a tile map system using a Bing Maps quadkey scheme [2]. After mapping feature points of a trajec-tory to quad keys, last few digits of near-by quad keys mayvary slightly, depending on the distance between two featurepoints. Since near-by quad keys tend to change slightly, wecan benefit from a more compact storage strategy by shrink-ing the sequence of feature points (i.e., quad keys) to oneprefix quad key string to represent the subset. We achievethis by using Longest Common Prefix Substring (LCPS) [9]of quad keys. The idea of LCPS is to group several quadkeys in a row into one common prefix. If a quad key rep-resents an area that is distant from its near-by quad keys’,the length of the common prefix is reduced, resulting in adifferent LCPS. This allows tracking of movements for tra-jectories, as well as comparing similarities between trajecto-ries. However, not all near-by quad keys vary only slightlyin the last few digits, for example, when location points fallaround the quad key boundaries, quad keys change drasti-cally. Splitting a trajectory into several sub-trajectories cansolve this problem.

We construct a prefix-tree to organize simplified user tra-jectories. To construct a prefix-tree, we use LCPSs as keys,and store metadata of fractions of trajectories into tree nodes.This metadata consists of the trajectory ID, user’s ID andthe frequency of its key prefix. By querying the prefix treewith a quad key, the tree can traverse to a node to get agroup of users who share a part of the trajectory, and thecorresponding trajectory IDs. After obtaining the completetrajectories of target users using trajectory IDs, we will beable to measure similarities by comparing traces.

Figure 6: Crowd-sourced GPS traces

5. LESSONS, CONCLUSIONS, AND FUTUREWORK

We have successfully designed and developed a mobile ap-plication to allow users to report and visualize traffic in-formation and a unique architecture for server to leveragethe benefit of Cloud storage and to ensure high query per-formances. In addition, we have also developed a carpool-ing recommendation system, which analyzes traces collectedfrom TrafficPulse users.

When it comes to designing a mobile application for trans-portation, we recommend including both an opportunisticsensing module and a participatory sensing module. Thesetwo types of sensing data allow us to derive different kindsof information; we can derive users’ transportation modes,driving behaviors, and road conditions through analyzingopportunistic sensing data and derive real-time events andpotential hazards through studying participatory sensing data.

We also find that it is necessary for our system to collectoffline and Wi-Fi location data. Now, many people haveSmartphones; but not every one of them has access to theInternet at all times. As mentioned, although offline data isnot publishing at near real-time; it can be stored for offlinedata mining.

We also suggest readers to separate stale and raw datawhen designing a storage service for transportation appli-cations. Shared data in such applications become stale atsome point, however, most user requests are focused on nearreal-time data. Since users are only interested in recent in-formation, we degrade the efficiency of executing commandson server by mixing stale and fresh data in the same storage.

It is important to create incentives for users to contributedata. Developing personal recommendation services derivedfrom shared contents can potentially create a feedback loopfor a system. Once users benefit from information providedby the system, they have more incentive to share their data.

Lastly, we design our system to continuously improve basedon user feedback. For example, we include a photo up-loaderbecause users found it to be an important resource. Figure7 shows a picture taken by a student who witnessed a caraccident and wanted to provide a visual aid of the scene toother users in the system.

In the future, more privacy-preserving methods should be

considered in order to have more users use the proposedmobile GISystem platform. For example, privacy issue foroffline data should be carefully managed. In addition, it isnecessary to provide animations to display the dynamics oftraffic flow on clients in the future, so that users can view notonly near-by geo-locations but also their movements (e.g.,directions).

We are also planning to turn TrafficPulse into a socialnetwork-based platform so that we can do various studiessuch as social network analysis and crowd analysis. By pro-viding more services derived from user-contributed data, wewill be able to create a stronger feedback loop and let moreusers benefit from our system. We also plan to integrateTrafficPulse to existing ITSs, so that municipalities can con-trol traffic flow economically.

Figure 7: Photo of a car accident taken by a student

6. REFERENCES[1] Google maps for android. http://www.google.com/

mobile/products/maps.html#p=default.

[2] Microsoft, bing maps tile system. http://msdn.microsoft.com/en-us/library/bb259689.aspx.

[3] Openstreetmap. http://www.openstreetmap.org/.

[4] Social media: the right tool in right hands.http://bit.ly/fWCjgy.

[5] Stats: Google maps the most popular mobile app inthe uk, with 6.4m users. http://bit.ly/OeFtjb.

[6] Ushahidi. http://ushahidi.com/.

[7] Waze. http://www.waze.com/.

[8] M. Bell. The real time estimation of origin-destinationflows in the presence of platoon dispersion.Transportation Research Part B, 25:115–125, 1991.

[9] L. Bergroth, H. Hakonen, and T. Raita. A survey oflongest common subsequence algorithms. InProceedings of the 7th International Symposium onString Processing Information Retrieval, SPIRE’00,pages 39–48, A Coruna, Spain, 2000.

[10] C. Bonnington. Global smartphone adoptionapproaches 30 percent. http://www.wired.com/gadgetlab/2011/11/smartphones-feature-phones/.

[11] J. Cryans, A. April, and A. Abran. Criteria tocompare cloud computing with current databasetechnology. In Proceedings of the InternationalConferences on Software Process and ProductMeasurement, pages 114–126, Munich, Germany, 2008.

[12] S. Deterding, M. Sicart, L. Nacke, K. O’Hara, andD. Dixon. Gamification. using game-design elements

in non-gaming contexts. In Proceedings of the 2011Annual Conference Extended Abstracts on HumanFactors in Computing Systems, CHIEA’11, pages2425–2428, 2011.

[13] D. Douglas and T. Peucker. Algorithms for thereduction of the number of points required torepresent a digitized line or its caricature. TheCanadian Cartographer, 10(2):112–122, 1973.

[14] R. O. Duda, P. E. Hart, and D. G. Stork. Patternclassification. New York: Wiley Interscience, 2ndedition, 2000.

[15] M. Goodchild. Citizens as sensors: the world ofvolunteered geography. GeoJournal, 69(4):211–221,2007.

[16] J. Grira, Y. Bedard, and S. Roche. Spatial datauncertainty in the vgi world: going from consumer toproducer. Geomatica, 64:61–71, 2010.

[17] B. Hull, V. Bychkovsky, Y. Zhang, K. Chen,K. Goraczko, A. Miu, E. Shih, H. Balakrishnan, andS. Madden. Cartel: a distributed mobile sensorcomputing system. In Proceedings of the 4thInternational Conference on Embedded NetworkedSensor Systems, pages 125–138, 2006.

[18] S. Kaisar. Smartphone traffic characteristics andcontext dependencies. Master’s thesis, University ofSaskatchewan, 2012.

[19] D. W. Lee and S. H. L. Liang. Crowd-sourced carpoolrecommendation based on simple and efficienttrajectory grouping. In The 4th InternationalWorkshop on Computational Transportation Science,IWCTS 2011, pages 12–17, Chicago, USA, 2011.

[20] D. W. Lee and S. H. L. Liang. Geopot: a cloud-basedgeolocation data service for mobile applications.International Journal of Geographical InformationScience, 25(8):1283–1301, 2011.

[21] P. Mohan, V. N. Padmanabhan, and R. Ramjee.Nericell: rich monitoring of road and traffic conditionsusing mobile smartphones. In Proceedings of the 6thACM conference on Embedded network sensorsystems, pages 323–336, 2008.

[22] C. Parker, A. May, and V. Mitchell. Relevance ofvolunteered geographic information in a real worldcontext. In Proceedings of GIS Research UK 19thAnnual Conference, Portsmouth, UK, 2011.

[23] X. Qian, L. Di, D. Li, P. Li, L. Shi, and L. Cai. Datacleaning approaches in web2.0 vgi application. InProceedings of the 17th International Conference onGeomatics, pages 12–14, Fairfax, USA, 2009.

[24] S. L. Shaw. Geographic information systems fortransportation: From a static past to a dynamicfuture. Annuals of GIS, 16(3):129–140, 2010.

[25] J. Supernak. Transportation modeling: Lessons fromthe past and tasks for the future. Transportation,12:79–90, 1983.

[26] R. F. Teal. Carpooling: Who, how and why.Transportation Research Part A: General,21(3):203–214, 1987.

[27] H. J. V. Zuylen and L. G. Willumsen. The most likelytrip matrix estimated from traffic counts.Transportation Research Part B: Methodological,14(3):281–293, 1980.