Implementation and evaluation of

Space Time Alarm Clock

Adrian Corneliu Prelipcean

Master of Science Thesis in Geoinformatics

TRITA-GIT EX 14-007

School of Architecture and the Built Environment

Royal Institute of Technology (KTH)

Stockholm, Sweden

June 2014

Abstract

Many modern mobile communication devices are equipped with a GPS receiver and anavigation tool. These devices are useful when a user seeks to reach a specified desti-nation as soon as possible, but may not be so when he/she only needs to arrive at thedestination in time and wants to focus on some activities on the way. To deal with thislatter situation, a method and device called “Space Time Alarm Clock” is presented forhelping the user reach the destination by a specified deadline and inform the user aboutthe consequences of his/her decisions. It does so by continuously and efficiently comput-ing how much more time the user may stay at his/her current location without failing toreach the destination by the deadline. Furthermore, it determines the possible movementchoices that a user can make with regards to an underlying road network, it computesthe shortest travel time associated with each choice and informs the user about the con-sequences of his/her decisions. Advantage of this approach is that it works completelyin the background so that the user‘s en-route activities will never be interfered with. The“Space Time Alarm Clock” was implemented for Stockholm, where it was tested.

Keywords: shortest path tree, location based services, shortest travel time, map matching,labeling systems, alarm scheduling.

AcknowledgmentsI would like to thank my supervisors, Takeshi Shirabe and Falko Schmid for their relent-less support, guidance and constructive feedback.

This project is partially supported by the German Research Foundation (DFG) throughthe Collaborate Research Center SFB/TR 8, the European Union Seventh FrameworkProgramme — Marie Curie Actions, Initial Training Network GEOCROWD (grant agree-ment No. FP7-PEOPLE-2010-ITN-264994).

1

Contents1 Introduction 7

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Location Based Services . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Route improvisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Research questions and Objectives . . . . . . . . . . . . . . . . . . . . . 10

2 Methods 112.1 Assumptions and data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Computational steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Destination and deadline specification . . . . . . . . . . . . . . . 132.3.2 Shortest travel time computation . . . . . . . . . . . . . . . . . . 132.3.3 Location Detection . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.4 Earliest arrival time estimation . . . . . . . . . . . . . . . . . . . 152.3.5 Consequence values computation . . . . . . . . . . . . . . . . . 152.3.6 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Implementation 173.1 General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Server-side Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Client-side Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Evaluation 234.1 Server side performance evaluation . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Processing time for generating the ellipse . . . . . . . . . . . . . 234.1.2 Processing time for finding the closest node to the destination . . 244.1.3 Processing time for extracting the subnetwork within the ellipse . 244.1.4 Number of nodes generated by the subnetwork extraction . . . . . 254.1.5 Processing time for computing the shortest path tree . . . . . . . 264.1.6 Total processing time for the server side . . . . . . . . . . . . . . 274.1.7 Number of edges sent to the client . . . . . . . . . . . . . . . . . 27

4.2 Client side performance evaluation . . . . . . . . . . . . . . . . . . . . . 294.2.1 Processing time for reading the subnetwork sent by the server . . 294.2.2 Processing time for building the topology of the subnetwork . . . 304.2.3 Processing time for building the indexes . . . . . . . . . . . . . . 304.2.4 Total computation time for the client side . . . . . . . . . . . . . 31

4.3 Overall waiting time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4.1 Questionnaire design . . . . . . . . . . . . . . . . . . . . . . . . 334.4.2 Collected questionnaires . . . . . . . . . . . . . . . . . . . . . . 34

2

5 Conclusions and Future Work 365.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

References 39

Appendix A: SQL statements 44

Appendix B: Considered origins and destinations 46

Appendix C: Performance measurements 47

Appendix D: osm2pgrouting mapconfig file 56

3

List of Figures1 Components of space time alarm clock . . . . . . . . . . . . . . . . . . . 122 Computational steps of space time alarm clock . . . . . . . . . . . . . . 123 Location detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Earliest arrival time estimation . . . . . . . . . . . . . . . . . . . . . . . 155 Conceptual design of the labeling system . . . . . . . . . . . . . . . . . 166 STAC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Ellipse used to extract the relevant subnetwork . . . . . . . . . . . . . . . 188 Shortest path tree on relevant subnetwork . . . . . . . . . . . . . . . . . 199 Destination and deadline specification . . . . . . . . . . . . . . . . . . . 2010 Labels implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2111 Performance measurements for the subnetwork extraction . . . . . . . . . 2412 Number of nodes generated by the subnetwork extraction . . . . . . . . . 2513 Performance measurements for computing the shortest path tree . . . . . 2614 Number of edges sent to the client . . . . . . . . . . . . . . . . . . . . . 2815 Processing time for reading the subnetwork sent by the server. . . . . . . 2916 Processing time for building the topology of the subnetwork. . . . . . . . 3017 Processing time for building the indexes. . . . . . . . . . . . . . . . . . . 3018 Total processing time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4

List of Tables1 Processing time for subnetwork extraction - the effect of the distance

between origin and destination . . . . . . . . . . . . . . . . . . . . . . . 252 Number of nodes generated by the subnetwork extraction - the effect of

the distance between origin and destination . . . . . . . . . . . . . . . . 263 Shortest path tree computation - the effect of the distance between origin

and destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Total processing time for the server side . . . . . . . . . . . . . . . . . . 275 Number of edges sent to the client - the effect of the distance between

origin and destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Overall waiting time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Origins and destinations used in performance tests . . . . . . . . . . . . . 468 Performance measurements for computing the ellipse . . . . . . . . . . . 479 Performance measurements for finding the closest node to the destination 4810 Performance measurements for extracting the subnetwork . . . . . . . . . 4911 Performance measurements for running the shortest path tree algorithm . 5012 Performance measurements for total computation time on the server . . . 5113 Measurements to determine the effect of the available time and distance

between origin and destination on the number of nodes in the subnetwork 5214 Measurements to determine the effect of the available time and distance

between origin and destination on the number of edges sent to the client . 5315 Performance measurements for reading the server’s response and gener-

ating the network topology . . . . . . . . . . . . . . . . . . . . . . . . . 5416 Performance measurements for building the indexes and total computa-

tion time on the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5

List of Acronyms and Abbreviationsam Ante Meridiem (before midday)

CPU Central Processing Unit

DBMS Database Management System

GIS Geographic Information Systems

GPS Global Positioning System

GSM Global System for Mobile Communications

GUI Graphical User Interface

h hour

JSON JavaScript Object Notation

KTH Kungliga Tekniska Hogskolan

LBS Location Based Services

m meter

ms millisecond

OSM OpenStreetMap

OSciM OpenScienceMap

pm Post Meridiem (after midday)

PL/pgSQL SQL Procedural Language

RAM Random Access Memory

s second

STAC Space Time Alarm Clock

SQL Structured Query Language

WiFi Wireless Fidelity

6

1 Introduction

1.1 MotivationIt is almost unthinkable but what would our modern life be like without clocks? Everymorning we would wake up unsure if we are going to make the first shift of work. Ata station we would wait for a next train without knowing when it comes. Soon afterlunch we would already start thinking about when we call it a day to go to pick upchildren from school. Actually, all these might be unnecessary worries because noneof us (including our employers, train companies, and schools) would have the sense ofpunctuality. Of course, our circadian rhythms or environmental conditions could still tellus approximately where we are in the day. However, it would be impossible to scheduleour daily activities as precisely as we do. Here is a naıve question: will a time comewhen we wonder how we could live without knowing our exact location (not just time)?Maybe.

In the era when highly precise and accurate measurements of location and time areavailable to (almost) anyone anytime anywhere, what is a spatio-temporal counterpart tothe alarm clock? To answer this, let us put ourselves in a somewhat familiar situation: weneed to leave a hotel room for a university auditorium to give a talk at 10:00 am. We canstill use the conventional alarm clock, but in this case, we need to do some calculation,because where the activity is performed is not where the alarm sounds. So we estimatehow long it takes from the hotel to the university and back calculate what time we need toleave the hotel, and set the alarm accordingly. Here we can do the travel time estimationmentally or with assistance of mapping and/or navigation software. There are manyonline services that help us find a route and estimate its travel time.

Suppose further that the talk has been postponed to 2:00 pm, so that we have sometime to explore downtown. Then, with the help of the navigation software, can we setthe alarm clock to a right time to stop our exploration? This may not be as easy as in theprevious case (where we are sitting in the hotel room) because we are moving around inthe city, which means that it takes different amounts of time to get to the destination fromdifferent locations, which, in turn, means that the alarm must go off at different times atdifferent locations. Still, if we do not mind to have the navigation software recompute aroute and travel time to the destination every time we change our location (perhaps by aspecified distance or longer, as employed in Abdalla [1]). Unfortunately, this would leadto a dilemma: if the recomputation is done frequently, it would cost an exceedingly largeamount of computing time/resource; otherwise, the travel time might not be computedin a timely manner. In any case, the alarm clock would not work timely or reliably. Itmight be an option to use a system proposed by Shirabe [49], which continuously labelsevery alternative move at the current location with the estimated arrival time. However,this might impose too much cognitive load on the user as these labels must be updatedrapidly and placed on a limited-size screen. As such, the idea of an alarm clock that takesinto account location is interesting but not without limitations.

7

1.2 Location Based ServicesLocation Based Services (LBSes) can be defined as the services that make use of a mo-bile device’s location to derive information whose content is personalized based on a setof preferences and a location (see [25, 47, 52] and see [41] for a more recent overview).LBSes are used in different applications such as: location based reminders [29,31], loca-tion based news [9], augmenting digital content over the physical space [43] and, one ofthe most widely used LBS, navigation systems.

The navigation systems offer aid to a traveler by showing his/her location on a mapand presenting visual and audio direction on how to reach a certain location [50]. Al-though navigation systems were first designed as stand-alone tools that were mainly usedby drivers for obtaining driving directions [2], the advance of location detection tech-nology and mobile computing technology made navigation and other LBSes possible ondevices that are not dedicated to a particular LBS.

These devices are commonly referred to as smartphones and they have the capabilitiesof a regular mobile phone, namely calling and texting, but with more advanced comput-ing capabilities (i.e., processing power and storage size) and connectivity (i.e., the newgenerations of telecommunication - 3G, 4G - and wireless connectivity to wireless net-work - WiFi). Furthermore, most smartphones models are equipped with sensors thathave the capability to retrieve the smartphones location via the network-based position-ing, WiFi-based positioning and/or GPS-based positioning.

The network based positioning system obtains a smartphone’s location by identifyingthe GSM (Global System for Mobile Communications) towers that a smartphone is closeto and triangulate the location based on the known geographical positions of the towersand on the signal intensity at the smartphone’s location. The WiFi-based positioningsystem is similar to the GSM positioning system with the main difference of obtainingthe smartphone’s location based on the intensity of the WiFi signal from a wireless accesspoint. Finally, the GPS positioning system obtains the smartphone’s location based onthe visible satellites∗. The network and WiFi based positioning perform well in cities butcannot be used in remote areas where no GSM towers or WiFi access points are present.The GPS positioning system is available anywhere but fails to work inside buildings (see[3] for an overview of the network-based and GPS-based positioning methods and [57]for an overview of the WiFi-based positioning method and its usage). By using any of theaforementioned techniques, a smartphone that is aware of the user’s location can providerelevant content to a user, which increases the usability of a smartphone.

These devices have been adopted by most people (see [13] for the worldwide situationand [51] for the situation in the United States of America) and 74% of the smartphoneowners use LBSes [58], out of which the most popular LBS is obtaining driving directionsor routing.

∗The minimum number of visible satellites to obtain a location is three.

8

