ansport Information Service in Smart Citiesreal.mtak.hu/26081/1/ComMag_paper_published_Aug_2015_u.pdf · garian Academy of Sci-ences (MTA SZTAKI), Budapest, Hungary 1 We use the terms

IEEE Communications Magazine • August 2015158 0163-6804/15/$25.00 © 2015 IEEE

K. Farkas and G. Feherare with the Inter-Univer-sity Centre for Telecom-munications andInformatics, Debrecen,Hungary, and theBudapest University ofTechnology and Eco-nomics, Budapest, Hungary.

A. Benczur and Cs. Sidloare with the University ofDebrecen, Hungary andthe Institute for Computercience and Control, Hun-garian Academy of Sci-ences (MTA SZTAKI),Budapest, Hungary

1 We use the termscrowdsensing, crowd-sourcing and participatorysensing interchangeablyin this paper.

INTRODUCTIONServices offered by smart cities aim to sup-

port the everyday life of inhabitants. Unfortu-nately, the traditional way of introducing a newservice usually implies a huge investment to

deploy the necessary background infrastructure.One of the most popular city services is pub-

lic transportation. Maintaining and continuouslyimproving such a service are imperative in mod-ern cities. However, the implementation of evena simple feature which extends the basic servicefunctions can be costly. For example, let's con-sider the replacement of static timetables withlively updated public transport information ser-vice. It requires the deployment of a vehicletracking infrastructure consisting of among oth-ers GPS sensors, communication and back-endinformatics systems and user interfaces, whichcan be an expensive investment.

An alternative approach to collect real-timetracking data is exploiting the power of thecrowd via participatory sensing or often calledmobile crowdsensing1 [1], which does not call forsuch an investment. In this scenario (Fig. 1), thepassengers' mobile devices and their built-in sen-sors, or the passengers themselves via reportingincidents, are used to generate the monitoringdata for vehicle tracking and send instant routeinformation to the service provider in real-time.The service provider then aggregates, cleans,analyzes the data gathered, and derives and dis-seminates the lively updates. The sensing task iscarried out by the built-in and ubiquitous sen-sors of the smartphones either in participatoryor opportunistic way depending on whether theuser is involved or not in data collection. Everytraveler can contribute to this data harvestingtask. Thus, passengers waiting for a ride canreport the line number with a timestamp ofevery arriving public transport vehicle at a stopduring the waiting period. On the other hand,onboard passengers can be used to gather andreport actual position information of the movingvehicle and detect halt events at the stops.

In this paper, we focus on the introduction ofour crowdsensing based public transport informa-tion service, what we have been developing as aprototype smart city application. The front-endinterface of this service, called TrafficInfo, is asimple and easy-to-use Android application whichvisualizes real-time public transport informationof the given city on Google Maps. It is built uponour Extensible Messaging and Presence Protocol(XMPP) [2] based communication framework [3]what we designed to facilitate the development ofcrowd assisted smart city applications (we alsointroduce shortly this framework). Following the

ABSTRACT

Thanks to the development of technology andthe emergence of intelligent services smart citiespromise to their inhabitants enhanced percep-tion of city life. For example, a live timetableservice of public transportation can increase theefficiency of travel planning substantially. How-ever, its implementation in a traditional wayrequires the deployment of some costly sensingand tracking infrastructure. Mobile crowdsensingis an alternative, when the crowd of passengersand their mobile devices are used to gather datafor almost free of charge.

In this paper, we put the emphasis on theintroduction of our crowdsensing based publictransport information service, what we have beendeveloping as a prototype smart city application.The front-end interface of this service is calledTrafficInfo. It is a simple and easy-to-useAndroid application which visualizes real-timepublic transport information of the given city onGoogle Maps. The lively updates of transportschedule information relies on the automatic stopevent detection of public transport vehicles. Traf-ficInfo is built upon our Extensible Messagingand Presence Protocol (XMPP) based communi-cation framework what we designed to facilitatethe development of crowd assisted smart cityapplications. The paper introduces shortly thisframework, than describes TrafficInfo in detailtogether with the developed stop event detector.

SISTER SOCIETY PAPER

Karoly Farkas, Gabor Feher, Andras Benczur, and Csaba Sidlo

Crowdsending Based Public TransportInformation Service in Smart Cities

Editor’s Note: The IEEE CommunicationsSociety has a Sister Society agreement with HTE(The Hungarian Association for Infocommunica-tions). The terms of the agreement include re-publication of articles of HTE’s Infocommuni-cations Journal in IEEE Communications Societypublications. The article below has alreadyappeared in Infocommunications Journal. Thecitation is: Infocommunications Journal, no 4, pp.13–20, Dec. 2014

Osman Gebizlioglu, Editor-in-Chief, IEEECommunications Magazine

FARKAS_LAYOUT_Author Layout 7/29/15 4:54 PM Page 158

IEEE Communications Magazine • August 2015 159

publish/subscribe (pub/sub) communication modelthe passengers subscribe in TrafficInfo, accordingto their interest, to traffic information channelsdedicated to different public transport lines orstops. Hence, they are informed about the livepublic transport situation, such as the actual vehi-cle positions, deviation from the static timetable,crowdedness information, etc.

To motivate user participation in data collec-tion we offer a day zero service to the passengers,which is a static public transportation timetable. Itis built on the General Transit Feed Specification(GTFS, designed by Google) [4] based transitschedule data and provided by public transportoperators. TrafficInfo basically presents this statictimetable information to the users which is updat-ed in real-time, if appropriate crowdsensed data isavailable. To this end, the application collectsposition data; the timestamped halt events of thepublic transport vehicles at the stops; and/or sim-ple annotation data entered by the user, such asreports on crowdedness or damaged seat/win-dow/lamp/etc. After analyzing the data gatheredlive updates are generated and TrafficInforefreshes the static information with them.

The rest of the paper is structured as follows.After a quick overview of related work we intro-duce our generic framework to facilitate thedevelopment of crowdsourcing based services.We show our live public transport informationservice together with the developed stop eventdetector. Finally, we summarize our work with ashort insight to our future plans.

RELATED WORKIn this section, we discuss the challenge ofattracting users to participate in crowdsensingand review the relevant works in the field ofcrowd assisted transit tracking systems.

A crowdsourcing based service has to acquirethe necessary information from its users who areproducers and consumers at the same time. There-fore it is essential for the service provider to attractusers. However, we face a vicious circle here. Theusers are joining the service if they can benefitfrom it and at the same time they contribute tokeep running the service which can persuade oth-ers also to join. But how can the users be attractedif the service is not able to provide the expectedservice level due to the lack of contributors? Thisalso means that the service cannot be widely spreadwithout offering a minimum service level and untilit has a sufficiently large user base.

Moovit2 is a similar application to TrafficInfowhich is meant to be a live transit app on themarket providing real-time information aboutpublic transportation. It faces the above men-tioned problem in many countries. Moovit hasbeen successful only in those cities where it hasalready a mass of users, just like in Paris, and notsuccessful in cities where its user base is low, e.g.,in Budapest. In order to create a sufficientlylarge user base Moovit provides, besides livedata, schedule based public transportation infor-mation as a day zero service, too. The source ofthis information is the company who operates thepublic transportation network. The best practiceis for providing such information is using GTFS[4]. According to the GTFS developer page, cur-

rently 263 public transportation companies pro-vide transit feeds from all over the world. Moovitpartially relies on GTFS and is available in 350cities attracting more than 6.5 million users. Wealso adopted this solution in TrafficInfo.

Several other mobile crowdsensing basedtransit tracking ideas have been publishedrecently. For instance, the authors in [5] proposea bus arrival time prediction system based onbus passengers' participatory sensing. The pro-posed system uses movement statuses, audiorecordings and mobile celltower signals to iden-tify the vehicle and its actual position. Theauthors in [6] propose a method for transittracking using the collected data of theaccelerometer and the GPS sensor on the users'smartphone. The authors in [7] use smartphonesensors data and machine learning techniques todetect motion type, e.g., traveling by train or bycar. EasyTracker [8] provides a low cost solutionfor automatic real-time transit tracking and map-ping based on GPS sensor data gathered frommobile phones which are placed in transit vehi-cles. It offers arrival time prediction, as well.

These approaches focus on the data (what tocollect, how to collect, what to do with the data)to offer enriched services to the users. However,our focus is on how to introduce such enrichedservices incrementally, i.e., how can we create anarchitecture and service model, which allowsincremental introduction of live updates fromparticipatory users over static services that areavailable in competing approaches. Thus, ourapproach complements the above ones.

FRAMEWORK FOR CROWDSENSINGBASED SMART CITY APPLICATIONS

In this section, we shortly describe our genericframework [3], which is based on the XMPPpublish-subscribe architecture, to aid the devel-opment of crowdsensing based smart city appli-cations. TrafficInfo is implemented on top ofthis framework.

2 http://www.moovitapp.com

Figure 1. Real-time public transport information service based on mobilecrowdsensing.

GTFS database