1.3 Route improvisationWayfinding (or routing) has been defined by Golledge [16] as the “process of determiningand following a path between an origin and a destination”. Routing is usually employedwhen the sole objective of the trip is getting to the destination. There are two main typesof routing in commercial systems, namely pedestrian routing and vehicle routing. Whilefrom a computational perspective, these two types of routing are identical, the main dif-ference is how they are used. The routing systems for vehicles needs to present simplifiedinformation to a user because of the speed of the vehicle and the device’s position is usu-ally fixed [2]. The routing system for pedestrians can present more information to userssince their traveling speed allows for short stops without disrupting the traffic [6, 32].Another difference between these two types of routing systems is the network links theuser can travel on (e.g., the highway is accessible to cars and other vehicles but not forpedestrians and paths through parks are accessible for pedestrians but not for vehicles).

Wayfinding and routing algorithms have been extensively studied in computer scienceand artificial intelligence and they supply information regarding shortest the shortest pathbetween an origin and a destination (one-to-one), between an origin and all other nodes(all-to-one or one-to-all) and between all nodes in a network (all to one). Dijkstra’s algo-rithm [11] solves the single source shortest path problem for a graph with positive edgecosts and does so in quadratic time (depends on the number of vertices in the network).Different heuristics have been employed to reduce the computation time, out of which themost common are the branch pruning method [27], which prunes the intermediate nodesthat have little probability of being on the shortest path to the destination mode, and theA* algorithm [20], which assigns a low priority to the nodes that have little probabilityof being on the shortest path. Other approaches [10] use a bi-directional search modethat divides the search problem into two, find the shortest path from the origin to thedestination and from the destination to the origin. This algorithm builds the shortest pathtree from the origin and from the destination and stops when a criterion is met (when thetwo shortest path trees intersect). Another routing problem is finding the simplest routeto the destination, which has been studied extensively by Duckham and Kulik [12, 18].

The algorithms behind popular routing systems such as Google Maps [15] are ei-ther patented, not available for the public or briefly presented in white papers. Whileseveral routing services are built on top of the Google Maps routing engine (e.g., [46]),other routing services employ variations of shortest path one-to-one algorithms (e.g., Os-mAnd [37], Routinho [44]). Most of these services provide both vehicle and pedestriannavigation. However, when using classical approaches to routing, users are supposed todecide which route to take from early on, in the planning stages, and any deviation fromthat path prompts the navigation system to recompute the path.

The concept of route improvisation was introduced by Shirabe [49] to complementthe existing en-route travel assistance by “providing a traveler information on the conse-quence of each possible move where he is and whenever he needs/wants it”. Althoughthe cognitive load might increase when using this procedure, the users are not limited tofollow one path only, as they can see how every decision can affect them/their schedule.

9

Most of the time, a traveler has to reach a destination by a specified time and notas soon as possible. The available time can be translated to a time budget and it canbe integrated into a space time prism, which describes an individual’s physical reach inspace and time [34]. Space-time prisms are a concept specific to time geography, whichallows for the study of the factors that restrict an individual’s choice [21, 35], and it hasbeen used in different research areas such as human activity pattern visualization [28],archeology [33] and migration [22]. Raubal et. al. [42] showed that time geographycan be used together with the “theory of affordances” [14] to customize a sequence ofactivities as subject to spatial and temporal constraints.

1.4 Research questions and ObjectivesWhile the navigation technology has been studied extensively, it was done so under theassumption that the traveler wants to get to the destination as soon as possible and thescenario in which a user desired to explore before getting to the destination has beenignored.

This raises the questions addressed in this study: Is it possible to design a method thatconsiders a destination and a deadline and determines the amount of time left (if any) atany given location so that the destination is reached by the deadline? Is it possible toderive information regarding the time it takes to reach the destination by following anyof the possible moves from a given location? How can this information be presented tosmartphone users and in what situations is it useful? Is it possible to design a compu-tationally non-demanding (with regards to running time and storage space) method thatcan seamlessly provide this information to smartphones?

To answer these questions, we implemented, tested and evaluated a mobile applica-tion that considers a destination and a deadline and communicates to the user the timeleft at the current location together with a labeling system that draws the consequencesof a user’s each possible move on a map. A website was designed for this project,namely [53] http://people.kth.se/˜shirabe/SpaceTimeAlarmClock/STAC.html, where the application was made available for downloading and those whoused the application could fill in a questionnaire designed for this project.

The objective of this research is two fold:

• To explore the possibility of a computationally non-demanding method to deriveinformation related to the time it takes to reach a specified destination by follow-ing any of the possible moves from a given location, and seamlessly provide thisinformation to mobile communication devices such as smartphones.

• To develop a prototype device implementing this method and test its computationalperformance and identify potential bottlenecks.

10

2 MethodsIn view of the problem described above, this thesis proposes an efficient method anddevice, called “Space Time Alarm Clock” (STAC), which has two main functionalities:1) it continuously tracks a user in space and time and alarms when the user has to leave thecurrent (spatial) location in order to reach a specified destination by a specified deadline(this functionality is similar to the conventional alarm clock, it does this while runningin the background without needing the user’s attention), and 2) it determines the possiblemovement choices that a user can make, it computes the shortest travel time associatedwith each choice and informs the user about the consequences of his/her decisions vialabels that are displayed at the decision making points.

2.1 Assumptions and dataOne crucial step of STAC is the estimation of a user’s travel time. This is done based ontwo assumptions: 1) the user moves along streets, not through a building or open fieldand 2) the user moves at a constant speed. The first assumption implies that the user canturn from one street to another at a street intersection and also turn around anywhere ona street.

The street network is represented in digital form by a graph such that nodes representstreet intersections and arcs represent street segments connecting two adjacent intersec-tions. Each arc has an associated value representing the time of its traversal, which isobtained by dividing its geometric length by the user’s speed. In this representation, ifthe user moves from node i to node j along arc(i, j), his/her location is specified by twopointers pointing at arc(i, j) and node i, and a numerical value indicating the travel timefrom node i to that location.

2.2 ComponentsAs illustrated in Figure 1, STAC consists of four general components:

• data input/output means, which accepts input from a user, and reads data fromthe storage means and communicate them to the user in various forms (e.g., visualand audio),

• data storage means, which stores relevant data (including the digital street net-work and user input),

• data processing means, which reads data from the data storage means, processthem, and writes results to the data storage means, and

• location and time detection means, which detects the user’s location and time

11

Figure 1: Components of space time alarm clock

2.3 Computational stepsSTAC involves five computational steps, as presented in Figure 2. The details of eachstep are described below.

Figure 2: Computational steps of space time alarm clock

12

2.3.1 Destination and deadline specification

The data input means accepts input specifying a destination and a deadline through thedata input means. Like a regular alarm clock, the deadline can be specified in the formatof day–hour–minute or the like. Like an existing navigation system, the destination can bespecified by describing its postal address, giving its geographic coordinates (e.g.,latitudeand longitude), or pointing at its approximate location on a reference map. Any of theseinputs is then converted to a node in the digital street network.

2.3.2 Shortest travel time computation

The data processing means computes the shortest travel time to the destination fromevery node in the digital street network. It should be noted that this can be done byrunning an all-to-one shortest path algorithm (such as Dijkstra’s algorithm [11], whichwas employed in our implementation as described in the next section) only once. Becauserelevant nodes are only those from which one can reach the destination by the deadline,the algorithm will be terminated when a node is labeled with a shortest travel time greaterthan the deadline minus the departure time.

Then the data processing means extracts only a subnetwork that spans the relevantnodes, and stores it in the data storage means. In the subsequent steps, this subnetworkis used instead of the network initially stored.

2.3.3 Location Detection

The location detection means continuously receives a GPS signal (or any other locationsensing data) representing coordinate data of the user’s location, which is then convertedto a point in the digital street network by an algorithm known as map matching. Com-monly, map matching is the operation that links two distinct data sets that have a spatialcomponent. Although the map matching operation has as main purpose obtaining thetopologically correct travel route, in STAC, map matching is used identify a user’s loca-tion along the network as close to real time as possible.

White [56] identified three types of map-matching, namely point-to-point map match-ing, which is basically a problem of finding the closest network node to a location, point-to-curve map matching, which snaps a location to its closest network edge, and curve-to-curve map matching, which forms a segment from a sequence of locations and identifiescommon segments within the road network.

Classical approaches, such as [24, 55], do not deliver the result in the desired timebecause their focus is on static trajectories, i.e., the processing is performed after the datacollection. Similarly, other approaches, such as [7, 30] focus on map matching for dataprovided by vehicles and the approaches are not suitable for pedestrian-specific data.

This thesis uses an algorithm similar to curve-to-curve map matching, where onecurve is represented by a trajectory that holds the last five recorded locations and theother curve is represented by an arc of the subnetwork. The movement direction of

13

the user is derived from the history of locations that form the trajectory. By using thisapproach, the algorithm can match the user’s location in real time.

The map matching algorithm is adapted so that it can match the locations as closeto real time as possible and it depends on two threshold values, Tdir, which representsthe maximum allowed difference between a movement’s direction and an arc’s direction,and Tdist, which represents the maximum allowed distance between the location of thetrajectory that is furthest away from the arc and the arc. The algorithm undergoes twomain steps: 1) if the previous sequence of locations has not been matched to the roadnetwork, then find the most suitable arc from the entire subnetwork, and 2) if the previoussequence of locations was matched to an arc, then try to match the current sequence oflocations to either the same arc or to the arc’s neighbors whose direction is similar to themovement’s direction and, if no arc is suitable (either the absolute difference betweenthe direction of the arc and the movement’s direction is more than Tdir or the distancebetween the location of the trajectory that is furthest away from the arc and the arc islarger than Tdist) then run step 1.

This process is outlined below with reference to Figure 3.

Figure 3: Location detection. The circle represents a node, the line represents an arc, thetriangle represents a GPS point, and the dot represents a network point determined by thematching algorithm

A point P1 is the first point detected by a GPS, and is snapped to arc(i, j), because thearc is closest to P1 and the distance between them does not exceed a specified threshold.Then, a point P2 is detected by the GPS, and is snapped to arc(i, j) because the arcis closest to P2 and the distance between them does not exceed the threshold and themovement direction P1 to P2 agrees to the arc’s direction. Then, a point P3 is detected bythe GPS, and it is not snapped to its nearest arc(j, l) because the movement direction P2 toP3 (more or less vertical) would not agree to the arc’s direction (more or less horizontal).Instead, P3 is snapped to arc(i, j) because the distance between P3 and the arc does notexceed the threshold and the movement directions P2 to P3 agrees to the arc’s direction.Then, a point P4 is detected by the GPS but not snapped to its closest arc(i, j) becausethe distance between them exceeds the threshold. Finally, a point P5 is detected by the

14

GPS and it is snapped to arc(j, l) because the arc is closest to P5, the distance betweenthem does not exceed the threshold, and the movement direction P4 to P5 agrees to thearc’s direction.

This step will be revisited until the user reaches the destination.

2.3.4 Earliest arrival time estimation

At every specified interval, the data processing means estimates the earliest arrival timeat the destination by the following simple arithmetic. Suppose that the user is currentlyat a point p on arc(i, j) as shown in Figure 4. Then, obviously, he/she must go througheither node i or j to reach the destination. Thus, the earliest arrival time via node j isestimated as tc+ t(p, j)+d(j), where tc is the current time, t(p, j) is the travel time fromp to node j, and d(i) is the shortest travel time from node j to the destination. Similarly,the earliest arrival time via node i is estimated as tc+t(p, i)+d(i). Therefore, the earliestarrival time, te(p), from p is given by:

te(p) = min(tc + t (p, j) + d (j) , tc + t (p, i) + d (i)) (1)