Service provider

Passengers

Real-time transitfeed service


IEEE Communications Magazine • August 2015160

COMMUNICATION MODEL

XMPP [2] is an open technology for real-time com-munication using Extensible Markup Language(XML) [9] message format. XMPP allows sendingof small information pieces from one entity toanother in quasi real-time. It has several extensions,like multi-party messaging [10] or the notificationservice [11]. The latter realizes a publish/subscribe(pub/sub) communication model [12], where publi-cations sent to a node are automatically multicastto the subscribers of that node. This pub/sub com-munication scheme fits well with most of the mobilecrowdsensing based applications. In these applica-tions, the users' mobile devices are used to collectdata about the environment (publish) and the usersconsume the services updated on the basis of thecollected data (subscribe).

Hence, we use XMPP and its generic pub-lish/subscribe communication model in ourframework to implement interactions. In thismodel, we define three roles, like Producer, Con-sumer and Service Provider (Fig. 2). These enti-ties interact with each other via the core service,which consists of event based pub/sub nodes.

Producer: The Producer acts as the originalinformation source in our model producing rawdata streams and plays a central role in data col-lection. He is the user who contributes hismobile's sensor data.

Consumer: The Consumer is the beneficiaryof the provided service(s). He enjoys the value

of the collected, cleaned, analyzed, extended anddisseminated information. We call the user asProsumer, when he acts in the service as bothConsumer and Producer at the same time.

Service Provider: The Service Provider intro-duces added value to the raw data collected bythe crowd. Thus, he intercepts and extends theinformation flow between Producers and Con-sumers. A Service Provider can play several rolesat the same time, as he collects (Consumer role),stores and analyzes Producers' data to offer(Service Provider role) value added service.

In our model, depicted in Fig. 2, Producersare the source of original data by sensing andmonitoring their environment. They publish(marked by arrows with empty arrowhead) thecollected information to event nodes (raw infor-mation nodes are marked by blue dots). On theother hand, Service Providers intercept the col-lected data by subscribing (marked by arrowswith black arrowhead) to raw event nodes andreceiving information in an asynchronous man-ner. They extend the crowdsensed data with theirown information or extract cleaned-up informa-tion from the raw data to introduce added valueto Consumers. Moreover, they publish their ser-vice to different content nodes. Consumers whoare interested in the reception of the addedvalue/service just subscribe to the appropriatecontent node(s) and collect the published infor-mation also in an asynchronous manner.

ARCHITECTUREWe can directly map this model to the XMPPpublish/subscribe service model as follows (Fig. 3):• Service Providers establish raw pub/sub data

nodes, which gather Producers' data, for theservices they offer.

• Consumers can freely publish their collecteddata to the corresponding nodes withappropriate node access rights, too. Howev-er, only the owner or other affiliated Con-sumers can retrieve this information.

• Producers can publish the collected data ortheir annotations to the raw data nodes atthe XMPP server only if they have appro-priate access rights.

• Service Providers collect the published dataand introduce such a service structure fortheir added value via the pub/sub subscrip-tion service, which makes appropriate con-tent filtering possible for their Consumers.

• Prosumers publish their sensor readings orannotations into and retrieve events fromXMPP pub/sub nodes.

• Service Providers subscribed to raw pub/subnodes collect, store, clean-up and analyzedata and extract/derive new informationintroducing added value. This new informa-tion is published into pub/sub nodes on theother side following a suitable structure.The pub/sub service node structure can benefit

from the aggregation feature of XMPP via usingcollection nodes, where a collection node will seeall the information received by its child nodes.Note, however, that the aggregation mechanismof an XMPP collection node is not appropriate tofilter events. Hence, the Service Provider role hasto be applied to implement scalable contentaggregation. Figure 3 shows XMPP aggregations

Figure 2. Crowdsensing model based on publish/subscribe communication.

Subscribe

Subscribe

Raw information nodes Value added information nodes

Publish Publish

Event service

Service providerService provider

Consumer

Consumer

Consumer

Producer

Producer

Producer

Producer

Figure 3. Mobile crowdsensing: the publish/subscribe value chain usingXMPP.

DB

Serviceprovider

Subscribe

Subscribe

Prosumers = producers/consumers

Raw datanode

Publish

Publish

Contentstructure

Service node

XMPP pub/sub service: topic nodes

Analytics



as dark circles at the container node while emptycircles with dashed lines represent only logicalcontainment where intelligent aggregation isimplemented through the service logic.

REAL-TIME PUBLIC TRANSPORTINFORMATION SERVICE