It is important to note that this is a trivial computation, as the shortest travel time d(i)has been already computed and is stored in the data storage means.

Figure 4: Estimating earliest arrival time. The dot represents the current position.

2.3.5 Consequence values computation

After the data processing estimates the arrival time, the data processing means retrievethe neighbors of the arc the current location belongs to that are visible on the device’sdisplay, which is a component of the data input/output means, (either both of the nodes ofan arc are within the subnetwork drawn on the display or only one node is) and computesthe shortest travel time specific to following each arc.

Let te(k) represent the earliest arrival time from the current location when passingthrough node k, te(p) represent the earliest arrival time from the current location, and

15

d(k) represent the shortest travel time from node k to the destination. Furthermore, lett (p, k) represent either the travel time from p to node k, when the shortest path from p tothe destination does not pass through node k’s neighbor, or the travel time from node k’sneighbor to node k, when the shortest path from p to the destination passes through nodek’s neighbor. The equation that computes te(k) is:

te(k) = te(p) + t (p, k) + d(k) (2)

The process is described with regards to Figure 5.

Figure 5: Labeling system. The dashed rectangle represents the focus of the display andthe rectangles represent the labels. The dot represents the current location.

Given the current location p located on arc(i, j), the arcs that intersect the focus of thedisplay and are neighbors with arc(i, j) are arc(j, k) and arc(j, l). Out of all considerednodes, nodes i, k and l are outside of the focus of the display. If the shortest path fromp to the destination passes through node j then arc(i, j) is labeled with te(i) = te(p) +t (p, i) + d(i), arc(j, k) is labeled with te(k) = te(p) + t (j, k) + d(k) and arc(j, l) islabeled with te(l) = te(p) + t (j, l) + d(l). Otherwise, if the shortest path from p tothe destination passes through node i then arc(i, j) is labeled with te(i) = tc, arc(j, k)is labeled with te(k) = te(p) + t (p, j) + t (j, k) + d(k) and arc(j, l) is labeled withte(l) = te(p) + t (p, j) + t (j, l) + d(l).

2.3.6 Communication

The data input/output means draw the visible labels at their equivalent position on thesmartphone’s display. The data processing means compares the estimated arrival timeand the deadline. If the former is greater than the latter, the data input/output meansgenerates an alarm signal (e.g., video, audio, textual, or haptic) and communicates it tothe user. Otherwise, it stops generating and communicating the alarm signal.

16

3 ImplementationThis section presents the general architecture of STAC, its components and the architec-ture of each component.

3.1 General ArchitectureWe have implemented STAC based on a “full client architecture” [26] that connects eachof multiple clients with limited storage and computing capability (e.g.,for arrival timeestimation) only once to a server with large storage (e.g.,for street network data) andpowerful computing capability (e.g.,for shortest path computation). Having mobile de-vices as clients, this way allows us to serve multiple users at the same time, Figure 6illustrates an overview of the architecture of the current implementation of STAC.

Figure 6: Architecture of the implementation of STAC. The OpenScienceMap server(right box) works as the STAC server and an Android device as a STAC client (phoneimage), with which a user (top oval) interact.

17

3.2 Server-side ImplementationSTAC uses the main server of OpenScienceMap (OSciM) [48], which plays roles of thedata storage means and the data processing means. OSciM is a platform to freely andefficiently offer Android mobiles users mapping and map rendering services. The OSciMserver contains a PostgreSQL [40] database management system (DBMS) with PostGISextension [39], which stores the complete OpenStreetMap (OSM) [19] data includingworldwide street network data and supports the management, query, and analysis of thesedata. The OSciM server uses an Apache Tomcat web server [4] and implements severalJava servlets to efficiently communicate with multiple clients. The PostgreSQL DBMSfurther contains the pgRouting extension [38], which specializes in geospatial routingfunctionality including Dijkstra’s shortest path algorithm.

The STAC server’s main purposes are: (1) extracting the subnetwork relevant to agiven origin, destination and available time, (2) finding the node that is closest to thedestination, and (3) generating an all-to-one shortest path tree on the relevant subnetworkwith regards to the destination.

From a theoretical stand point, the first step is ignored, as the computational complex-ity is more important than the computational time. However, given the practical nature ofthe implementation where it is imperative to reduce the computation time, we employeda simple heuristic to extract the relevant subnetwork.

One valid approach is to consider only the destination and the available time and toextract all the nodes and edges of the network that are within a circle with a radius ofat ∗ cs, where at represents the available time and cs

† represents the constant (walking)speed. However, while this approach is simple to understand, it is over-representativeof the relevant subnetwork because it considers that the user can be anywhere in thenetwork.

To reduce the size of the subnetwork, we employed a different approach that alsotakes into account the current location of the user (i.e., origin). This method generates anellipse with the origin as one of its focus, the destination as the other focus and the sumof the distances from the foci to every point on the line is at ∗ cs. The ellipse is presentedin Figure 7

Figure 7: Ellipse used to extract the relevant subnetwork. “O” represents the first focus,which corresponds to the origin, “D” represents the second focus, which corresponds tothe destination, a represents the distance from “O” to a point on the ellipse, b representsthe distance from “D” to a point on the ellipse, and a+ b = at ∗ cs.

†We used 1 m/s as cs in the implementation presented in this report.

18

The relevant subnetwork extraction is performed with a SQL query similar to (seeAppendix A for the full PL/pgSQL function):

SELECT * FROM network WHERE ST WITHIN(network geom, get ellipse(latorig,lonorig, latdest, londest, at));

After extracting the relevant subnetwork, the next task is finding the closest node tothe destination, which can be easily done via a SQL query similar to (see Appendix A forthe full PL/pgSQL function):

SELECT node FROM get closest node( latdest, londest);

Finally, the shortest path tree algorithm is performed on the subnetwork and all thereachable nodes and edges that connect them are extracted and built into a response thatis sent to the client (see Figure 8 for an example of the shortest path tree result on a givensubnetwork).

Legend

Destination

Origin

Node arrival time

0 - 7.5 minutes

7.5 - 15 minutes

15 - 22.5 minutes

22.5 - 30 minutes

Edges

Ellipse

OpenStreetMap

Figure 8: The output of the shortest path tree on the relevant subnetwork. The green starrepresents the origin (59.3622189 latitude, 17.9982 longitude) and the yellow star repre-sents the destination (59.3548189 latitude, 17.9892 longitude). The gray area representsthe ellipse generated for the origin, destination and available time of 30 minutes.

19

3.3 Client-side ImplementationEach client of STAC is an Android smartphone or any other Android device, which hasa storage medium containing a SQLite DBMS [54], a central processing unit (CPU), aGPS receiver, and a graphical user interface (GUI), and is able to communicate with theOSciM server. The SQLite DBMS plays a role of the data storage means. The CPU playsthe role of the data processing mean. The GPS receiver and the CPU clocks serve as thelocation and time detection means. The Android GUI serves as the data input/outputmeans.

With reference to Figure 6, the workflow of STAC is explained below. First (arrow 1),through the Android GUI (Figure 9), the user specifies the destination by tapping on itslocation on a reference map or typing its address or place name in the textbox on the top ofthe display, which brings the user to the next dialog box in which the date/hour/minute ofthe deadline is typed. Then, a request for shortest travel time computation together withthe user input is sent to OSciM server (arrow 2). The OSciM server receives a request(that contains a destination and a deadline) (arrow 2) and runs a servlet requesting thePostgreSQL DBMS to run a shortest path algorithm and extract a subnetwork that spansall nodes from which the destination can be reached by the deadline. The subnetwork isthen sent to the client using a servlet (arrow 3). The Android client will not contact theserver again.

Figure 9: Specification of destination and deadline in the STAC research prototype. Onthe left, the map marker represents the location of a specified destination (which, in thepresent example, corresponds to the address typed in the textbox on top). On the right,in response to tapping on a first dialog box showing a default deadline (which is, in thepresent example, set to 30 minutes from the current time), a second dialog box pops upto accept a user input for its modification.

20

As soon as the Android client receives the subnetwork from the OSciM server (arrow3) (and it parses it using the GSON [17] library used to convert JSON representationsto their equivalent objects), it stores the subnetwork in the SQLite database and builds aquadtree indexing structure [45] for all the nodes in the subnetwork in order to efficientlyperform necessary spatial queries (e.g., retrieval of the node closest to a specified point orretrieval of the node having a specified ID) in the remaining steps. Then, Android client’sGPS receiver starts tracking the user’s location every second. This frequency was chosenas a compromise between the client’s battery life and the accuracy in map matching. EachGPS point is then map-matched to a point on an arc in the subnetwork. Only the latestmap-matched point and the three immediately preceding points are stored in the SQLitedatabase. These points are used to reduce the uncertainty (due to GPS measurementnoise) in the user’s location and movement direction. Then, the arrival time is estimatedbased on the device’s CPU clock and the current location.

Once the arrival time is estimated, the labeling system extracts the geometries of thearc the current location was matched to and its neighbors, and it checks which of themare intersecting the current map view. The labeling system then estimates the arrivaltime associated to following each of the previously extracted arcs and draws the labelsaccordingly (see Figure 10).

Figure 10: An example of how labels are implemented. The red marker represents theuser’s location, its arrow represents the direction the user is heading towards. In thiscase, if the user goes straight, it will take him/her 3 minutes and 6 seconds to reach thedestination, if he/she goes right, it will take him/her 6 minutes and 37 seconds to reachthe destination and if he/she turns around, it will take him/her 9 minutes and 46 secondsto reach the destination.

21

The CPU clock runs and updates the arrival time every millisecond (set by default).If the estimated arrival time is later than the deadline, the Android client’s alarm goes off,and optionally asks the user whether he/she wants any available navigational applicationstart (arrow 4).

22

4 EvaluationThis section distinguishes between each task that is performed on the client and on theserver and determines its computation time. These operations are performed because wewant to identify the main bottlenecks in the current implementation and we want to studythe effect of the increase of available time on the time it takes to perform each task.

4.1 Server side performance evaluationThe server performs the following tasks: (1) it generates the ellipse, (2) it finds the closestnode to the destination, and (3) it computes the shortest path tree.

The measurements were performed for 5 different origins and, for each origin, weconsidered 6 destinations (See Appendix B for the latitude and longitude for the locationsof the considered origins and destinations). We considered as destinations the following:

• the destination coincides with the origin,

• the destination is displaced 1 km from the origin,

• the destination is displaced 2 km from the origin,

• the destination is displaced 3 km from the origin,

• the destination is displaced 4 km from the origin, and

• the destination is displaced 5 km from the origin.

The tests were performed on an Openshift [36] virtual environment with 512MBRAM and shared CPU based on the processing load. The detailed aggregates for allof the performance measures can be found in Appendix C. The OSM data used for thesetests was downloaded on 22 April 2014.

Even though most of the server-side tasks increase quadratically with the increase ofthe available time, the effect is less visible in the figures because of the varying densityof nodes throughout the study area.

4.1.1 Processing time for generating the ellipse

The ellipse generation is a mathematical operation and the computation time to generatethe ellipses is not affected by any external factor. For 36 measurements, we obtainedan average computation time of 4.2 milliseconds with a standard deviation of 5.5 mil-liseconds, which is mainly due to CPU fluctuations. In this case, the median is morerepresentative of the computation time and its value is 1.3 seconds.

23

4.1.2 Processing time for finding the closest node to the destination

The PostGIS extension of PostgreSQL enables indexing the geometry of elements withstructures such as B-tree [8] and GiST [23] (Generalized Search Tree) structures. TheGiST index was used to reduce the number of operations performed while performingspatial operations such as finding the closest neighbor of a geometry. For 36 measure-ments, we obtained an average computation time of 2.6 milliseconds, with a standarddeviation of 4.5 milliseconds and a median of 0.7 milliseconds.