In this section, we shortly overview the architec-ture of our public transport information service,then describe TrafficInfo, its front-end Androidinterface together with our stop event detector.

SERVICE ARCHITECTUREOur real-time public transport information ser-vice architecture has two main building blocks,such as our crowdsensing framework describedearlier and the TrafficInfo application (Fig. 4).The framework can be divided into two parts, astandard XMPP server and a GTFS Emulatorwith an analytics module.

The XMPP server maps the public transportlines to a hierarchical pub/sub channel structure.We turned the GTFS database into an XMPPpub/sub node hierarchy. This node structurefacilitates searching and selecting transit feedsaccording to user interest.

Transit information and real-time eventupdates are handled in the Trip nodes at the leaflevel. The inner nodes in the node hierarchycontain only persistent data and references rele-vant to the trips. The users can access the transitdata via two ways, based on routes or stops .When the user wants to see a given trip (vehicle)related traffic information the route based filter-ing is applied. On the other hand, when theforthcoming arrivals at a given stop (location)are of interest the stop based filtering is theappropriate access way.

The GTFS Emulator provides the statictimetable information, if it is available, as the ini-tial service. It basically uses the officially distribut-ed GTFS database of the public transportoperator of the given city. However, it also relieson another data source, which is OpenStreetMap(OSM), a crowdsourcing based mapping service[13]. In OSM maps, users have the possibility todefine terminals, public transportation stops oreven public transportation routes. Thus, the OSMbased information is used to extend and clean theinformation coming from the GTFS source. Theanalytics module is in charge of the business logicoffered by the service, e.g., deriving crowdednessinformation or estimating the time of arrivals atthe stops from the data collected by the crowd.

TrafficInfo handles the subscription to thepub/sub channels, collects sensor readings, publish-es events to and receives updates from the XMPPserver, and visualizes the received information.

TRAFFICINFO FEATURESTrafficInfo has three main features, but most ofthe users will benefit from its visualization capa-bility that visualizes public transport vehiclemovements on a city map.

1) Visualization: An example of this primaryfeature can be seen on Fig. 5a displaying trams1, 4, 6 and buses 7 and 86 on the Budapest mapin Hungary. The depicted vehicles can be fil-

tered to given routes. The icon of a vehicle mayreflect various attributes, such as the number,progress or crowdedness of the specific vehicle.Clicking on a vehicle's icon a popup shows allknown information about that specific vehicle.

2) Information Sharing: The second feature isabout information sharing. Passengers can sharetheir observations regarding the vehicles they arecurrently riding. Figure 5b shows the feedbackscreen that is used to submit the observations. Thefeedback information is spread out using ourcrowdsourcing framework and displayed on thedevices of other passengers, who might be inter-ested in it. It is up to the user what informationand when he wants to submit, but we are planningto provide incentives to use this feature frequently.

3) Sensing: The third feature is collecting smart-phone sensor readings without user interaction,which is almost invisible for the user. User posi-tions are reported periodically and are used todetermine the vehicle's position the passenger isactually traveling on. In order to create the linkbetween the passenger and the vehicle, we try toidentify the movement of the user through hisactivities. To this end we are using various sensors,e.g., accelerometer, and try to deduct the times-tamped stop events of the vehicles (our automaticstop event detection mechanism is described earli-er). The duration between the detected stops cou-pled with GPS coordinates identifies the routesegment, which the user actually rides.

Besides the GPS coordinates Google also pro-vides location information on those areas, wherethere is no GPS signal. Usually this position ishighly inaccurate, but the estimated accuracy isalso provided. We also use the activity sensor,which guesses the actual activity of the user. Cur-rently, the supported activities are: in vehicle, onbicycle, on foot, running, still, tilting, walking andunknown. Accuracy is provided here, as well.

The collected sensor readings, on one hand,are uploaded to the XMPP server, where theanalytics module processes and shares themamong parties who are subscribers of the rele-vant information; on the other hand, are usedlocally. For example, user activity is analyzed onthe server side and it is used to create non real-time stop patterns through machine learning.

Figure 4. Real-time public transport information service architecture.

Route B

Subscribe

Subscribe

GTFS database

Transit feed analytics

Live events

Reference

AgencyGuidingcontents

Rawdatanode

XMPPserver

Publish

Participatory usersrunning TrafficInfo

Trip 2

Out

GTFSemulator and

analyticsRoutes

Stop B

Route B

Route A

Stop A

Stops

In

Trip 2

Route A



These patterns are delivered back to the applica-tion, where further local analytics can use themfor, e.g., identifying the vehicle and providingposition information. These sensor data flowsare depicted in Fig. 6. Note that, at the moment,stop events are detected locally on the devicedue to resource usage reasons and only thedetected events with a timestamp are reportedback to the server. Based on this information theserver side analytics estimate the upcomingarrival times of the given vehicle and dissemi-nate live timetable updates to the subscribers.

SERVICE LEVELSRunning TrafficInfo in a small city is differentthan in big cities, like Budapest. The cause ofthis difference is the unavailability of static pub-

lic transportation information in, e.g., GTFS for-mat. If even the static public transportationschedule is not presented by the application,people will likely not use it. Furthermore, fewerusers will generate less live traffic data whichmakes the whole application useless. Hence, it isclear that we should apply a different approachin cities where static public transportation infor-mation has not been available, yet.

1) City Explorer: In a new city, at the begin-ning we assume that there is zero knowledge inour system about the city's public transportation.The goal is to gather the relevant information ina fast and inexpensive way. When a reliableGTFS or OSM information base of the given cityis available, we import this data into our databas-es. In other situations, we use crowdsourcing togather this information. We assume that someusers will install the TrafficInfo application eitherto contribute to city exploration or just simply forcuriosity (or some incentive mechanism has to beintroduced to grab users). We expect no othercontributions than installing the application, car-rying the smartphone during the day, traveling onpublic transportation and answering some simplequestions asked by the application. The smart-phones, using their built-in sensors, collect all thenecessary data without user interaction. Thequestions are used to annotate the collected data.

Every day the captured data is uploaded in abatch to the server for analysis. At the sametime, the application downloads informationabout what to ask on the following day(s).

Figure 8 depicts an uploaded activity log of aparticular user. In this example, the informationsource is the Google activity recognition modulementioned above. The blue bars show the detect-ed activity during the capture time. In addition,another sensor module recorded the motion, too.Its output is the red bars, recognizing only still ormoving states. The height of the bars expressesthe confidence of the recognition. Although thevalues represented with blue and red bars arecoming from two different sensors, they usuallyhave the same results for the still state. There areonly a few differences, where the activity recogni-tion shows unknown event, while the motion sen-sor signals still state. It is not displayed on thefigure, but the GPS position and its accuracy arealso logged for every event.

The captured logs are processed by the serverduring the night, when the users are typicallyinactive and the system tries to guess the publictransport stops and routes in the city. The moreusers report the same information the higher thechance is to guess the transportation system cor-rectly. A database stores all the possible stoplocations together with their confidence. Thisdatabase is then downloaded to the applicationwhich will ask simple questions to the users toidentify stops. For instance, the applicationmight ask: “Are you standing at a stop, waiting forpublic transport?” We expect simple answers forsimple questions until we can construct the pub-lic transportation stop database. Routes areexplored in a similar way. When the user travelsbetween already known stops, we assume thatthere is a public transport route among thesestops. The application might ask the user aboutthe route type and the line number.

Figure 5. TrafficInfo screenshots: a) vehicle visualization; b) user feedbackform.

(a) (b)

+

–

Figure 6. Sensor data flows in TrafficInfo.

XMPP

Nonreal-timesensordatadump

Non real-time stoppatterns

Real-time vehicle position

XMPP

HTT

P

Service

HTT

P

TrafficInfoTrafficInfo

Activitysensor /

acc. meter

Identify vehicle

Identify position

GPS /locationsensor

Localanalytics

Stopanalytics

Real-timevehicleposition



2) Schedule (Re)Construction: Once the publictransportation stops and routes are explored inmost parts of the city, we can assume with highconfidence that more users join and use theapplication. Visualizing stops and routes aidsusers to get orientation. However, the explo-ration of the city is continuing, the sensor read-ings are always collected, but questions are askedonly regarding to the partially explored areas.

When the number of users exceeds a certainlevel and the trips can be guessed, the automaticdetection of the stop events comes into the pic-ture. The detected events are reported to theserver by the application. The server filters thisdata and analyzes the patterns of each transportline. As more stop events are captured the pat-terns are more complete and finally the publictransportation schedule is constructed.

3) Live Schedule: TrafficInfo providing publictransportation stops, routes and schedules isassumed to attract many users, similarly to thoseapplications that are available in big cities based onGTFS data. One advantage of TrafficInfo is that itprovides an alternative way to collect all necessaryinformation from scratch which does not requirethe cooperation of the public transport operatorcompany, rather relies on the power of the crowd.