4.1.3 Processing time for extracting the subnetwork within the ellipse

This step extracts all the nodes that are within the ellipse. We have found that this step isclosely related to the size of the ellipse, which in turn is affected by the origin, destinationand available time. The computation time increases quadratically with the available time(see Figure 11).

0

100

200

300

400

500

600

0 0.5 1 1.5 2 2.5 3

Tim

e (

mil

lise

co

nd

s)

Available time (hours)

Performance measurements for subnetwork extraction

Figure 11: Performance measurements for the subnetwork extraction. For this figure, theorigin corresponds with the destination.

However, as the distance between the origin and destination flattens the ellipse andreduces its area, the computation time decreases when the distance between origin anddestination increases. This can be seen in Table 1.

24

Table 1 The effect of the distance between origin and destination for extracting the sub-network within the ellipse. For these measurements, the available time was considered tobe three hours.

Distance (m) Avg. (ms) Med. (ms) Std. Dev. (ms)0 516 404 2571000 501 501 722000 473 484 653000 452 482 604000 424 485 955000 411 419 70

4.1.4 Number of nodes generated by the subnetwork extraction

The number of nodes depends on the same parameters as the processing time for extract-ing the subnetwork, namely the distance between the origin and the destination and theavailable time. The number of nodes within the subnetwork increases quadratically withthe available time (see Figure 12).

0

5000

10000

15000

20000

25000

30000

0 0.5 1 1.5 2 2.5 3

Nu

mb

er o

f n

od

es

Available time (hours)

Number of nodes generated by the subnetwork extraction

Figure 12: Number of nodes generated by the subnetwork extraction. For this figure, theorigin corresponds with the destination.

Similar to the behavior of the processing time, the number of nodes decreases whenthe distance between origin and destination increases (see Table 2). However, it can alsobe noticed that the standard deviation increases together with the distance between theorigin and the destination. This might be due to the varying density of nodes per unit ofsurface, which increases when the subnetwork covers denser areas and decreases whenthe subnetwork covers sparser areas.

25

Table 2 The effect of the distance between origin and destination for the number of ex-tracted nodes of the subnetwork within the ellipse. For these measurements, the availabletime was considered to be three hours.

Distance (m) Avg. Med. Std. Dev.0 28228.6 28604.0 4059.91000 28801.5 30270.0 5060.02000 27617.2 28327.0 5185.73000 26873.0 27690.0 5930.94000 25918.2 27690.0 6836.05000 24293.0 26026.0 7055.6

4.1.5 Processing time for computing the shortest path tree

This step runs the shortest path tree algorithm on the network that was extracted in Sec-tion 4.1.3. As expected, this step depends on the number of nodes within the subnetwork,which implies that it is directly affected by the distance between origin and destina-tion (see Table 3) and the available time (see Figure 13). The processing time increasesquadratically with the available time.

0

10000

20000

30000

40000

50000

60000

70000

0 0.5 1 1.5 2 2.5 3

Tim

e (m

illi

seco

nd

s)

Available time (hours)

Performance measurements for computing the shortest path tree

Figure 13: Performance measurements for computing the shortest path tree. For thisfigure, the origin corresponds with the destination.

Similar to the previous observations, the standard deviation increases together withthe distance between the origin and the destination (see Table 3).

As shown in Figure 13, the computation time for the shortest path tree algorithmvaries from 2 seconds to over 1 minute, and it takes considerably longer to run this stepthan any of the aforementioned steps.

26

Table 3 The effect of the distance between origin and destination for the shortest pathtree computation. For these measurements, the available time was considered to be threehours.

Distance (m) Avg. (ms) Med. (ms) Std. Dev. (ms)0 60894.2 62295.1 8754.01000 62128.4 65757.0 9791.12000 58769.7 61076.8 10081.53000 57483.2 58896.1 11236.04000 55623.0 60689.2 14284.95000 52962.6 55412.9 14763.6

4.1.6 Total processing time for the server side

The shortest path tree computation has been identified as the main bottleneck of the serveroperations, as it accounts to more than 98% of the total computation time. Consistent withthe previous, operations the processing time increases quadratically with the availabletime and varies from 6 seconds to 63 seconds (see Table 4).

Table 4 Total processing time on the server side. For these measurements, the origincorresponds with the destination.

Av t (h) Avg. (s) Med. (s) Std. Dev. (s) Min. (s) Max. (s)0.5 6.3 6.7 0.8 5.0 6.81 13.8 14.4 2.4 9.7 15.51.5 23.6 23.2 4.9 16.1 28.22 35.3 35.3 8.3 23.6 43.62.5 46.9 46.8 9.1 33.3 55.93 61.4 62.7 8.9 48.3 72.5

4.1.7 Number of edges sent to the client

The number of edges that is sent to the client is measured to estimate the client overload.It is defined as the number of edges connecting any two nodes from which the destinationis reachable.

As expected, this step depends on the number of nodes within the subnetwork, whichimplies that it is directly affected by the distance between origin and destination (seeTable 5) and it increases quadratically with the available time (see Figure 14).

27

0

5000

10000

15000

20000

25000

30000

35000

40000

0 0.5 1 1.5 2 2.5 3

Nu

mb

er o

f ed

ges

Available time (hours)

Number of edges sent to the client

Figure 14: Number of edges sent to the client. For this figure, the origin correspondswith the destination.

Table 5 The effect of the distance between origin and destination for the number of edgesthat is sent to the client. For these measurements, the available time was considered to bethree hours.

Distance (m) Avg. Med. Std. Dev.0 35691.4 36086.0 5458.21000 36428.3 38373.5 6765.72000 35016.0 35837.0 6844.83000 34102.4 35117.0 7816.34000 32913.4 35139.0 8975.65000 30804.8 33014.0 9250.4

28

4.2 Client side performance evaluationThe client performs three main tasks before providing the STAC functionality, namely:(1) reading the subnetwork sent by the server, (2) building the topology and inserting theedges in the database, and (3) building the indexing system on the subnetwork.

The evaluation has been performed on an HTC One X+ smartphone model, runningon Android 4.2.2.

4.2.1 Processing time for reading the subnetwork sent by the server

This step requires the phone to be connected to the Internet but the impact of varyingconnection speed is beyond the purpose of this thesis.

To this extent, the client receives a stream of data as input and, based on the datacontent, it builds objects from the stream. The data that is being sent by the serverrepresents the relevant subnetwork for the given origin, destination and available time,and its was discussed in Section 4.1.7.

Reading the subnetwork sent by the server is directly affected by the number of edgesinside the subnetwork and the processing time increases with the size of the network in alinear fashion. (see Figure 15).

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 20000 25000 30000

Pro

cess

ing

tim

e (m

illi

seco

nd

s)

Number of edges

Processing time for reading the subnetwork sent by the server

Figure 15: Processing time for reading the subnetwork sent by the server.

29

4.2.2 Processing time for building the topology of the subnetwork

After the data was read and built into objects, the topology is built so that each node hasthe correct set of neighboring nodes and the edges that connect a node to its neighborsare connected.

This operation is affected by the number of edges inside the subnetwork and theprocessing time increases with the size of the network in a linear fashion (see Figure 16).

0

10000

20000

30000

40000

50000

60000

70000

0 5000 10000 15000 20000 25000 30000

Pro

cess

ing

tim

e (m

illi

seco

nd

s)

Number of edges

Processing time for building the topology of the subnetwork

Figure 16: Processing time for building the topology of the subnetwork.

4.2.3 Processing time for building the indexes

This step builds R-tree indexes on the geometry of nodes and, as expected, it depends onthe size of subnetwork that is being sent to the client and the processing time increaseswith the size of the network in a linear fashion (see Figure 17).

0

10000

20000

30000

40000

50000

60000

70000

0 5000 10000 15000 20000 25000 30000

Pro

cess

ing t

ime

(mil

lise

conds)

Number of edges

Processing time for building the indexes

Figure 17: Processing time for building the indexes.

30

4.2.4 Total computation time for the client side

Reading the response from the server has been identified as the main bottleneck of theclient operations, as it accounts to more than 43% of the total computation time, followedby the operation of building the indexes, that is responsible for approximately 30% of theprocessing time. Building the topology is responsible for the rest 27% of the processingtime (see Figure 18).

0

50000

100000

150000

200000

250000

0 5000 10000 15000 20000 25000 30000

Pro

cess

ing

tim

e (m

illi

seco

nd

s)

Number of edges

Total processing time

SubnetworkTopology

IndexTotal

Figure 18: Total processing time.

31

4.3 Overall waiting timeWe consider the overall time as being the time elapsed since the client sent the request tothe server until the alarm is functional on the client (after the network has been indexed).As expected, the waiting time, together with the standard deviation, increase with theaverage time (see Table 6).

Table 6 Overall waiting time. For these measurements, the origin corresponds with thedestination.

Av t (h) Avg. (s) Med. (s) Std. Dev. (s) Min. (s) Max. (s)0.5 24.0 26.6 7.0 14.8 27.01 66.0 69.0 16.3 41.3 79.01.5 123.8 123.8 31.8 76.7 153.72 189.6 191.9 50.5 117.9 235.32.5 253.9 254.3 54.2 173.5 307.03 328.3 332.6 51.2 251.1 380.1

The service becomes unusable if the available time is greater than 2 hours, as thewaiting time becomes too long (over 3 minutes). However, this depends on the locationof the origin and the destination, as sparser areas (corresponding to the “Min” column inTable 6) have a waiting time similar to the average waiting time of the previous step (e.g.,the minimum time for 2 hours, namely 117.9 second, is approximately the same with theaverage time for 1.5 hours, namely 123.8 seconds).

Furthermore, it is noticeable that the server processing time is considerably lower -approximately 20% of the total processing time - than the client processing time - ap-proximately 80% of the total processing time.

32

4.4 Case study4.4.1 Questionnaire design

The questionnaire was designed to answer questions regarding the user’s familiarity withthe environment the application was tested in, the alarm clock’s functionality and thelabeling system’s functionality.

General1. Do you live (or have you lived) in Stockholm?The answer to this question provides useful information regarding the user’s familiarityto the study area.

Alarm functionality2. Did the alarm go off?3. Did you reach the destination in time?The answers to questions 2 and 3 are analyzed together and they can fall in one out ofthe four possible cases. We interpret the first case, where the answer to both questionsis “No”, as a malfunction of STAC, thus failing to aid the user. The second case, whereboth the answers are “Yes”, represents the case in which STAC functioned accordinglyand the user reached the destination in time thanks to STAC. The third case, where thealarm went off but the user did not reach the destination in time, represents the case whenthe user interrupted STAC because of other concerns. The fourth case, where the alarmdid not go off but the user reached the destination in time, represents the case in which auser did not pay much attention to STAC, as he/she already had a predefined schedule. 4.If not, please describe why Space Time Alarm Clock failed to help you.The answer to this question relates to the conditions in which the Space Time AlarmClock failed to work and it can be used to understand its shortcomings.

Labeling functionality5. Did you use the labels (like 8m41s) around your location?The answer to this question provides information regarding whether a user consideredthe labeling system or not when testing.6. Did the labels make sense to you?The answer to this question provides information regarding the readability and/or infor-mation content of the labels.7. Did the labels affect your choice of directions?The answer to this question provides information regarding the user’s experience withlabels, namely whether the user’s actions were influenced by the presence of the labels.8. If so, how?If the answer to question 7 is “Yes”, this question is supposed to capture more informationregarding how the labels were used by the user.

33

4.4.2 Collected questionnaires

This section contains the summary of the five questionnaires that were filled in by fivedifferent respondents.