When the number of users is high enoughand (static) schedule information is available,the continuously collected position and stopevent data is used to create and propagate livelyupdates. These updates refresh the timetable ifnecessary and reflect the actual public transporttraffic conditions.

4) Information Sharing on Public TransportConditions: On-line users are able to send andreceive information about the vehicle's conditionsthey are actually riding. This requires user inter-action on a voluntary basis as current sensors arenot able to detect crowdedness, torn seats, baddrivers, etc. If the application has a wide userbase we can always expect some volunteers toreport on such conditions. The application pro-vides easy to use forms to enter the relevant data.

5) Additional Services: When TrafficInfo isrunning in a full-fledged manner, it can cooper-ate with other services targeting public trans-portation. For example, a rendezvous service canbe paired to the TrafficInfo application to orga-nize dates on public transportation vehicles.

STOP EVENT DETECTIONOne of the fundamental functions of TrafficInfo isto detect stop events of public transport vehicles.We implemented such a detector locally on themobile device. The reason behind that is twofold.First, cheaper devices produce bogus raw GPSlocation data that, if directly transmitted to theXMPP server, would mislead the service. Second,raw logs are generated at a very high rate and itwould cause a substantial burden to transmit theraw logged data to the server in real-time for fur-ther processing. Instead, only when stop events aredetected a summary of information, e.g., thetimestamp of the event and the time elapsed sincethe last stop event, will be transmitted.

To illustrate the challenge of stop event detec-tion, we show the logged trajectory on tram routes4 and 6 in Budapest from two devices, a SamsungGalaxy S3 and a Nexus4 smartphone, in Fig. 9

and Fig. 10, respectively. In case of Nexus4 (Fig.10), yellow dots indicate the predicted locationsof the stop events. Note that Nexus4 with networkinformation provides correct position data, similarin quality to the Galaxy S3 device. Unfortunately,we were not able to collect GPS position datafrom all the devices we used in our experimentseven if the device was equipped with GPS sensor.

Our solution for stop event detection is basedon features. Hence, we generated several featuresfrom the experimental usage logs collected duringthe testing period. The measurement object weused to collect context data is summarized inTable 1. It includes among others GPS, WiFi,network and acceleration sensor readings, etc.

The features we defined are the following:• Latitude, Longitude: raw GPS data;• AccAbsMax and AccAbsMin: maximum and

minimum value of acceleration in the past20 seconds;

• Last Annotation Time: in seconds, depend-ing on the annotation type (Stopped at Sta-tion or Leaving Stop);

• Closest Station: distance calculated fromraw GPS data;

• GPS Distance: distance traveled during thelast 20 seconds based on raw GPS data.We collected Android sensor and location

data by using the Android Location API.3 Thedevice can have multiple LocationProvider sub-

Figure 7. Service levels vs. user base.

Explore the city

Construct schedules

Live schedules

Traffic information sharing

Additional services

Figure 8. Captured sensor data during user activity.

walking

in vehicle

on bicycleon bicycle

on footrunning

still

still

moving

tiltingunknown

16:00 17:0016:5516:5016:4516:4016:3516:3016:2516:2016:1516:1016:05

Time



classes based on network, GPS and passive sen-sors, and the location manager has a method toselect the best provider. Accessing the sensorsrequires three level permissions:A C C E S S _ F I N E _ L O C A T I O N ,ACCESS_COARSE_LOCATION, INTERNET.The GPS sensor can be accessed by the NMEAlistener.4 Accelerometer is accessible throughthe Google Location Services API, part ofGoogle Play Services, a high level frameworkthat automates the location provider choice.

For classification we used the J48 decisiontree implementation of the Weka data miningtool.5 The final output of our detector is thedetected stop event, including location andtimestamp. With the combination of the definedfeatures and models we could detect stop eventswith high accuracy within 13 seconds after thearrival at the station.

We measure the accuracy of the method bycomputing the precision, recall and AUC (AreaUnder the Curve) [14] of our classifiers in a 10-fold crossvalidation setting. We consider AUC asthe main stable measure for classifier perfor-mance that does not depend on the decisionthreshold separating the predicted stop events.The best classifier reached precision 0.97, recall0.95, F-measure 0.96. The corresponding bestAUC was 0.86, which means that a random timepoint when the tram is at a stop is predicted 86%more likely a stop than another random timepoint when the tram is in between two stops. Ingeneral, an AUC between 0.8-0.9 is considered inthe literature to be good to excellent.

SUMMARYIn this paper, we shortly introduced our XMPPbased communication framework that wedesigned to facilitate the development of crowdassisted smart city applications. Then we pre-sented our crowdsensing based real-time publictransport information service, implemented ontop of our framework, and its front-end Androidapplication, called TrafficInfo, in detail togetherwith our stop event detector. This detector wasdeveloped to automatically detect halt events ofpublic transport vehicles at the stops.

As future work, we plan to develop TrafficIn-fo further and enhance the different services ofall the introduced service levels. Moreover, weintend to recruit a noticeable user base andcarry out field experiments with these real users.Their feedback is important to plan the direc-tions for improvements.

ACKNOWLEDGMENTThe publication was supported by the

TÁMOP-4.2.2.C-11/1/KONV-2012-0001 project.Károly Farkas has been partially supported bythe Hungarian Academy of Sciences through theBolyai János Research Fellowship.

Figure 9. GPS position trajectory (blue) and the real tram route (red) aslogged by a Samsung Galaxy S3 device.

Figure 10. GPS position trajectory (blue), the real tram route (red) andstops (yellow dots) as logged and detected by a Nexus4 device.

3 http://developer.android.com/guide/topics/sensors/index.html

4 https://developer.android.com/reference/android/location/GpsStatus.NmeaListener.html

5 http://www.cs.waikato.ac.nz/ml/weka/



REFERENCES[1] R. Ganti, F. Ye, and H. Lei, “Mobile Crowdsensing: Cur-

rent State and Future Challenges,” IEEE Commun.Mag., Nov. 2011, pp. 32–39.

[2] P. Saint-Andre, “Extensible Messaging and PresenceProtocol (XMPP): Core,” RFC 6120 (Proposed Standard),Internet Engineering Task Force, Mar. 2011,http://www.ietf.org/rfc/rfc6120.txt.

[3] R. L. Szabo and K. Farkas, “A Publish-Subscribe SchemeBased Open Architecture for Crowd-Sourcing,” Proc.19th EUNICE Wksp. Advances in Communication Net-working (EUNICE 2013), Springer, Aug. 2013, pp. 1–5.

[4] Google Inc., General Transit Feed Specification Reference,https://developers.google.com/transit/gtfs/reference/.

[5] P. Zhou et al., “How Long to Wait?: Predicting BusArrival Time with Mobile Phone based ParticipatorySensing,” Proc. 10th Int’l. Conf. Mobile Systems, Appli-cations, and Services (MobiSys 2012), June 2012,

[6] A. Thiagarajan et al., “Cooperative Transit TrackingUsing Smart-phones,” Proc. 8th ACM Conf. EmbeddedNetworked Sensor Systems (SenSys 2010), 2010, Nov.2010, pp. 85–98.

[7] L. Bedogni, M. Di Felice, and L. Bononi, “By Train or byCar? Detecting the User's Motion Type Through Smart-phone Sensors Data,” Proc. IFIP Wireless Days Conf.(WD 2012), 2012, pp. 1–6.

[8] J. Biagioni et al., “EasyTracker: Automatic Transit Track-ing, Mapping, and Arrival Time Prediction Using Smart-phones,” Proc. 9th ACM Conf. Embedded NetworkedSensor Systems (SenSys 2011), pp. 1–14.

[9] T. Bray et al., Extensible Markup Language (XML) 1.0(Fifth Edition), W3C, W3C Recommendation REC-xml-20081126, Nov. 2008, http://www.w3.org/TR/2008/REC-xml-20081126/.

[10] P. Saint-Andre, “XEP-0045: Multi-User Chat,” XMPPStandards Foundation, Standards Track XEP-0045, Feb.2012, http://xmpp.org/extensions/xep-0045.html.

[11] P. Millard, P. Saint-Andre and R. Meijer, “XEP-0060:Publish-Subscribe,” XMPP Standards Foundation, DraftStandard XEP-0060, July 2010, http://xmpp.org/exten-sions/xep-0060.html.

[12] P. Eugster et al., “The Many Faces of Publish/Sub-scribe,” ACM Comput. Surv., vol. 35, no. 2, June 2013,pp. 114–31.

[13] M. Haklay and P. Weber, “ OpenStreetMap: User-Gen-erated Street Maps,” IEEE Pervasive Computing, Oct.2008, http://dx.doi.org/10.1109/MPRV.2008.80.

[14] J. Fogarty et al., “Case Studies in the Use of ROC CurveAnalysis for Sensor-based Estimates in Human ComputerInteraction,” Proc. Graphics Interface 2005, ser. GI ‘05,School of Computer Science, University of Waterloo,Waterloo, Ontario, Canada: Canadian Human-ComputerCommunications Society, 2005, http://portal.acm.org/citation.cfm?id=1089508.1089530, pp. 129–36.