Quantitative evaluation of STAC

User overview All five users that tested STAC live (or have lived) in the study area.

Alarm functionality The answers for three of the users fell in the second case(mentioned above), where STAC helped the user to get to the destination. One set ofanswers fell in case one, which means that STAC failed to aid that user. Finally, oneset of answers fell in the fourth case, where the user arrived at the destination withoutwaiting for STAC to ring.

Labeling functionality All five users understood what the labeling system was sup-posed to represent. Except user 1, the rest of the users were influenced by the labelingsystem while choosing their direction.

Qualitative evaluation of STAC

a) Description of how STAC failed to aid the user to reach the destination in time

User 1 This user reached the destination in time.

User 2 “The limit of 30min was too short”User 2 failed to reach the destination in time because there was either a temporal

malfunctioning of STAC or the user did not read the instructions provided for testingSTAC.

User 3 This user reached the destination in time.

User 4 This user reached the destination in time.

User 5 This user reached the destination in time.

34

b) Description of how the labeling system affected the users’ choice of directions

User 1 “Most of the labels are just useful at the beginning when I chose the direc-tions, when I decided which routes, only the labels for the routes I chose made a littlesense(for telling the time) but I wouldn’t change my direction anymore according to otherlabels. too many labels when I was walking, it made me a little confused”

User 1 based his/her decision on the labels only when it came to choose the initialroute to follow. In this case, the labels were used as a substitute for classic navigationsystems. Once the user decided which path to follow, the cognitive load seems to be toomuch for the task at hand.

User 2 User 2 did not provide any response regarding the utility of labels or abouthow they have been used.

User 3 “To choose a longer but more appealing route, or to make a small detour toperform a side-task. It would be interesting to be able to change the base map or/ and tobe able to see certain points of interest, to justify this choice. For example if you use thisaplication as a tourist in Stockholm you want to catch the train back home, but you wantto know which is the most interesting route that will allow you to catch this train.”

User 3 described a broader use of how the labels can be used in a touristic contextwhere they can facilitate the exploration of certain parts of a city that can be of interestfor a user (who is also a tourist in this case).

User 4 “My usage pattern of the app was tainted by my extended use of traditionalnavigation systems which made me presumably look at the screen too much and mademe focus on trying to figure out the choices that lead me on the shortest path to mydestination, i.e., I was always looking for the choices with the least time label on them.In a sense it was difficult to emulate a test scenario where the app is used as a alarmclock of space exploration tool.”

User 4 provided a verbose description of how the application was used as a classicalnavigation tool to reach the destination via the shortest path. In this case, the user wastrying to figure out what the shortest path is at every decision point and the cognitive loadmade it difficult for the user to use the application as a navigation tool. The user pointedat his habit of using classical navigation tools, which might have influenced how he/sheused STAC.

User 5 “The labels displayed the optimal time for arriving to my destination point;they suggested in a slightly different route than the one I was following and given mywalking speed I made it to my destination on the arranged time.”

User 5 used the labels to reach the destination as soon as possible and he/she noticedthat the shortest path was slightly different than the path he/she usually takes for arrivingat the same destination.

35

5 Conclusions and Future WorkThis section concludes and presents the possible future work related to this project.

5.1 ConclusionsWe have presented a new location-based service, called Space Time Alarm Clock (STAC),for continuously monitoring the location of a user and alerting when the user has to leavethe current location in order to arrive at a specified destination by a specified deadline. Todo so, assuming that the user moves at a constant speed through a given street network,STAC performs a simple logic comprising: 1) accepting a specification of a destinationand a deadline and computing the shortest travel time from each node of the networkto the destination, 2) tracking the user’s location in the network in real time, 3) addingthe current time and the travel time from the current location to the destination, and 4)generating an alarm signal if the result exceeds the deadline. Optionally it also shows theamount of time remaining at the current location before it becomes impossible to reachthe destination in time. STAC can be implemented as a stand-alone mobile applicationor integrated to an existing navigation system.

The system was tested in an uncontrolled experiment, where the application was up-loaded to a website, a set of instructions were provided and the users filled in a ques-tionnaire about their experience with STAC. The majority of the users did not miss theirdeadline while using STAC and the labeling system influenced their choice of directions.There seems to be a noticeable cognitive load when STAC is used as a classical naviga-tion system, but that is mostly due to the fact that the users are already used to existingnavigation systems.

We have noticed that both server-side and client-side computation time is directlyaffected by the available time and the area in which the application is used. The denser thenetwork of that area, the more the computation time increases, which usually correspondsto the central part of the city.

As it was discussed previously, the client-side computation time is considerably largerthan the server-side computation time (approximately three times more) and it increases -together with the available time - faster than the equivalent server-side time. This bringsto question whether the labeling functionality should always be used together with thealarm functionality. On one hand, the labeling functionality is built on top of the samesubnetwork used by the alarm counter part and both use the same algorithms to providethe desire functionality. On the other hand, the labels need to be displayed for the user tosee as soon as possible, while the alarm functionality can deliver an approximate resultuntil a more precise one can be achieved. Furthermore, the alarm can run and performall computations seamlessly, in the “background”, without requiring any user’s attention.Finally, the computation time needs to be reduced on both the client side and the serverside in order to increase the utility and usability of STAC.

One problem that we have encountered was regarding the incompleteness of the OSMdata in some cases. This is mostly due to incorrect labeling of certain road segments and

36

the fact that the OSM data set can be changed by any registered user, at any time. Inorder to keep the data set up-to-date, the OSM network needs to be downloaded daily (orhourly). This raises multiple problems: (1) this operation is not feasible because of theindexing structures used by the DBMS, which need to be rebuilt every time a new dataset is inserted, (2) the server becomes unreachable for certain periods of time, on a dailybasis, and (3) the topology of the network needs to be recomputed at every insertion andsome information kept in certain columns is lost.

While we showed that STAC worked according to our expectancies, the number ofusers that tested the application and filled in the questionnaires is too little to derive anystatistically significant information. However, the initial testing of STAC is an incentivefor future research that involves exploring the potential of STAC and how different usersexpect to use such a system.

37

5.2 Future WorkCurrently, STAC is working only in the Stockholm area, but this can be easily extendedfor the rest of the world. However, STAC is designed for pedestrians only and it is, inprinciple, possible to extend it to other modes of transportations including driving andpublic transportation. Care must be taken, however, because this would bring about agreater degree of uncertainty and dynamics in arrival time estimation, which, in turn,would require not just one, but more likely frequent, update of network data and execu-tion of a shortest path algorithm, which would cause a significant amount of computationand thus communication. Probably the next natural step would be to include train asa transportation mode, as it is usually not affected by traffic congestions since it func-tions on the railroad network. However, this would increase the number of accessiblenodes and the heuristic involved in extracting the relevant subnetwork for a destinationand deadline might need to change. Furthermore, incorporating public transportationis particularly hard because of the different agencies that handle public transportationin different countries or even cities. Finally, a robust system would need to have realtime information about the traffic situation, which is, at the time this report was wrote,available in only some places of the world.

The assumptions on top of which STAC was developed and implemented, namely thatthe user moves at a constant speed and only on the road network, prevent the delivery ofinformations regarding earliest arrival time when the user leaves the road network (e.g.,takes a shortcut through a building or through open space). However, if the OSM data willinclude information about routes that can be taken through buildings and open spaces andif new location receiving services allow for positioning independent of satellite visibility,the current implementation can provide its functionality as it is.

An important implication of STAC is that while location-based technology may con-tinue to advance in terms of the capability of prescribing spatio-temporal decisions orplans (e.g.,route directions) that optimize multiple, possibly conflicting, objectives andconstraints, it can also offer less proactive assistance, which aims to softly influenceone’s behavior by limiting its intervention to the provision of warnings or suggestionsonly when undesired outcomes (e.g.,being late) are anticipated to happen. The questionis not about which of the two capabilities is more important but how to balance themaccording to the purpose and context and, if necessary, alternate them seamlessly.

Finally, an extension for STAC would be to allow the user to enter a list of places thathe/she wants to visit and, optionally, the order in which the places need to be visited, andaid the user in visiting all the places within the available time. This would allow STAC tobe used together with scheduling tools by a wider range of people. An interesting additionto this branch of research would be studying how people that have already used navigationsystem interact with STAC and what their expectancies are compared to people who havelittle or no experience with using navigation systems.

38

References[1] Abdalla, Amin “LatYourLife: A Geo-Temporal Task Planning Application”. In Ad-

vances in Location-Based Services. Springer Berlin Heidelberg: 305-325, 2012,doi:10.1007/978-3-642-24198-7 20

[2] Abbott, Eric, and Powell, David. “Land-vehicle navigation using GPS.”Proceedings of the IEEE 87, no. 1: 145-162, 1999, doi:10.1.1.175.4174,http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=736347&isnumber=15872 Last accessed July 7, 2014

[3] Adusei, Isaac K., Kyamakya, K., and Jobmann, Klauss. “Mobile positioningtechnologies in cellular networks: an evaluation of their performance metrics.”In MILCOM, vol. 2: 1239-1244, 2002, doi:10.1109/MILCOM.2002.1179656,http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1179656&isnumber=26490 Last accessed July 7, 2014

[4] “Apache Tomcat” http://tomcat.apache.org/ Last accessed July 7, 2014

[5] “Android” http://www.android.com/ Last accessed July 7, 2014

[6] Arikawa, Masatoshi, Shin’ichi Konomi, and Keisuke Ohnishi. “NAVITIME: Sup-porting pedestrian navigation in the real world.” Pervasive Computing, IEEE 6, no.3: 21-29, 2007. doi:10.1109/MPRV.2007.61

[7] Brakatsoulas, Sotiris, Pfoser, Dieter , Salas, Randall, and Wenk, Carola. “On map-matching vehicle tracking data.” In Proceedings of the 31st international conferenceon Very large data bases: 853-864, 2005, isbn=1-59593-154-6

[8] Comer, Douglas. “Ubiquitous B-tree”. ACM Computing Surveys (CSUR),11(2): 121-137, 1979, doi:10.1145/356770.356776, http://doi.acm.org/10.1145/356770.356776 Last accessed July 7, 2014

[9] Chih-Ming, Chen, Chin-Ming, Hong and Shin-Cia, Chen. “Intelligent location-based mobile news service system with automatic news summarization.” En-vironmental Science and Information Application Technology: 527-530, 2009,doi:10.1109/ESIAT.2009.485

[10] Dantzig, George, B. “On the Shortest Route Through a Network”, In ManagementScience, Volume 6, 2: 187-190, 1960, doi:doi.org/10.1287/mnsc.6.2.187

[11] Dijkstra, Edsger W. “A note on two problems in connexion with graphs.” Nu-merische mathematik 1.1 269-271, 1959, doi:10.1.1.165.7577

[12] Duckham, Matt, and Kulik, Lars. “ Simplest Paths: Automated Route Selection forNavigation.” In Spatial Information Theory. Foundations of Geographic InformationScience: 169-185. Springer Berlin Heidelberg, 2003, doi:10.1007/978-3-540-39923-0 12

39

[13] Gartner, “Gartner Says Annual Smartphone Sales Surpassed Sales of FeaturePhones for the First Time in 2013”, http://www.gartner.com/newsroom/id/2665715 Last accessed July 7, 2014

[14] Gibson, James, J. “The concept of affordances”, Perceiving, acting, and knowing:67-82, 1977

[15] “Google Maps” https://maps.google.com/ Last accessed July 7, 2014

[16] Golledge, Reginald, G. “Human wayfinding and cognitive maps.” Wayfinding be-havior: Cognitive mapping and other spatial processes: 5-45, 1999, ISBN: 978-0801859939

[17] “google-gson” http://code.google.com/p/google-gson/ Last ac-cessed July 7, 2014

[18] Haque, Shazia, Kulik, Lars, and Klippel, Alexander. “Algorithms for reliable navi-gation and wayfinding.” In Spatial Cognition V Reasoning, Action, Interaction: 308-326. Springer Berlin Heidelberg, 2007, doi:10.1007/978-3-540-75666-8 18

[19] Haklay, Mordechai, and Weber, Patrick. “Openstreetmap: User-generatedstreet maps”. Pervasive Computing, IEEE 7, no. 4: 12-18, 2008,doi:10.1109/MPRV.2008.80, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4653466&isnumber=4653458 Last ac-cessed July 7, 2014

[20] Hart, Peter, E., Nilsson, Nils., J., and Raphael, Bertram. “A Formal Ba-sis for the Heuristic Determination of Minimum Cost Paths” In IEEE Trans-actions on Systems Science and Cybernetics, Volume 4, 2: 100 - 107, 1968,doi:10.1145/1056777.1056779

[21] Hagerstrand, Torsten “Space, time and human conditions”, 1975.

[22] Hagerstrand, Torsten. ”Migration and area.” Migration in Sweden: 27-158, 1957

[23] Hellerstein, Joseph,. M., Naughton, Jeffrey, F., and Pfeffer, Avi “Generalized searchtrees for database systems”. VLDB 1995: 562-573, 1995 http://dl.acm.org/citation.cfm?id=645921.673145 Last accessed July 7, 2014

[24] Yanagisawa, Hiroki “An Offline Map Matching via Integer Programming”, In pro-ceeding of: 20th International Conference on Pattern Recognition, ICPR 2010, Is-tanbul, Turkey: 23-26 August, 2010, doi:DOI: 10.1109/ICPR.2010.1022

[25] Jiang, Bin, and Yao, Xiaobai. “Location-based services and GIS in perspec-tive”. Computers, Environment and Urban Systems 30, no. 6: 712-725, 2006,doi:10.1016/j.compenvurbsys.2006.02.003

40

[26] Jing, Jin, Helal, Abdelsalam, S., and Elmagarmid, Ahmed “Client-Server Comput-ing in Mobile Environments”. ACM Computing Surveys, 31, no. 2: 117-157, 1999,doi:10.1.1.17.3097

[27] Karimi, Hassan, A. “Real-time optimal route computation: a heuristic approach”,ITS Journal - Intelligent Transportation Systems Journal Volume 3, Issue 2: 111-127,1996, doi:10.1080/10248079608903712.

[28] Kwan, Mei-Po, and Lee, Jiyeong. “Geovisualization of human activity patternsusing 3D GIS: a time-geographic approach.” Spatially integrated social science27, 2004, http://www.meipokwan.org/Paper/Best_2003.pdf Last ac-cessed July 7, 2014

[29] Lamming, Mik, and Flynn, Myke. “ “Forget-me-not”: Intimate computing in sup-port of human memory.” In Proc. FRIEND21, 1994 Int. Symp. on Next GenerationHuman Interface: 4, 1994, doi:10.1.1.1.6966

[30] Liu, Lianxia, Xi1, Quan, and Liu, Minghua, Li1, Zhong. “Map matching algorithmand its application.” (2007).

[31] Marmasse, Natalia, and Schmandt, Chris. “Location-Aware Information De-livery with ComMotion.” In Handheld and Ubiquitous Computing: 157-171,Springer Berlin Heidelberg, 2000, ISBN: 3-540-41093-7, http://dl.acm.org/citation.cfm?id=647986.741313, Last accessed July 7, 2014

[32] May, Andrew, J., Ross, Tracy, Bayer, Steven, H., and Tarkiainen, Mikko, J. “Pedes-trian navigation aids: information requirements and design implications” In Personaland Ubiquitous Computing, 7, no. 6: 331-338, 2003, doi:10.1007/s00779-003-0248-5

[33] Mlekuz, Dimitrij, and Vermeulen, Frank. “Time geography, GIS and archaeology.”In Fusion of Cultures. Abstracts from the 38th Conference on Computer Applica-tions and Quantitative Methods in Archaeology. University of Granada/CAA In-ternational. Granada: 443-445, 2010, http://www.academia.edu/376168/Time_geography_GIS_and_archaeology Last accessed July 7, 2014

[34] Miller, Harvey, J. “Modelling accessibility using space-time prism concepts withingeographical information systems”. International Journal of Geographical Informa-tion Systems Vol. 5, Issue 3: 287-301, 1991, doi:10.1080/02693799108927856

[35] Miller, Harvey, J. “A measurement theory for time geography”. Geograph-ical analysis 37, no. 1: 17-45, 2005, doi:10.1111/j.1538-4632.2005.00575.x,onlinelibrary.wiley.com/doi/10.1111/j.1538-4632.2005.00575.x/pdf Last accessed July 7, 2014

[36] “Openshift ” https://www.openshift.com/ Last accessed July 7, 2014

41

[37] “OsmAnd” http://osmand.net/ Last accessec July 7, 2014

[38] “pgRouting Project - Open Source Routing Library”. http://pgrouting.org/ Last accessed July 7, 2014

[39] “PostGIS - Spatial and Geographic objects for PostgreSQL” http://postgis.net/ Last accessed July 7, 2014

[40] “PostreSQL - The world’s most advanced open source database” http://www.postgresql.org/ Last accessed July 7, 2014

[41] Raper, Jonathan, Gartner, Georg, Karimi, Hassan, and Rizos, Chris. “A criti-cal evaluation of location based services and their potential”. Journal of Loca-tion Based Services 1, no. 1: 5-45, 2007, http://dx.doi.org/10.1080/17489720701584069 Last accessed July 7, 2014

[42] Raubal, Martin, Miller, Harvey, J., and Bridwell, Schott “User-Centered Time Ge-ography for Location-Based Services”. Geografiska Annaler: Series B, Human Ge-ography 86, no. 4: 245–265, 2004, doi: 10.1111/j.0435-3684.2004.00166.x

[43] Rekimoto, Jun, Ayatsuka, Yuji, and Hayashi, Kazuteru. “Augment-able reality: Sit-uated communication through physical and digital spaces.” , Second InternationalSymposium on Wearable Computers: 68-75, IEEE, 1998, http://dl.acm.org/citation.cfm?id=857199.858022 Last accessed July 7, 2014

[44] “Routino : Router for OpenStreetMap Data” http://www.routino.org/Last accessed July 7, 2014

[45] Samet, Hanan. “The quadtree and related hierarchical data structures”. ACM Com-puting Surveys (CSUR) 16, no. 2: 187-260, 1984, doi:10.1145/356924.356930,http://doi.acm.org/10.1145/356924.356930 Last accessed July 7,2014

[46] Santos, Luıs, Joao Coutinho-Rodrigues, and Antunes, Carlos Henggeler . “A webspatial decision support system for vehicle routing using Google Maps.” DecisionSupport Systems 51.1: 1-9, 2011, doi:10.1016/j.dss.2010.11.008

[47] Schiller, Jochen, and Voisard, Agnes(Eds.). “Location-based services”, Elsevier,2004, ISBN: 9781558609297

[48] Schmid, Falko, Janetzek,Hannes, Wladysiak, Michael, and Hu, Bo. “Open-ScienceMap: open and free vector maps for low bandwidth applications”. Pro-ceedings of the 3rd ACM Symposium on Computing for Development. ACM: p.51, 2013, doi:10.1145/2442882.2442939, http://doi.acm.org/10.1145/2442882.2442939 Last accessed July 7, 2014

42

[49] Shirabe, Takeshi “Information on the consequence of a move and its use for routeimprovisation support”. In Spatial Information Theory, 10th International Confer-ence, COSIT 2011, Belfast, ME, USA, September: 12-16, 2011, doi:10.1007/978-3-642-23196-4 4

[50] Skog, Isaac, Handel, Peter, “In-Car Positioning and Navigation Technologies – ASurvey” Intelligent Transportation Systems, IEEE Transactions on , vol.10, no.1: 4-21, 2009, doi:10.1109/TITS.2008.2011712

[51] Smith, Aaron. “46% of American adults are smartphone owners.” Pew Internet& American Life Project, 2012, http://www.pewinternet.org/files/old-media/Files/Reports/2012/Smartphone%20ownership%202012.pdf Last accessed July 7, 2014

[52] Spreitzer, Mike, and Theimer, Marvin “Providing location information in a ubiqui-tous computing environment (panel session)”, ACM, vol. 27, no. 5.: 270-283, 1994,http://doi.acm.org/10.1145/173668.168641 Last accessed July 7,2014

[53] “STAC”http://people.kth.se/˜shirabe/SpaceTimeAlarmClock/STAC.html Last accessed July 7, 2014

[54] “SQLite” http://www.sqlite.org/ Last accessed July 7, 2014

[55] Wakuda, Yuki, Asano, Satoshi, Koshizuka, Noboru, and Sakamura, Ken. “An adap-tive map-matching based on Dynamic Time Warping for pedestrian positioning us-ing network map.” In Position Location and Navigation Symposium (PLANS), 2012IEEE/ION: 590-597, 2012, doi:10.1109/PLANS.2012.6236932

[56] White, Christopher, E., Bernstein, David, and Kornhauser, Alain, L. “Some mapmatching algorithms for personal navigation assistants”. Transportation ResearchPart C: Emerging Technologies 8, no.1: 91-108 , 2000

[57] Weyn, Maarten, and Schrooyen, Frederik. “A Wi-Fi Assisted GPS Po-sitioning Concept.”, ECUMICT, Gent, Belgium, 2008, https://www.researchgate.net/publication/228790908_A_Wi-Fi_Assisted_GPS_Positioning_Concept Last accessed July 7, 2014

[58] Zickuhr, Kathryn. ”Three-quarters of smartphone owners use location-based services.” Pew Internet & American Life Project, 2012 http://www.pewinternet.org/files/old-media/Files/Reports/2012/PIP_Location_based_services_2012_Report.pdf Lastaccessed July 7, 2014

43

Appendix A: SQL statements

CREATE OR REPLACE FUNCTION get ellipse(double precision, double precision,double precision, double precision, double precision, integer) RETURNS geometry AS$BODY$DECLAREtotaldist double precision;origdest double precision;a double precision;b double precision;xorig double precision;yorig double precision;eccentricity double precision;rotation double precision;result geometry;interm geometry;orig geometry;dest geometry;BEGINrotation = pi()/2-((st azimuth(st makepoint($1,$2)::geography,st makepoint($3,$4)::geography)+st azimuth(st makepoint($1,$2),st makepoint($3,$4)))/2);orig = st transform(st setsrid(st makepoint($1,$2),4326), 3006);dest = st transform(st setsrid(st makepoint($3,$4),4326), 3006);xorig = (st x(orig)+st x(dest))/2;yorig = (st y(orig)+st y(dest))/2;origdest = st distance(orig, dest);interm = st setsrid(st makepoint(st x(dest)+3600*$5, st y(dest)), 3006);totaldist = st distance(interm,dest);if (origdest<>0) thenif totaldist >origdest thenb = (totaldist - origdest);a = totaldist;b= sqrt(totaldist * totaldist - origdest * origdest);result = st setsrid(ST Translate( ST Rotate( ST Scale( ST Buffer(ST Point(0,0), 0.5,$6), a, b), rotation), xorig, yorig),3006);else result = st setsrid(st makepoint(xorig,yorig),3006);end if;else result = st buffer(st transform(st setsrid(st makepoint($1,$2),4326), 3006), totald-ist/2);end if;RETURN st transform(result, 4326); END;$BODY$LANGUAGE plpgsql VOLATILE;

44