BIOGRAPHIESKÁROLY FARKAS ([email protected]) received his Ph.D. degreein Computer Science in 2007 from ETH Zurich, Switzerland,and his M.Sc. degree in Computer Science in 1998 from theBudapest University of Technology and Economics (BME),Hungary. Currently he is working as an associate professor atBME. His research interests cover the field of communicationnetworks, especially autonomic, self-organized, wireless andmobile ad hoc networks, and mobile crowdsourcing. He haspublished more than 70 scientific papers in different journals,conferences and workshops and he has given a plenty of reg-ular and invited talks. In the years past, he supervised a num-ber of student theses and coordinated or participated inseveral national and international research projects, such asCityCrowdSource of EIT ICTLabs. Moreover, he acted as pro-gram committee member, reviewer and organizer of numer-ous scientific conferences, thus he took the general co-chairrole of the IEEE PerCom 2014 conference and the TPC co-chair role of the CROWDSENSING 2014 and the CASPer 2015workshops. He is the coordinator of the local Cisco Network-ing Academy and was the founding initiator of the Cisco IPv6Training Laboratory and the BME NetSkills Challenge studentcompetition at BME. Between 2012–2015 he has beenawarded the Bolyai János Research Fellowship of the Hungar-ian Academy of Sciences, and received the Gold Medal andPollák-Virág awards of HTE (Scientific Association for Info-communications Hungary) in 2015.

GÁBOR FEHÉR graduated in 1998 at the Budapest Universityof Technology and Economics on the Faculty of Electronic

Engineering and Informatics. In 2004 he received a PhD.degree, the topic of his thesis was resource control in IPnetworks. Currently he is an associate professor at thesame university. Besides giving lectures, he is also con-tributing to various national and international researchprojects. From 2004 he is continuously involved in threeconsecutive EU founded IST/ICT projects. He has teachingactivity on the faculty's Smart City specialization workingwith microelectronics, sensor networks and smartphones.He and his students are working on more projects withcrowdsouring and crowdsensing, from the basic researchup to the prototype applications.

ANDRÁS BENCZÜR received his Ph.D. at the Massachusetts Insti-tute of Technology in 1997. Since then his interest turned toData Science. He is the head of 30 doctoral students, post-docs and developers at the Institute for Computer Scienceand Control of the Hungarian Academy of Sciences (SZTAKI).He is site coordinator in the Hungarian FutureICT project,and cloud computing activity leader in the Budapest node ofEIT ICTLabs. He serves on the program committees of lead-ing conferences including WWW, WSDM, ECML/PKDD, hewas Workshop Chair for WWW 2009 and main organizer ofthe ECML/PKDD Discovery Challenge 2010. In 2012 he wasawarded the Momentum grant of the Hungarian Academyof Sciences for his research in Big Data.

CSABA SIDLÓ started working on data warehousing projectsand application driven research problems of extremely largedata sets in 2000. He joined the Institute for Computer Sci-ence and Control of the Hungarian Academy of Sciences(SZTAKI) in 2004; he is now head of the Big Data BusinessIntelligence research group. His main interest is Big Dataanalytics and business intelligence on scalable distributedarchitectures. His industrial projects include master dataentity resolution, integration and analytics of log, web andlocation data. He is currently involved in several big dataprojects for web, telecom and sensor data analytics. Heauthored several research papers and book chapters, andhas a Ph.D. in Informatics from Eötvös University, Hungary.

Table 1. Semantics of TrafficInfo measurement logs.

Field description Examples, possible values

Event type Initialization, manual, sensor

Timestamp Time when the event occurred

Track (tram, bus line) Tram 6

Phone type E.g., Nexus4 including IMEI

Acceleration Absolute or axes X, Y, and Z

GSM signal strength As defined in the relevant standard

Android GPS, network, andpassive location accuracy, longitude and latitude values

Android GPS Location Provider data,accuracy radius with 68% confidence

CellID, WiFi MACID LAC (location area code) and CID (Cell ID)

Vehicle number ID of the transport vehicle

Direction Onward or backward

Arrived at Time of arrival at the stop

Manual input

–Stopped at station–Revoke stopped at station–Leaving stop–Revoke leaving stop–Stopped at traffic light–Revoke stopped at traffic light–Revoke last input


Documents

ansport Information Service in Smart Citiesreal.mtak.hu/26081/1/ComMag_paper_published_Aug_2015_u.pdf · garian Academy of Sci-ences (MTA SZTAKI), Budapest, Hungary 1 We use the terms