CREATE OR REPLACE FUNCTION get closest node(double precision, double preci-sion)RETURNS bigint AS$BODY$declareinterest point geometry;interest id bigint;begininterest point = st setsrid(st makepoint(1,2),4326);interest id= g1.id FROM ways vertices pgr As g1 where g1.checkit is true ORDER BYthe geom < − > interest point LIMIT 1;return interest id;end;$BODY$LANGUAGE plpgsql VOLATILE;

45

Appendix B: Considered origins and destinations

Table 7 The origins and destinations used in performance tests. The first digit representsthe origin and the second digit represents the offset, e.g., 51 is the destination that is 1km away from the origin 5

Index Latitude Longitude1 59.355272 17.98325911 59.364455 17.98270212 59.373784 17.98177713 59.382412 17.98138814 59.391406 17.98126515 59.400263 17.9784482 59.345808 18.0717521 59.352047 18.08651322 59.358059 18.10087923 59.363422 18.11619224 59.36786 18.13050325 59.371917 18.1457833 59.343985 18.05551431 59.342673 18.03777932 59.342364 18.01982133 59.344161 17.99953534 59.333881 17.98715135 59.331223 17.9702344 59.324752 18.06992541 59.315777 18.07241942 59.307029 18.07636743 59.298516 18.08184744 59.288075 18.08219745 59.279621 18.0842695 59.314888 18.0731151 59.31399 18.05514152 59.31441 18.03788453 59.314527 18.01997154 59.305284 18.00518155 59.302146 17.98783

46

Appendix C: Performance measurements

Table 8 Performance measurements for computing the ellipse.Dist O D (m) Av t (h) Avg. (ms) Std. Dev. (ms) Med. (ms)0 0.5 13.0 26.3 1.20 1 1.1 0.2 1.20 1.5 1.2 0.3 1.20 2 15.4 31.4 1.30 2.5 1.2 0.1 1.20 3 1.9 1.2 1.31000 0.5 2.5 2.5 1.31000 1 1.2 0.3 1.11000 1.5 1.3 0.1 1.31000 2 1.3 0.3 1.41000 2.5 1.3 0.3 1.31000 3 6.2 9.8 1.32000 0.5 0.6 0.0 0.72000 1 1.4 0.1 1.32000 1.5 3.4 4.5 1.42000 2 15.4 31.4 1.42000 2.5 1.9 1.2 1.42000 3 1.3 0.2 1.43000 0.5 0.6 0.0 0.63000 1 1.2 0.2 1.33000 1.5 1.3 0.1 1.33000 2 15.2 31.1 1.43000 2.5 15.6 32.0 1.53000 3 1.4 0.3 1.34000 0.5 0.6 0.0 0.64000 1 0.7 0.1 0.74000 1.5 1.3 0.1 1.34000 2 1.3 0.1 1.34000 2.5 15.6 31.9 1.44000 3 4.1 6.2 1.45000 0.5 0.6 0.0 0.65000 1 14.8 31.6 0.75000 1.5 1.2 0.2 1.25000 2 1.6 0.7 1.35000 2.5 1.3 0.2 1.35000 3 1.3 0.2 1.3

47

Table 9 Performance measurements for finding the closest node to the destination.Dist O D (m) Av t (h) Avg. (ms) Std. Dev. (ms) Med. (ms)0 0.5 1.4 0.9 1.40 1 0.6 0.6 0.10 1.5 0.6 0.6 0.10 2 0.7 0.7 0.10 2.5 0.6 0.6 0.10 3 0.7 0.7 0.21000 0.5 0.7 0.6 0.11000 1 1.4 0.7 1.41000 1.5 0.6 0.6 0.11000 2 0.7 0.7 0.11000 2.5 0.7 0.6 0.21000 3 0.7 0.7 0.12000 0.5 0.6 0.6 0.22000 1 0.6 0.6 0.12000 1.5 6.9 0.7 9.62000 2 14.2 0.6 30.52000 2.5 0.6 0.6 0.12000 3 1.5 0.6 2.03000 0.5 0.6 0.6 0.13000 1 0.6 0.6 0.13000 1.5 2.5 0.6 4.43000 2 0.6 0.6 0.13000 2.5 14.9 0.6 31.53000 3 0.6 0.6 0.04000 0.5 7.3 4.5 7.64000 1 0.6 0.6 0.04000 1.5 0.7 0.6 0.24000 2 0.6 0.6 0.14000 2.5 0.6 0.6 0.14000 3 1.9 0.6 2.95000 0.5 3.3 0.9 5.05000 1 0.6 0.5 0.15000 1.5 19.4 12.3 29.25000 2 0.6 0.6 0.15000 2.5 2.3 0.6 3.85000 3 1.6 0.6 2.3

48

Table 10 Performance measurements for extracting the subnetwork.Dist O D (m) Av t (h) Avg. (ms) Std. Dev. (ms) Med. (ms)0 0.5 80.2 32.7 82.60 1 118.5 28.1 105.00 1.5 180.3 35.8 197.90 2 294.9 53.5 299.70 2.5 311.6 44.4 303.40 3 515.8 256.8 404.31000 0.5 38.4 34.0 32.81000 1 90.9 15.1 94.71000 1.5 163.7 52.4 163.01000 2 380.7 233.9 292.21000 2.5 353.1 56.8 355.61000 3 501.1 72.2 500.52000 0.5 0.5 0.0 0.52000 1 94.3 4.4 94.82000 1.5 381.3 398.1 201.42000 2 274.0 74.8 291.52000 2.5 366.3 67.3 400.82000 3 473.2 65.0 483.63000 0.5 0.5 0.1 0.53000 1 52.1 35.5 63.13000 1.5 230.4 26855.9 228.93000 2 261.1 102.4 284.03000 2.5 323.6 111.1 311.13000 3 452.3 59.7 482.44000 0.5 0.6 0.2 0.54000 1 0.6 0.0 0.64000 1.5 131.6 65.3 126.04000 2 244.6 80.5 288.14000 2.5 322.7 99.5 381.54000 3 423.7 95.1 484.85000 0.5 0.5 0.0 0.55000 1 0.5 0.1 0.55000 1.5 58.7 30.2 48.65000 2 247.2 104.2 245.65000 2.5 316.7 72.5 304.95000 3 411.2 69.9 418.7

49

Table 11 Performance measurements for running the shortest path tree algorithm.Dist O D (m) Av t (h) Avg. (ms) Std. Dev. (ms) Med. (ms)0 0.5 6243.5 767.7 6609.10 1 13646.0 2390.5 14314.40 1.5 23403.1 4860.7 23108.30 2 34995.9 8293.4 35090.70 2.5 46598.6 9111.5 46489.70 3 60894.2 8754.0 62295.11000 0.5 5726.4 632.7 5957.61000 1 12835.2 2231.5 13423.31000 1.5 22859.4 5618.2 24605.01000 2 35555.4 9828.2 38557.91000 2.5 48133.7 11984.0 50909.31000 3 62128.4 9791.1 65757.02000 0.5 0.0 0.0 0.02000 1 10658.4 1824.0 11699.32000 1.5 21904.3 5970.1 21990.32000 2 33119.4 9698.4 34481.82000 2.5 45467.7 11366.8 49272.32000 3 58769.7 10081.5 61076.83000 0.5 0.0 0.0 0.03000 1 7623.4 2104.7 7075.43000 1.5 17976.0 4894.1 18509.63000 2 29908.1 8555.7 30989.53000 2.5 43920.9 11917.0 46103.23000 3 57483.2 11236.0 58896.14000 0.5 0.0 0.0 0.04000 1 0.0 0.0 0.04000 1.5 14863.0 4225.7 15396.24000 2 26776.2 8154.8 29475.84000 2.5 41391.4 11570.1 44001.84000 3 55623.0 14284.9 60689.25000 0.5 0.0 0.0 0.05000 1 0.0 0.0 0.05000 1.5 8305.7 2443.2 8987.25000 2 22439.6 6491.1 24897.25000 2.5 37117.1 10676.0 41059.95000 3 52962.6 14763.6 55412.9

50

Table 12 Performance measurements for total computation time on the server.Dist O D (m) Av t (h) Avg. (ms) Std. Dev. (ms) Med. (ms)0 0.5 6338.1 765.0 6690.60 1 13766.2 2363.7 14413.80 1.5 23585.2 4870.5 23228.60 2 35306.8 8266.4 35302.80 2.5 46911.9 9147.6 46794.80 3 61412.6 8931.4 62689.51000 0.5 5767.9 626.1 5969.71000 1 12928.7 2233.2 13507.91000 1.5 23025.0 5662.0 24771.11000 2 35938.1 9983.1 38851.81000 2.5 48488.9 12033.6 51267.31000 3 62636.3 9729.3 66215.92000 0.5 1.8 0.1 1.82000 1 10754.8 1828.1 11796.32000 1.5 22295.9 6304.1 22201.52000 2 33423.1 9771.0 34775.22000 2.5 45836.5 11427.4 49714.32000 3 59245.7 10145.4 61562.43000 0.5 1.8 0.1 1.83000 1 7677.3 2106.6 7165.03000 1.5 6208.4 27006.1 13551.13000 2 30185.0 8631.2 31275.63000 2.5 44275.0 12006.6 46486.73000 3 57937.4 11294.0 59380.44000 0.5 8.5 7.7 5.64000 1 1.9 0.1 1.84000 1.5 14996.6 4284.0 15506.84000 2 27022.7 8227.8 29773.54000 2.5 41730.3 11679.9 44385.14000 3 56052.7 14373.4 61176.05000 0.5 4.5 5.0 2.05000 1 15.9 31.7 1.85000 1.5 8385.0 2472.1 9052.05000 2 22689.0 6569.7 25290.15000 2.5 37437.4 10738.0 41366.75000 3 53376.6 14800.7 55822.2

51

Table 13 Measurements to determine the effect of the available time and distance be-tween origin and destination on the number of nodes in the subnetwork.

Dist O D (m) Av t (h) Avg. Std. Dev. Med.0 0.5 1682.0 388.2 1849.00 1 5300.2 1124.8 5465.00 1.5 10257.2 2414.0 10215.00 2 15973.2 4022.8 16061.00 2.5 21712.6 4391.5 21749.00 3 28228.6 4059.9 28604.01000 0.5 1419.5 342.5 1534.51000 1 5011.3 1109.7 5259.51000 1.5 10050.0 2820.7 10937.01000 2 16343.0 4919.3 17939.01000 2.5 22393.3 5593.5 23954.51000 3 28801.5 5060.0 30270.02000 0.5 0.0 0.0 0.02000 1 3878.4 882.2 4240.02000 1.5 8807.0 2543.3 9011.02000 2 14927.6 4501.0 15830.02000 2.5 21139.8 5539.7 22306.02000 3 27617.2 5185.7 28327.03000 0.5 0.0 0.0 0.03000 1 2321.4 1027.4 2087.03000 1.5 7494.2 2264.9 7857.03000 2 13422.8 4279.8 14061.03000 2.5 20331.0 5810.6 21427.03000 3 26873.0 5930.9 27690.04000 0.5 0.0 0.0 0.04000 1 0.0 0.0 0.04000 1.5 5676.0 1906.1 6364.04000 2 11896.4 3964.1 13374.04000 2.5 18976.2 5566.5 20550.04000 3 25918.2 6836.0 27690.05000 0.5 0.0 0.0 0.05000 1 0.0 0.0 0.05000 1.5 2770.6 1255.7 3087.05000 2 9840.0 3235.3 11011.05000 2.5 16916.2 5163.7 18711.05000 3 24293.0 7055.6 26026.0

52

Table 14 Measurements to determine the effect of the available time and distance be-tween origin and destination on the number of edges sent to the client.

Dist O D (m) Av t (h) Avg. Std. Dev. Med.0 0.5 2145.8 602.1 2455.00 1 6802.6 1641.4 7111.00 1.5 13255.2 3391.8 13309.00 2 20530.0 5455.3 20842.00 2.5 27629.2 5829.2 27700.00 3 35691.4 5458.2 36086.01000 0.5 1793.8 573.3 2033.01000 1 6438.0 1672.1 6882.01000 1.5 12915.3 3927.9 14132.01000 2 20909.0 6677.6 23099.51000 2.5 28416.5 7516.3 30513.51000 3 36428.3 6765.7 38373.52000 0.5 0.0 0.0 0.02000 1 4955.8 1301.1 5508.02000 1.5 11265.2 3443.7 11673.02000 2 19055.6 6017.5 20071.02000 2.5 26884.4 7340.0 28290.02000 3 35016.0 6844.8 35837.03000 0.5 0.0 0.0 0.03000 1 2912.8 1416.8 2716.03000 1.5 9509.0 3045.8 10211.03000 2 17042.8 5694.3 17673.03000 2.5 25835.0 7732.1 27133.03000 3 34102.4 7816.3 35117.04000 0.5 0.0 0.0 0.04000 1 0.0 0.0 0.04000 1.5 7120.8 2553.0 8038.04000 2 15032.2 5212.1 16898.04000 2.5 24122.6 7454.8 25991.04000 3 32913.4 8975.6 35139.05000 0.5 0.0 0.0 0.05000 1 0.0 0.0 0.05000 1.5 3440.0 1711.9 3997.05000 2 12360.8 4274.9 13799.05000 2.5 21445.4 6847.0 23560.05000 3 30804.8 9250.4 33014.0

53

Table 15 Performance measurements for reading the server’s response and generatingthe network topology.

Read subnetwork Generate topology# edges Avg. (s) Std. Dev. (s) Med. (s) Avg. (s) Std. Dev. (s) Med. (s)1000 4.6 0.9 4.7 2.2 0.2 2.32000 6.3 0.2 6.3 4.3 0.4 4.13000 9.5 0.0 9.5 5.9 0.3 5.84000 13.3 0.9 13.0 8.1 0.4 8.05000 16.1 0.3 16.2 10.0 0.2 10.06000 20.2 1.4 19.6 12.1 0.1 12.07000 23.0 0.8 22.8 14.2 0.5 14.08000 26.0 0.2 25.9 15.9 0.4 15.79000 29.3 0.5 29.3 17.8 0.1 17.810000 36.3 6.4 33.5 20.4 1.1 20.311000 35.9 0.9 35.7 22.1 0.2 22.212000 39.2 0.6 39.4 23.5 0.4 23.613000 51.6 16.6 44.4 30.5 10.5 25.414000 56.2 18.1 47.5 32.4 10.9 27.115000 50.2 1.9 51.6 29.9 1.0 29.516000 52.6 1.3 51.7 32.0 1.2 32.017000 56.1 1.4 55.7 33.6 1.2 33.118000 59.3 1.1 58.9 35.1 0.6 35.219000 62.8 0.8 62.7 37.6 0.9 37.820000 66.0 1.3 66.0 39.8 1.0 39.721000 69.6 1.9 69.7 42.3 1.5 41.822000 74.3 3.0 73.7 44.5 1.3 44.523000 77.0 3.2 75.9 46.5 1.9 46.324000 79.4 1.0 79.6 46.7 0.6 46.725000 83.0 1.1 82.9 50.1 3.3 49.326000 87.7 1.9 87.0 52.2 3.2 50.927000 89.7 2.0 89.0 55.7 1.8 55.528000 92.2 0.9 92.3 56.3 0.8 56.529000 95.3 1.4 95.4 59.8 2.1 60.030000 100.4 1.9 100.9 60.7 2.2 61.6

54

Table 16 Performance measurements for building the indexes and total computation timeon the client.

Build index Total time# edges Avg. (s) Std. Dev. (s) Med. (s) Avg. (s) Std. Dev. (s) Med. (s)1000 2.5 0.3 2.4 9.3 1.2 10.02000 4.6 0.2 4.7 15.2 0.4 15.13000 6.9 0.2 6.9 22.3 0.4 22.24000 9.5 0.2 9.5 30.9 0.6 30.75000 12.1 0.4 12.0 38.2 0.6 38.36000 15.0 1.0 14.9 47.3 1.0 47.37000 16.5 0.7 16.5 53.7 1.0 53.98000 18.5 0.2 18.6 60.3 0.7 60.19000 21.7 0.6 21.6 68.8 0.7 68.910000 22.3 0.1 22.3 79.0 7.3 75.511000 25.4 1.0 25.3 83.4 1.6 83.512000 33.1 9.1 29.1 95.8 8.3 92.613000 36.1 12.1 30.3 118.2 39.1 100.014000 38.4 12.1 33.1 127.1 41.0 107.215000 33.6 1.4 33.3 113.7 1.4 114.116000 36.5 1.0 36.2 121.1 2.0 120.417000 39.1 1.7 39.5 128.7 2.0 129.218000 40.6 0.9 40.9 135.0 1.4 134.919000 41.9 2.1 41.8 142.3 3.4 140.120000 45.1 1.2 45.3 151.0 2.5 151.021000 47.8 1.1 48.0 159.7 2.5 158.622000 49.9 5.0 48.8 168.6 6.9 167.023000 50.0 2.4 49.3 173.5 3.1 172.824000 53.0 2.1 53.2 179.1 2.8 179.125000 54.2 2.5 53.4 187.3 5.8 185.226000 56.8 2.4 56.4 196.7 2.8 196.627000 59.4 3.6 61.6 204.8 4.1 204.728000 60.6 2.0 60.3 209.2 3.4 209.329000 61.5 1.6 61.2 216.6 3.2 215.930000 62.5 3.9 61.5 223.6 6.3 222.6

55

Appendix D: osm2pgrouting mapconfig file

Listing 1: Configuration file used by the osm2pgrouting import - part I1 <?xml v e r s i o n =” 1 . 0 ” e n c o d i n g =”UTF−8” ?>2 <c o n f i g u r a t i o n>3 <t y p e name=” f o o t ” i d =” 2 ”>4 <c l a s s name=” yes ” i d =” 201 ” />5 <c l a s s name=” d e s i g n a t e d ” i d =” 202 ” />6 < / t y p e>7 <t y p e name=” r o u t e ” i d =” 8 ”>8 <c l a s s name=” f e r r y ” i d =” 801 ” />9 <c l a s s name=” bus ” i d =” 802 ” />

10 <c l a s s name=” b i c y c l e ” i d =” 803 ” />11 <c l a s s name=” t r a i n ” i d =” 804 ” />12 <c l a s s name=” subway ” i d =” 805 ” />13 <c l a s s name=” r a i l ” i d =” 806 ” />14 <c l a s s name=” t ram ” i d =” 807 ” />15 < / t y p e>16 <t y p e name=” highway ” i d =” 1 ”>17 <c l a s s name=” motorway ” i d =” 101 ” />18 <c l a s s name=” m o t o r w a y l i n k ” i d =” 102 ” />19 <c l a s s name=” m o t o r w a y j u n c t i o n ” i d =” 103 ” />20 <c l a s s name=” t r u n k ” i d =” 104 ” />21 <c l a s s name=” t r u n k l i n k ” i d =” 105 ” />22 <c l a s s name=” p r i m a r y ” i d =” 106 ” />23 <c l a s s name=” p r i m a r y l i n k ” i d =” 107 ” />24 <c l a s s name=” s e c o n d a r y ” i d =” 108 ” />25 <c l a s s name=” t e r t i a r y ” i d =” 109 ” />26 <c l a s s name=” r e s i d e n t i a l ” i d =” 110 ” />27 <c l a s s name=” l i v i n g s t r e e t ” i d =” 111 ” />28 <c l a s s name=” s e r v i c e ” i d =” 112 ” />29 <c l a s s name=” t r a c k ” i d =” 113 ” />30 <c l a s s name=” p e d e s t r i a n ” i d =” 114 ” />31 <c l a s s name=” s e r v i c e s ” i d =” 115 ” />32 <c l a s s name=” b u s s t o p ” i d =” 116 ” />33 <c l a s s name=” p a t h ” i d =” 117 ” />34 <c l a s s name=” cyc leway ” i d =” 118 ” />35 <c l a s s name=” foo tway ” i d =” 119 ” />36 <c l a s s name=” b r i d l e w a y ” i d =” 120 ” />37 <c l a s s name=” byway ” i d =” 121 ” />38 <c l a s s name=” s t e p s ” i d =” 122 ” />39 <c l a s s name=” u n c l a s s i f i e d ” i d =” 100 ” />40 < / t y p e>

56

Listing 2: Configuration file used by the osm2pgrouting import - part II1 <t y p e name=” cyc leway ” i d =” 2 ”>2 <c l a s s name=” l a n e ” i d =” 201 ” />3 <c l a s s name=” t r a c k ” i d =” 202 ” />4 <c l a s s name=” o p p o s i t e l a n e ” i d =” 203 ” />5 <c l a s s name=” o p p o s i t e ” i d =” 204 ” />6 < / t y p e>7 <t y p e name=” t r a c k t y p e ” i d =” 3 ”>8 <c l a s s name=” g r ad e 1 ” i d =” 301 ” />9 <c l a s s name=” g r ad e 2 ” i d =” 302 ” />

10 <c l a s s name=” g r ad e 3 ” i d =” 303 ” />11 <c l a s s name=” g r ad e 4 ” i d =” 304 ” />12 <c l a s s name=” g r ad e 5 ” i d =” 305 ” />13 < / t y p e>14 <t y p e name=” j u n c t i o n ” i d =” 4 ”>15 <c l a s s name=” r o u n d a b o u t ” i d =” 401 ” />16 < / t y p e>17 < / c o n f i g u r a t i o n>

57

Reports in Geodesy and Geographic Information Technology

The TRITA-GIT Series - ISSN 1653-5227

14-001 Muhammad Zaheer. Kinematic orbit determination of low Earth orbiting satellites, using satellite-

to-satellite tracking data. Master of Science thesis in Geodesy No. 3130. Supervisor: Milan

Horemuž. March 2014.

14-002 Razmik Agampatian. Using GIS to measure walkability: A Case study in New York City. Master

of Science thesis in Geoinformatics. Supervisor: Hans Hauska. April 2014.

14-003 Solomon Dargie Chekole. Surveying with GPS, total station and terresterial laser scaner: a

comparative study. Master of Science thesis in Geodesy No. 3131. Supervisor: Milan Horemuž and

Erick Asenjo. May 2014.

14-004 Linda Fröjse. Unsupervised Change Detection Using Multi-Temporal SAR Data - A Case Study of

Arctic Sea Ice. Master of Science thesis in Geoinformatics. Supervisors: Yifang Ban och Osama A.

Yousif. June 2014.

14-005 Can Yang. Multi-Agent Simulation to Evaluate Sustainability of Cities. Master of Science thesis in

Geoinformatics. Supervisors: Yifang Ban and Mats Dunkars. June 2014.

14-006 Caroline Ivarsson. Combining Street View and Aerial Images to Create Photo-Realistic 3D City

Models. Master of Science thesis in Geoinformatics. Supervisors: Yifang Ban and Helén Rost. June

2014.

14-007 Adrian Corneliu Prelipcean. Implementation and evaluation of Space Time Alarm Clock. Master

of Science thesis in Geoinformatics. Supervisors: Takeshi Shirabe and Falko Schmid. June 2014.

TRITA-GIT EX 14-007

ISSN 1653-5227

ISRN KTH/GIT/EX--14/007-SE