Enhancing Parking Behavior Detectionkth.diva-portal.org/smash/get/diva2:1085169/FULLTEXT01.pdfAbstract A review of navigation systems nowadays shows that new features are required

IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Enhancing Parking Behavior Detection

TEODORA ANITOAEI

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING

Enhancing Parking Behavior Detection

Master of Science - Major Thesis

Teodora Anitoaei

Supervisor: Gabriel Hjort BlindellExaminer: Christian SchulteStockholm 31st October 2016

ICT Innovation - Embedded SystemsSchool of Information and Communication Technology

KTH Royal Institute of Technology

TRITA-ICT-EX-2016:104

c�Teodora Anitoaei, 31st October 2016

Abstract

A review of navigation systems nowadays shows that new features are requiredin the automotive field. One such feature is suggesting a parking space within apositioning system. In the new global context of navigation, finding a parkingplace has become a central issue for all drivers. The research question for thisstudy is what happens when you get to the destination or when you don’t needto use a GPS to arrive to your destination? This thesis has two major purposes:(1) to investigate an e�cient solution for detecting the parking behavior of amoving car; (2) to implement and integrate an environment-friendly solutionfor HERE in a way that would give the company a competitive edge.

By examining only the latitude and longitude from all the input GPS datareceived in a navigation system, the author defines the best configuration for aparking detection algorithm. Once the best configuration was found, an imple-mentation was proposed. An extensive series of tests has been carried out onthe final implementation. Data for tests was obtained using internal tools fromHERE for producing di↵erent testing routes as navigation files (.nmea files).Creating the input files manually o↵ers flexibility and gives the opportunity totouch all the unexpected behaviors, knowing the expected result in any case.

The results obtained from the analysis of the algorithm are encouraging.It has been shown that the configuration chosen for implementation is cheapand e↵ective in predicting parking behavior. In conclusion, the implementa-tion of the algorithm was successfully integrated with the existing HERE SDK.The new feature will be available for the following three automotive companies:Audi, BMW, and Daimler. The algorithm is designed such that it can be easilyextended and improved. Future work might include adding parameters thatshould be adjustable by the user or client like speed of the car.

Keywords: Haversine, navigation, parking, positioning, location

i

Sammanfattning

En genomgang av nutida navigationssystem visar att nya funktioner kravs forfordonsomradet. En sadan funktion ar att foresla en parkeringsplats inom ettpositioneringssystem. I det nya globala sammanhanget for navigering har prob-lemet att hitta en pa parkeringsplats blivit en central fraga for alla forare.Fragestallningen for denna studie ar vad som hander nar du kommer till desti-nationen eller nar du inte behover anvanda en GPS for att komma fram till dindestination? Denna avhandling har tva huvudsakliga syften: (1) att undersokaen e↵ektiv losning for detektering av parkeringsbeteende hos en bil som ror sig;(2) att genomfora och integrera en miljovanlig losning for HERE pa ett sattsom skulle ge bolaget en konkurrensfordel.

Genom att endast undersoka latitud och longitud fran all GPS-indata sommottags i ett navigationssystem definierar forfattaren den basta konfiguratio-nen for en parkeringdetekteringsalgoritm. Nar val den basta konfigurationenfunnits foreslots ett genomforande. En omfattande serie tester har utforts padet slutliga genomforandet. Data for prov erholls med hjalp av interna verktygfran HERE for att producera olika provvagar som navigationsfiler (.nmea filer).Att skapa indatafiler manuellt erbjuder flexibilitet och ger mojlighet att vidroraalla ovantade beteenden, for att veta det forvantade resultatet i vilket fall somhelst.

De resultat som erhallits fran analysen av algoritmen ar uppmuntrande. Dethar visats att konfigurationen som valts for genomforandet ar billig och e↵ektivi att forutsaga parkeringsbeteende. Sammanfattningsvis har genomforandet avalgoritmen framgangsrikt integrerats med den befintliga HERE SDK:n. Dennya funktionen kommer att finnas tillganglig for foljande tre bilforetag: Audi,BMW och Daimler. Algoritmen ar utformad sa att den latt kan utvidgas ochforbattras. Framtida arbete kan omfatta att lagga till parametrar som bor varainstallningsbara av anvandaren eller kunden som till exmpel hastigheten pabilen.

Nyckelord: Haversine, navigation, parkering, positionering, lokalisering

iii

Acknowledgments

I would like to express my gratitude to my examiner Christian Schulte and tomy supervisor Gabriel Hjort Blindell for all the useful comments, remarks andengagement through the learning process of this master thesis. Furthermore Iwould like to thank the software company HERE for introducing me to the topicas well for the support on the way. I would like to thank my loved ones, whohave supported me throughout entire process, both by keeping me harmoniousand helping me putting pieces together.

v

List of Acronyms andAbbreviations

This document requires readers to be familiar with terms and concepts. Forclarity we summarize some of these terms and give a short description of thembefore presenting them in next sections.

GPS Global Positioning System

SDK Software Development Kit

NMEA National Marine Electronics Association

GPX Global Positioning System Exchange Format

JSON JavaScript Object Notation

PDA Parking Detector Algorithm

GNSS Global Navigation Satellite System

DT Driven Track

OT Optimal Track

R Ratio

C Cost

T Threshold

TT Target Tracking

GPSD Global Positioning System Daemon

API Application Program Interface

APP Application Layer

TDD Test Driven Development

HCVD Hybrid Components and Vehicle Data

ETA Estimated Time of Arrival

vii

Contents

1 Introduction 11.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Ethics and Sustainability . . . . . . . . . . . . . . . . . . . . . . 21.6 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.8 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.9 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . 31.10 About HERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 52.1 Navigation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 NMEA files . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 GPX files . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 JSON files . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4 GPSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Navigation Formulas . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Haversine Formula . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Law of Cosines Formula . . . . . . . . . . . . . . . . . . . 112.2.3 Equirectangular Approximation Formula . . . . . . . . . . 12

2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Method 153.1 Parking Detection Algorithm (PDA) . . . . . . . . . . . . . . . . 153.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Results and Analysis 294.1 Notations and Values . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . 344.4 Discussion of classification results and error cases . . . . . . . . . 34

4.4.1 False positives . . . . . . . . . . . . . . . . . . . . . . . . 344.4.2 False negatives . . . . . . . . . . . . . . . . . . . . . . . . 37

ix

5 Conclusions 395.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A Final Results for Haversine Haversine configurations 41

B Configurations Graphs Comparisons 49

C PDA Code 53

D PDA Integration Test 67

Bibliography 72

List of Figures

2.1 Waypoints, Routes, and Tracks recorded by GPS receivers . . . . 82.2 GPSD - Dataflow View . . . . . . . . . . . . . . . . . . . . . . . 92.3 Spherical triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Comparison between Law of Cosines and Haversine Formulas . . 132.5 Ratios of Law of Cosines and Haversine Formula . . . . . . . . . 13

3.1 Parking Detection Algorithm Flow . . . . . . . . . . . . . . . . . 163.2 CarloControlPanel User Interface . . . . . . . . . . . . . . . . . . 173.3 Example of input file - Visualization . . . . . . . . . . . . . . . . 183.4 Driven track vs. Optimal track . . . . . . . . . . . . . . . . . . . 193.5 Carlo Package Overview . . . . . . . . . . . . . . . . . . . . . . . 203.6 CarloControlPanel Tool Package . . . . . . . . . . . . . . . . . . 213.7 Navcore Components . . . . . . . . . . . . . . . . . . . . . . . . . 223.8 PDA Components . . . . . . . . . . . . . . . . . . . . . . . . . . 233.9 UML Diagram for Parking Detector Algorithm . . . . . . . . . . 253.10 Sequence Diagram for Parking Detector Algorithm . . . . . . . . 263.11 PDA Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Algorithm Configurations . . . . . . . . . . . . . . . . . . . . . . 304.2 Algorithm Test Files . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Red Segment - Track Start Problems . . . . . . . . . . . . . . . . 354.4 Red Segment - Map Matching Problems . . . . . . . . . . . . . . 354.5 Red Segment - Wrong Annotation . . . . . . . . . . . . . . . . . 364.6 Red Segment - Unknown . . . . . . . . . . . . . . . . . . . . . . . 36

B.1 Haversine vs HereAPI - 400m . . . . . . . . . . . . . . . . . . . . 49B.2 Haversine vs HereAPI - 500m . . . . . . . . . . . . . . . . . . . . 50B.3 Haversine vs HereAPI - 600m . . . . . . . . . . . . . . . . . . . . 50B.4 Haversine vs HereAPI - 700m . . . . . . . . . . . . . . . . . . . . 51B.5 Haversine vs HereAPI - 800m . . . . . . . . . . . . . . . . . . . . 51

xi

List of Tables

4.1 Configuration 1 for test file 1 . . . . . . . . . . . . . . . . . . . . 33

A.1 Final Results for algorithm configuration ”Haversine Haversine 400 800 1200”and di↵erent parameters . . . . . . . . . . . . . . . . . . . . . . . 41

A.2 Final Results for algorithm configuration ”Haversine Haversine 500 1000 1500”and di↵erent parameters . . . . . . . . . . . . . . . . . . . . . . 42




xiii

List of Code

2.1 $GPGGA sentence decoding . . . . . . . . . . . . . . . . . . . . . 62.2 GPX File Example . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Haversine Formula implemented in C++ . . . . . . . . . . . . . . 102.4 Equirectangular Formula implemented in Python . . . . . . . . . 123.1 SimpleClassifier implemented in Python . . . . . . . . . . . . . . 16C.1 PDA API header implemented in C++ . . . . . . . . . . . . . . 53C.2 PDA API source code implemented in C++ . . . . . . . . . . . . 55C.3 PDA Implementation Header in C++ . . . . . . . . . . . . . . . 57C.4 PDA Implementation Source Code in C++ . . . . . . . . . . . . 59D.1 PDA Integration Test Code in C++ . . . . . . . . . . . . . . . . 67

xv

Chapter 1

Introduction

This chapter first gives a short introduction into the general problem and theproblem statement, followed by an overview of the goals, purpose, methodology,delimitations and motivation of this study. The last part is concerned with theoutline for the thesis.

1.1 Problem

Parking management is a common condition which has considerable impacton people driving every day. Parking management is frequently described as:search time and cost for parking spaces, parking revenue, and tra�c congestion.Evidence suggests that distance wasted on detecting the available parking spacesis more than 4 kilometers per parking attempt, so an average of 10 minutes [24].Drivers will keep on circling the parking area until they found an empty parkingspot. This problem usually occurs in urban areas, where the number of vehiclesis higher as compared to the availability of parking spaces. These ine↵ectiveconditions happened because of the lack of technology, available on the markettoday, for detecting parking behavior.

In recent years, there has been an increasing amount of problems on findinga parking space, especially in the big cities. Recent research explains that over30% of the tra�c in the city centers of medium and larger cities is due to peoplelooking for a parking space [2]. Creating parking places makes it more attractiveto drive, so streets are at their capacity, worsening tra�c and delaying transitservice. Lack of parking spaces not only generates tra�c, but also degrades thequality of neighborhoods. On one hand, there are so many cars that is nearlyimpossible to build great urban places. On the other hand, it has conclusivelybeen shown that parking makes housing less a↵ordable, because a parking spaceadds a significant amount of money to the cost of an apartment or a house [2].

According to studies done by Siemens [23], it can be said that every cardriver wastes on average 100 hours a year looking for a parking space and causesone third of tra�c, especially in city centers and around 30 percent of driversare searching for a parking space in overcrowded city centers. Every year, thedistance covered in each district of a big city is equivalent to 14 trips aroundthe world [24].

1

1.2 Problem Statement

Thanks to technologies like smart-phones, GPS systems, or in-car navigationsystems, finding the way has never been easier with access to tra�c conditions,travel time, and directions. The research question for this study is about whathappens when you get to the destination or when you don’t need to use a GPSto arrive to your destination? In the new global context, finding a parking placehas become a central issue for all drivers. Despite this, directions skip over thislast, very important step: suggesting a parking space.

Parking is an important aspect of navigation. Several attempts on navigationtools nowadays are adding the necessary condition of knowing the destination.Extensive research has been carried out on car navigation systems that o↵ersassistance in parking when the driver approaches the predicted destination.However, the fact is that most of the drivers don’t need directions to go homeor to work, but no study exists which detects parking search behavior if thedestination is unknown.

1.3 Goals

The primary goals of this thesis project are:1. Present a cheap and e�cient algorithm for predicting parking space search

behavior;2. Evaluate all the possible configurations of the algorithm in order to choose

the best one for the final application;3. Design and implement the best configuration to be integrated in the

HERE SDK.

1.4 Purpose

The results from this thesis and the actual implementation will be available inthe new features of 2017 for the following three automotive companies: Audi,BMW, and Daimler. The proposed solution is integrated in the HERE SDKand should be delivered as an integrated component from the software company.The findings are already patented by HERE and the research should make animportant contribution to the field of automotive navigation.

1.5 Ethics and Sustainability

The proposed solution shall protect the user’s privacy by: not requiring a finaldestination point; not storing more than two kilometers of the traveled routeduring software runtime and discarding them at shutdown; not collecting ordisclosing user’s personal information to any external entities.

The chosen implementation shall lead the way to a sustainable future by:reducing the number of kilometers traveled while searching for a parking place;reducing the tra�c in crowded cities; keeping the car’s used resources to aminimum;

2

1.6 Research Methodology

This thesis has adopted the quantitative research method, as the focus is on theevaluation of all possible configurations for the algorithm proposed as a solutionfor predicting space search behavior.

1.7 Delimitations

A primary concern of this project is detecting parking search behavior withoutknowing the destination. Traditionally, this kind of behavior might still beinferred from driving patterns. A full discussion of which criteria might beavailable and how well they may predict parking search behavior lies beyondthe scope of this study. The reader should bear in mind that the study is basedon examining one research question: how to detect parking search behavioronly knowing the traveled GPS trace, more specific only pairs of latitude andlongitude, logged in the system.

1.8 Motivation

This project was conceived during my time working for HERE - a software com-pany owned by leading automotive companies: Audi, BMW, and Daimler (andwas formerly owned by Nokia, until December 2015) [22] that brings togethermapping and location businesses under one brand. HERE captures locationcontent such as road networks, buildings, parks and tra�c patterns [15].

My main reason for choosing this topic is based on the work developed inthe same area with three di↵erent roles that I played in the company: workingstudent, intern student, and master thesis student, in a time frame of one year.

1.9 Structure of the thesis

The thesis will be organized as a one-person project. The present researchexplores the current findings from HERE about parking search behavior andinvestigates only one of the features, creating an algorithm and discovering thebest parameters to run the final application.

Thesis Outline: Chapter 1 introduces the problem and gives an overview ofthe context of this thesis. Chapter 2 further describes the idea of this thesisand provides the information needed to understand the problem and solution.Related work and competing solutions are also discussed. The goals and themethods of this study are discussed in chapter 3. Chapter 4 provides the resultsobtained with the methods presented in chapter 3 and an analysis of the work,explaining how it can be used and extended. Finally, chapter 5 evaluates thegoals of this study and gives final remarks.

1.10 About HERE

HERE is a web mapping service developed originally in Navteq, an Americancompany founded in 1985. The company was acquired by Nokia (a Finnish

3

telecommunication firm). It o↵ers street maps, satellite imagery, real-timetra�c conditions, route planning for traveling by foot, bicycle, car and pub-lic transportation. It then sells or licenses that mapping content, along withnavigation services and location solutions to other businesses such as Alpine,Garmin, BMW, Oracle and Amazon.com. In addition, HERE provides platformservices to many mobile devices operating systems, online or o✏ine. It deliverslocation services through HERE applications, provides solutions for GIS andgovernment clients and powers major mapping providers, such as Bing, Face-book and (formerly) Yahoo! Maps [7]. HERE has maps in nearly 200 countries,o↵ers voice guided navigation in 94 languages, provides live tra�c informationin 33 countries and has indoor maps available for about 49,000 unique buildingsin 45 countries [16]. As of December 2015 the company has more than 6500employees.

4

Chapter 2

Background

This chapter provides information about the navigation systems key-terms thatthe reader should have to fully comprehend the rest of this thesis. It will firstgive a high-level overview of navigation systems and explain what it is meantwhen positioning is mentioned. After defining these terms, a high-level overviewof navigation tools and applications is given.

2.1 Navigation Systems

Navigation is the science that focuses on the process of determining position,location, distance traveled, and course to a known destination. In other words,monitoring and controlling the movement of a craft or vehicle from one placeto another. This dissertation aims to unravel one of the mysteries surroundingautomotive navigation systems: detecting parking search behavior of a movingcar.

In general, discussing about an automotive navigation system means a sys-tem based on the Global Positioning System (GPS), including a GPS receiverand audio/video (AV) components designed for a specific purpose such as acar-based/hand-held device or a smart-phone/tablet application. GPS is asatellite-based system used for locating any positions on the globe. The systemis operated by the U.S. Department of Defense (DoD), NAVSTAR (NAViga-tion Satellite Timing and Ranging). GPS provides in real-time and continuous(24 hours/day) a 3-dimensional positioning, navigation and timing worldwide.Any person with a GPS receiver can access the system, and it can be usedfor any application that requires location coordinates (coordinating informationfrom three or four satellite signals). That location includes the position of thesatellite and the precise time of transmission. Having three signals, any 2Dposition can be found on earth; additional satellite signals make it possible tofind altitude. GPS technology works in almost any condition and is accurate towithin 3-15 meters, depending on the number of signals received, the spread ofsatellites in the sky and the technologies used in the receiver [13].

5

2.1.1 NMEA files

One of the input formats used in this study is NMEA data. NMEA is anacronym for the National Marine Electronics Association. An interesting factis that NMEA existed well before GPS was invented. According to the NMEAo�cial website, the association was formed in late ’50s by a group of electronicdealers. The purpose was to create better communications between the nav-igation hardware and software. Nowadays in the world of GPS, NMEA is astandard data format supported by all GPS manufacturers, like ASCII is thestandard for digital computer characters in the computer world.

NMEA can play an important role because it has the power to give equip-ment users the ability to mix and match hardware and software. Each GPSreceiver is di↵erent, and with NMEA-formatted GPS data is easier for soft-ware developers to write software for a wide variety of GPS receivers insteadof having to write a custom interface for each. A good example is VisualGPS(free software), which accepts NMEA-formatted data from any GPS receiverand graphically displays it. Not having a standard such as NMEA, it would betime consuming and expensive to write and maintain such a tool [5].

NMEA 0183 replaces the earlier NMEA 0180 and NMEA 0182 standardsand is a combined electrical and data specification for communication betweenelectronics (echo sounder, sonars, anemometer, gyrocompass, autopilot, GPSreceivers). In marine applications, it is slowly being phased out in favor of thenewer NMEA 2000 standard. The NMEA 0183 standard is a serial communi-cations protocol, that uses a simple ASCII, defining how data are transmittedin a ”sentence” from one ”talker” to multiple ”listeners”. A talker can havean unidirectional conversation with an unlimited number of listeners, and withmultiplexers, multiple sensors can talk to a single computer port. At the ap-plication layer, the standard also defines the contents of each sentence type, sothat all listeners can parse messages accurately [21].

All messages are transmitted in the form of sentences. In these sentences areallowed only printable ASCII characters, plus CR (carriage return) and LF (linefeed). Each sentence starts with a ”$” sign and ends with < CR >< LF >.However, there are a few NMEA messages/sentences and that makes NMEAa bit confusing. Just like there are all kinds of GPS receivers with di↵erentcapabilities, there are many di↵erent types of NMEA messages with di↵erentcapabilities. In addition, NMEA data can be transmitted via di↵erent typesof communications interfaces such as RS-232, USB, Bluetooth, Wi-Fi, UHF,etc. [9]. For this study, only ”GPGGA” sentences are used and a decodingexample is presented in 2.1 [8]. The GGA is a basic GPS NMEA messagewith essential fixed data which provide 3D location and accuracy information,including latitude and longitude. There are alternative and companion NMEAmessages that provide similar or additional information.

1 $GPGGA,123519 ,4807 .038 ,N,01131 . 000 ,E, 1 , 0 8 , 0 . 9 , 5 4 5 . 4 ,M, 4 6 . 9 ,M, ,⇤472

3 Where :4

5 GGA Global Po s i t i on i ng System Fix Data6 123519 Fix taken at 12 : 35 : 19 UTC7 4807 .038 ,N Lat i tude 48 deg 07 .038 ’ N8 01131 .000 ,E Longitude 11 deg 31 .000 ’ E9 1 Fix qua l i t y :

10 0 = i nv a l i d

6

11 1 = GPS f i x (SPS)12 2 = DGPS f i x13 3 = PPS f i x14 4 = Real Time Kinematic15 5 = Float RTK16 6 = est imated ( dead reckon ing ) ( 2 . 3 f e a tu r e )17 7 = Manual input mode18 8 = Simulat ion mode19 08 Number o f s a t e l l i t e s be ing tracked20 0 .9 Hor i zonta l d i l u t i o n o f p o s i t i o n21 545 .4 ,M Alt i tude , Meters , above mean sea l e v e l22 46 . 9 ,M Height o f geo id (mean sea l e v e l )23 above WGS84 e l l i p s o i d24 ( empty f i e l d ) time in seconds s i n c e l a s t DGPS update25 ( empty f i e l d ) DGPS s t a t i o n ID number26 ⇤47 the checksum data , always beg ins with ⇤

Listing 2.1: $GPGGA sentence decoding

2.1.2 GPX files

GPX or GPS Exchange Format is a light-weight XML document designed asa common GPS data format for the interchange data (way-points, routes, andtracks) between softwares and Web services on the Internet. Location data (andoptionally elevation, time, and other information) is stored in tags and can beexchanged between GPS devices and applications. Common software appli-cations for the data include viewing tracks projected on various map sources,annotating maps, and geo-tagging photographs based on the location they weretaken. Latitude and longitude are expressed in decimal degrees using the WorldGeodetic System 1984 (WGS 84) datum [20]. Elevation is recorded in meters.Dates and times respect Coordinated Universal Time (UTC) using ISO 8601format [17].

The advantages of using GPX file: allows to exchange data with a growinglist of programs for Windows, MacOS, Linux; can be transformed into other fileformats using a simple converter software or website; it is based on the XMLstandard, thus there are numerous tools able to read this format; makes it easyfor anyone on the web to develop new features for di↵erent applications.

From figure 2.1 [4] one can easily understand the di↵erences between way-points, routes and tracks. Waypoints are a pair of coordinates that identify apoint in physical space, tracks are a record of where a device/person has been,and routes are suggestions and estimations about where they might go. For ex-ample, each point in a track has a time stamp (because is recording where andwhen it was there), but the points in a route are unlikely to have timestampsother than estimated trip duration, because a route is a suggestion which ispossible that nobody ever have traveled [4]. Listing 2.2 [4] represents a simpleexample of GPX file produced by a Garmin Oregon 400t hand-held GPS unit.

1 <?xml ve r s i on=” 1 .0 ” encoding=”UTF�8” standa lone=”no” ?>2

3 <GPX xmlns=” ht tp : //www. t opog ra f i x . com/GPX/1/1” xmlns:GPXx=” ht tp : //www. garmin . com/xmlschemas/GPXExtensions/v3” xmlns:GPXtpx=” ht tp ://www. garmin . com/xmlschemas/TrackPointExtension /v1” c r e a t o r=”Oregon 400 t ” ve r s i on=” 1 .1 ” xmlns :x s i=” ht tp : //www.w3 . org /2001/XMLSchema�i n s t ance ” xs i : s chemaLocat ion=” ht tp : //www. t opog ra f i x .com/GPX/1/1 h t tp : //www. t opog ra f i x . com/GPX/1/1/GPX. xsd h t tp : //

7

Figure 2.1: Waypoints, Routes, and Tracks recorded by GPS receivers

www. garmin . com/xmlschemas/GPXExtensions/v3 h t tp : //www. garmin .com/xmlschemas/GPXExtensionsv3 . xsd h t tp : //www. garmin . com/xmlschemas/TrackPointExtension /v1 h t tp : //www. garmin . com/xmlschemas/TrackPointExtensionv1 . xsd”>

4 <metadata>5 < l i n k h r e f=” ht tp : //www. garmin . com”>6 <t ex t>Garmin I n t e r n a t i o n a l7 </ text>8 </ l i n k>9 <time>2009�10�17T22:58:43Z

10 </ time>11 </metadata>12 <t rk>13 <name>Example GPX Document14 </name>15 <t rk s eg>16 <t rkpt l a t=” 47.644548 ” lon=”�122.326897”>17 <e l e>4 .46</ e l e>18 <time>2009�10�17T18:37:26Z</ time>19 </ trkpt>20 <t rkpt l a t=” 47.644548 ” lon=”�122.326897”>21 <e l e>4 .94</ e l e>22 <time>2009�10�17T18:37:31Z</ time>23 </ trkpt>24 <t rkpt l a t=” 47.644548 ” lon=”�122.326897”>25 <e l e>6 .87</ e l e>26 <time>2009�10�17T18:37:34Z</ time>27 </ trkpt>28 </ t rk s eg>29 </ trk>30 </GPX>

Listing 2.2: GPX File Example

8

2.1.3 JSON files

JavaScript Object Notation [25] or JSON, is a minimal, open-standard formatthat uses human-readable text to transmit data objects consisting of attributevalue pairs. It is used primarily to transmit data between a server and a webapplication, largely replacing XML which is used by AJAX. JSON is a language-independent data format. It derives from JavaScript, but nowadays, code togenerate and parse JSON-formatted data is available in almost all programminglanguages. The JSON filename extension is usually JSON.

2.1.4 GPSD

Global Positioning System Daemon or GPSD [11], is a free software, daemon(computer program that runs as a background process) that receives data froma GPS receiver, and provides the data back to multiple applications such GPSnavigation software. The literature has emphasized the importance of GPSD inrecent generations of manned aircraft, marine navigation systems, and militaryvehicles. GPSD is everywhere in mobile embedded systems. It underlies themap service on Android phones. So it provides a unified interface to receiversof di↵erent types, allowing concurrent access by multiple tools. GPSD managesa collection of sensors and makes logs from all of them available as a JSON fileon a TCP/IP port.

Figure 2.2: GPSD - Dataflow View

Figure 2.2 [10] shows the GPSD’s architecture from a data-flow point ofview. GPSD launches in a loop waiting for input. The source can be 1. clientsmaking requests over a TCP/IP port; 2. navigation sensors connected via serialdevices; 3. control socket used by hot-plug scripts and some configuration tools;or 4. servers issuing periodic di↵erential-GPS correction updates (handled asnavigation sensors) [10]. If data comes in from a navigation sensor, it is givento the packet sni↵er. Packet sni↵er is a finite-state machine that works like thelexical analyzer in a compiler. The packet sni↵er’s job is to accumulate datafrom each port, deciding when it has accumulated a packet of a known type.A packet may contain di↵erent data, but the packet sni↵er does not know anddoes not care about the content of the packet. It only tells the core library whenit has one and passes back the payload and the packet type. The core libraryhas the responsibility to hand the packet to the driver associated with its type.The driver’s will mine data out of the packet payload into a session structureand decide for the multiplexer layer what kind of data it is. Part of this decisionis an indication that the daemon has accumulated enough data to ship a reportto its clients. After a data read from a sensor device, it means we’ve seen theend of a packet, the end of a packet group (which may be one or more packets),and the data in the device’s session structure should be passed to one of theexporters [10].

9

2.2 Navigation Formulas

2.2.1 Haversine Formula

Haversine Formula is a key equation in navigation. It is computing the shortestdistance between two points on the surface of a sphere, also known as great-circle distance or orthodromic distance, from their longitudes and latitudes. Theequation is a particular case of a more general formula in spherical trigonom-etry called ”The Law of Haversines”, relating the sides and angles of sphericaltriangles [6]. The name for the formula is following from Haversine function,given by: haversin(✓) = sin2( ✓2 ).

Figure 2.3: Spherical triangle

Consider the unit sphere from the figure 2.3, with the defined triangle bythe orthodromic distances connecting points u, v, and w on the surface of thesphere. Given that the lengths of these three sides are: a - from u to v, b - fromu to w, c - from v to w, and the angle of the corner opposite c is C, then thelaw of haversines is:

hav(c) = hav(a� b) + sin(a) ⇤ sin(b) ⇤ hav(C)

The sphere is a unit one, that means the lengths a, b, and c are equal tothe angles, in radians, subtended by those sides from the center of the sphere.So if one simply considers the special case where u is the north pole, while vand w are the two points whose separation d is to be determined, the Haversineformula is obtained.

Listing 2.3 proves exactly how this thesis is using the Haversine Formula andthe Earth radius chosen for all the projects inside HERE AUTO SDK.

1 const double RADIANS PER DEGREE = 0.0174532925199432957692;2 const double EARTH RADIUS METERS = 6371000 .0 ;3 /⇤4 ⇤ Computes the d i s t anc e between two geopo int s on the earth ’ s5 ⇤ s u r f a c e us ing the Havers ine formula . The curvature o f the earth6 ⇤ i s taken in to account . The a l t i t u d e o f the po in t s i s ignored .7 ⇤8 ⇤ @param p1 F i r s t coo rd inate .9 ⇤ @param p2 Second coord inate .

10 ⇤ @return The d i s t anc e in meters between p1 and p2 ,11 ⇤ or 0 i f e i t h e r po int i s i n v a l i d .

10

12 ⇤/13 double14 d i s t me t e r s ( const GeoCoordinates& p1 , const GeoCoordinates& p2 )15 {16 i f ( ! p1 . i s v a l i d ( ) | | ! p2 . i s v a l i d ( ) )17 {18 r e turn 0 ;19 }20

21 const double p 1 l a t r a d i a n s = p1 . l a t i t u d e ⇤RADIANS PER DEGREE;22 const double p 2 l a t r a d i a n s = p2 . l a t i t u d e ⇤RADIANS PER DEGREE;23 const double p1 l ng r ad i an s = p1 . l ong i tude ⇤RADIANS PER DEGREE;24 const double p2 l ng r ad i an s = p2 . l ong i tude ⇤RADIANS PER DEGREE;25

26 const double s i n h a l f d l a t =27 s i n ( ( p1 l a t r ad i an s�p2 l a t r a d i a n s ) /2) ;28 const double s i n h a l f d l n g =29 s i n ( ( p1 lng rad ians�p2 lng r ad i an s ) /2) ;30 const double a = s i n h a l f d l a t ⇤ s i n h a l f d l a t +31 cos ( p 1 l a t r a d i a n s ) ⇤ cos ( p 2 l a t r a d i a n s ) ⇤32 s i n h a l f d l n g ⇤ s i n h a l f d l n g ;33 const double c = 2⇤ a s in ( std : : min ( 1 . 0 , s q r t ( a ) ) ) ;34

35 r e turn EARTH RADIUS METERS ⇤ c ;36 }

Listing 2.3: Haversine Formula implemented in C++

However, the formula is limited when applied to the Earth, because the Earthis not a perfect sphere, having a radius R which varies from 6356.78 km at thePoles to 6378.14 km at the Equator. The formula gives only an approximateresult and there are small corrections, typically on the order of 0.1%, becauseof this slight ellipticity of the planet.

Haversine formula:

a = sin2(�'/2) + cos'1 ⇤ cos'2 ⇤ sin2(��/2)

c = 2 ⇤ arctan 2( 2p

(a), 2p

(1a))

d = R ⇤ c, where ' is latitude, � is longitude, �' is di↵erence in latitude, �� is di↵erencein longitude , R is earths radius (mean radius = 6371 km); the angles need tobe in radians to pass to trigonometric functions.

2.2.2 Law of Cosines Formula

According to this source [19], it is discussed that the Haversine Formula is con-ditioned for numerical computation, even for small distances. A better solutionare calculations based on the spherical law of cosines. In fact, when Sinnottpublished the Haversine formula, computational precision was limited. Nowa-days, most modern computers and languages use IEEE 754 64-bit floating-pointnumbers, which provide 15 significant figures of precision. With this preci-sion, by the source’s estimations, the simple spherical law of cosines formula(cos c = cos a⇤cos b+sin a⇤sin b⇤cosC) gives results down to distances as smallas a few meters on the Earths surface.

Law of Cosines:

d = arccos(sin'1 ⇤ sin'2 + cos'1 ⇤ cos'2 ⇤ cos� ⇤ �)R

11

2.2.3 Equirectangular Approximation Formula

The arguments presented above makes the simpler law of cosines a reasonable1-line alternative to the Haversine formula. On the other hand, the choicemay be driven by programming language, processor, coding context, availabletrigonometric functions in di↵erent languages, thus for very small distances anEquirectangular Approximation Formula might be more suitable, only if theperformance is an issue and accuracy is not important. It is interesting to notethat for small distances Pythagoras theorem can be used on an equirectangularprojection:

x = � ⇤ � ⇤ cos'm

y = � ⇤ '

d = R 2p(x2 + y2)

1 de f e qu i r e c t angu l a r d i s t an c e ( s t a r t po i n t , end po int ) :2 # two pa i r s o f l a t i t u d e and long i tude3 l a t1 , lon1 = s t a r t p o i n t4 l a t2 , lon2 = end po int5

6 x = math . rad ians ( lon2 � lon1 ) ⇤ math . cos ( 0 . 5 ⇤ math . rad ians (l a t 2 + l a t 1 ) )

7 y = math . rad ians ( l a t 2 � l a t 1 )8

9 # a sph e r i c a l d i s t anc e between the two po in t s10 r e turn R ⇤ math . s q r t ( x⇤x + y⇤y )

Listing 2.4: Equirectangular Formula implemented in Python

The problem with all these three formulas is related with computer arith-metic, not mathematics. At HERE it was decided that only Haversine formulais used, because the precision is less important. The basic factors to considerwhen discussing about these three are: a) a radian on the earth spans almost107 meters; b) the cosine function for arguments x close to 0 is approximatelyequal to 1 � x2/2; c) double-precision floating point has 15 decimal digits ofprecision.

Considering b) and c), it is implied that when x is near 1 meter, or 10�7

radians, almost all precision is lost: 1 � (10�7)2 = 1 � 10�14 is a computationin which the first 14 of the 15 significant digits are all canceled, with just onedigit to represent the result. Flipping this around, using inverse cosine (arc-cos) means that computing arccos for angles that correspond to meter-lengthdistances cannot be done with any meaningful accuracy. Similar considerationssuggest one shall avoid using the inverse cosine if distances less than a few hun-dred meters are involved, depending on how much precision one’s willing tolose. In Law-of-cosines, arccos is used to convert an angle to a distance. Thatrole is played by arctan2 in the Haversine formula. The tangent of a small an-gle x is approximately equal to x itself. Consequently the inverse tangent of anumber, being approximately that number, is computed essentially with no lossin precision. Finally, this is the reason why the Haversine formula, althoughmathematically equivalent to the law of cosines formula, is superior for smalldistances (1 meter or less).

According to [14], in the figure 2.4 is a comparison of the two formulas using100 random point-pairs on the globe (using double-precision calculations). Fordistances less than about 0.5 meters, the two formulas diverge and for distances

12

above 0.5 meters they tend to agree. To show how closely they agree, thefigure 2.5 represents a plot with the ratios of the Law of Cosines : HaversineFormula results for another 100 random point pairs, with their latitudes andlongitudes randomly di↵ering by up to 5 meters. This shows that the Law ofcosines formula is good to 3-4 decimal places once the distance exceeds 5-10meters. The number of decimal places of accuracy increases quadratically; thusat 50-100 meters (one order of magnitude) you get 5-6 decimal places accuracy(two orders of magnitude); at 500-1000 meters you get 7-8 decimal places, andso on.

Figure 2.4: Comparison between Law of Cosines and Haversine Formulas

Figure 2.5: Ratios of Law of Cosines and Haversine Formula

2.3 Related Work

Very little was found in the literature on the question of determining the behav-ior of a moving car. An important competitor on the software side is Siemens.Even if is not a direct competition with this study, the Siemens Innovation hasnumerous projects related with parking management using smart sensors, smartsoftware and smart data interpretation. The goals are clear: smart infrastruc-tures for saving time, protecting the environment and ultimately improving the

13

quality of life for city dwellers. One of the projects starts in Berlin to test radar-based parking space detection with the desired result to end to superfluous andhazardous tra�c searching for a parking space, and optimum use of parkingspaces within the city [24]. Siemens has launched the world’s first pilot projectin a public area (Berlin) aimed at simplifying the process for searching for aparking space. They have installed for test and demonstration radar sensors onstreet lamps that provide information on parking space occupancy. The networkof sensors scans from above an area of up to 30 meters, the equivalent of fiveto eight parking spaces. The results will be available in 2016 and should provethat by reducing parking search tra�c the system is suitable for cutting CO2emissions.

14

Chapter 3

Method

Chapter Three begins by laying out the solution to the problem presented in theIntroduction chapter, and looks at how the algorithm is working. It will thengo on in detail about the architecture. It presents the design and implementa-tion for algorithm, describing both its static and dynamic view.The static viewincludes elements such as: classes with inheritance and composition, structuredclasses, interfaces, components, subsystems, and deployment.The dynamic viewincludes the sequence or communication diagram.

3.1 Parking Detection Algorithm (PDA)

In collaboration with HERE, in Hybrid Components and Vehicle Data (HCVD)team, by analyzing the behaviors of a driver, the program detects whether theyare driving towards a destination or if they are currently in search of a parkingspot. Several metrics are used for detecting this, including distance to finaldestination (if set), distance to potential destination (if learned) and the currentdriving behavior (speed, forking rate, gained distance). HERE formulated thisas a classical machine learning classification problem. It is the author’s purposeto choose one of the simplest and most e�cient features from machine learningand improve it. The main aim of this study is to investigate the approachchosen, proposing a design and implementation for a solution to be integratedwith the current HERE Auto SDK. Once it is known that a driver is activelylooking for a parking place, it can be used as information to suggest a parkinggarage or a parking area in the vicinity of the driver. For this, HERE will usethe o✏ine data in their map or online services that add live data. The conceptis to develop an application that is able to check the driving status and to makesuggestions to the user when a parking behavior occurs.

The feature chosen by the author is called ”Track Cost”. Additionally, asimple classifier was added, that implemented a very simple heuristic techniqueon the track cost feature and did not require to be trained by any data. Thecode implementation for the simple classifier is illustrated in listing 3.1. Underthe assumption that drivers typically take optimal routes to reach a destination(the shortest or the fastest route) parking search behavior can easily be detected.Once the driver reaches his destination and starts looking for a parking space,the route is no longer optimal. Typically the driver first tries to find a parking

15

Figure 3.1: Parking Detection Algorithm Flow

spot right at the destination and then explores the street network around thisspot with increasing distance. The di�culties appear when the driver is lookingfor something else (e.g. an ATM, a shop, a gas station, a parking place furtherfrom destination). These are non-optimal routes and can happen also in tra�c(like an accident on the road can be the cause of a detour).

1 c l a s s S imp l eC l a s s i f i e r :2 ”””3 C l a s s i f i e s j son /gpx/nmea track f i l e s with a c l a s s i f i e r .4 The c l a s s i f i e r i s check ing three r a t i o s ( co s t0 / cos t1 / cos t2 )5 depending on chosen th r e sho ld s and i s r e tu rn ing a bool6 r ep r e s en t i ng the s t a tu s o f the car ( d r i v i ng / parking )7 ”””8 de f i n i t ( s e l f ) :9 #thr e sho ld s

10 s e l f . th r e sho ld0 = 1.1511 s e l f . th r e sho ld1 = 1.2512 s e l f . th r e sho ld2 = 1 .4

16

13

14 de f s t a tu s ( s e l f , cost0 , cost1 , co s t2 ) :15 i s p a r k i n g = 016 i f co s t0 > s e l f . th r e sho ld0 or cos t1 > s e l f . th r e sho ld1 or

cos t2 > s e l f . th r e sho ld2 :17 i s p a r k i n g = 118 r e turn i s p a r k i n g

Listing 3.1: SimpleClassifier implemented in Python

In figure 3.1 a work-flow of the algorithm is represented. This algorithmbegins with the GPS input, which can be given in three formats: NMEA, JSONor GPX files. A short introduction about these formats was provided in theBackground chapter. Another way to get the input is in the car, through real-time driving coordinates. For the purpose of testing the functionality of thealgorithm, random input files were not conclusive, so the input data needed to becustomized depending on the wanted status of the car. In order to create specialtracks, an inside GNSS tool from HERE SDK was used: CarloControlPanel.The idea of the application is very simple: drawing a trace on a map gives aNMEA or GPX file.

Figure 3.2: CarloControlPanel User Interface

CarloControlPanel is a tool that, among other things, can create, visualizeand send out NMEA position data via a socket. In figure 3.2 the user interfaceof the application is presented. Tracks can be interactively created by clickingand dragging points on the map. NMEA data (only GPRMC and GPGGAsentences) is then generated by interpolating between created positions. If the”Routed” feature is enabled position data is interpolated between calculatedroute geometry positions. Speed, interval and start time of generated positionscan be configured. Tracks can be saved as GPX files or exported as NMEAfiles. GPX tracks can be loaded and modified. NMEA tracks can be loaded,visualized and replayed.

To understand better how were these files created, a visual example is shownin figure 3.3. There are three colors on the trace: blue - for ”unknown” status,

17

when there is not enough data collected to decide the status of the car, green -for ”driving” behavior, when nothing unusual occurs in the driving track, andred - for ”parking”, when the driven track is longer than the optimal one. Allthese files contain more information than is necessary for the algorithm. So thenext step is converting the input in pairs of latitude and longitude. In order toconvert NMEA sentences a lot of packages are available online, and for GPX orJSON files a simple parser is enough.

Figure 3.3: Example of input file - Visualization

On the basis of figure 3.3, another explanation of the map can be seen infigure 3.4. The idea is the driver is leaving from Isafjordsgatan 39 to Kistagangen20. The blue path represents the driven track, and the green one shows whatwould have been the optimal track. One can easily see the di↵erence. Withthis in mind, is interesting to mention that the track cost is using the routeoptimality. Given a point B on the track, a previous point A on the track isselected (e.g. 1000 meters before) and a route calculation is done to point B.The track cost is computed as the ratio of the track length to the route length.The higher the track cost is at a point B, the more likely it is that the driveris searching for parking. These costs are calculated for the following distances:400 m, 800 m, and 1200 m at each track point. Track costs could also be basedon the ratio of track duration and route duration. Nevertheless, this is verysensitive to any sort of tra�c incident. The length of a track or route can bedetermined with high accuracy, whereas durations are only estimates with a veryhigh degree of variance and as such give worse classification scores. However, toget the tracks cost required, the next steps in the algorithm are evaluating thedriven tracks and the optimal ones. With the costs computed, three thresholdsare mandatory. More details about the numbers chosen for driven tracks and

18

thresholds can be checked in chapter 4. Finally, it is therefore possible to expressa status of the car: 0 - driving mode or 1 - parking mode.

Figure 3.4: Driven track vs. Optimal track

3.2 Design

An initial objective of the project was to identify the best configuration for thealgorithm. The author chose Python for this task. Python is an open sourceprogramming language, easy to learn and use, providing a flexible environment,and not the least, very robust. The code written in Python for this applica-tion has fewer lines of code than the same algorithm implemented in any otherprogramming language, which makes Python less prone to issues, easier to de-bug, and more maintainable. All of these advantages and the fact that is notnecessary to look up references frequently, nor are there formalities of the lan-guage, like it would in Java or C++, convinced the author that this is the fastersolution for finding out the best parameters to run the algorithm.

This section is set out with the aim of assessing the importance of reusingthe existing components from HERE SDK and introducing a new feature. Oneof these preexisting components, car location (carlo) SDK package is shown infigure 3.5 to help understand how the HERE AUTO SDK is structured. Thename ”Carlo” has been chosen having the motivation to create a location SDKfor cars. Hence CAR LOcation SDK is CARLO SDK. The SDK consists ofseveral modules: common (shared components that are required by all othercomponents), SDL (smart data loader), navcore (Core Location SDK compo-nents: contains functionality to render a map, calculate routes, search locations

19

etc.), MobilityGraph (captures user’s mobility graph and transition patterns,provides destination and route predictions), BSP (the board-support-packagelibrary: providing platform specific implementations, e.g. system state infor-mation or platform configurations, an interface to the (geo location) sensors,logging, persistence storage, network access, etc.) and ngeo ( MOS compo-nents).

Figure 3.5: Carlo Package Overview

Given the architecture for the SDK, an explanation for the GPS simulationtool can also be represented: figure 3.6. CarloControlPanel tool is implementedin Carlo Package. Carlo allows it to communicate with GPSD or GeoLocation-Sensor. GPSD is a service daemon that monitors one or more GPS-es attachedto a host computer through serial or USB ports, making all data on the loca-tion of the sensors available to be queried on TCP port of the host computer.With GPSD, multiple location-aware client applications can share access tosupported sensors without contention or loss of data. Also, GPSD responds toqueries with a format that is substantially easier to parse than the NMEA 0183.The GPSD distribution includes a linkable C service library, a C++ wrapperclass, and a Python module that developers of GPSD-aware applications can useto encapsulate all communication with GPSD [11]. GPSD can also connect toCarloControlPanel so basically all applications that use the library ”libgps” canreceive simulated position data - e.g. Here Auto. However, GeoLocationSensoris feeding to the navigation tool a new position that can come from GPSD,NMEA file or directly from Carlo.

It was decided that the best fit for PDA was in navcore module, where areall the features related with maps, routes and search. In order to integratethe new algorithm in the project, a series of analyses on the components werenecessary. One of the advantages in doing this is the reuse of existing products

20

Figure 3.6: CarloControlPanel Tool Package

and components. In figure 3.7 is an overview of the architecture for navcore.Each component can not be detailed in this study due to confidentially reasons.However, analyzing diagram in figure 3.8 on one hand can be seen the newcomponents for navcore module, similar with the classes from prototype phase:algorithm component (PSD), composed from the four main interfaces Driven-Track (DT), OptimalTrack (OT), SimpleClassifier (SC) and RatioCalculator(RC). On the other hand, four components are reused from navcore structure:utilities - where all the helpers methods are, including the mathematical formu-las for Haversine distance, routing - where all the logic for computing the fastestroute between two points is, positioning - where all the GPS points are treatedand forward, and guidance - necessary for routing and positioning modules.

3.3 Implementation

In figure 3.9 is shown the complete UML diagram for the code used for testingdi↵erent configurations for the algorithm. Even if in the diagram are shown onlythe default values, the UML diagram is valid for all configurations. The dia-gram describes the structure of the PDA by showing the system’s classes, mod-ules, their attributes, methods, and the relationships among them. The classParkingSearchDetectionAlgorithm owns four classes: DrivenTrackCost, Opti-malTrackCost, SimpleClassifier, and RatioCalculator. These four main classesare in a inheritance relation.

DrivenTrackCostByHaversineDistance and DrivenTrackCostByEquirectan-gularDistance are inherited from DrivenTrackCost. The names may help tounderstand the di↵erences between them. One class is using Haversine Formulafor computing the distance between two GPS coordinates, and the other one isusing a simplified version of this formula called Equirectangular Distance For-mula. As mentioned in the Background chapter, the di↵erence between thesetwo is the accuracy provided.

21

Figure 3.7: Navcore Components

The same division is valid for OptimalTrackCost: OptimalTrackCostBy-HaversineDistance and OptimalTrackCostByEquirectangularDistance. In addi-tion, OptimalTrackCostByRouteLength class is represented. This class is usingthe HERE routing API, connecting this prototyping phase to the final projectcode source and creating valuable results. Another important class is RatioCal-culatorByDistance inherited from RatioCalculator. As described in the previoussection, a possible RatioCalculatorByDuration class would have been an option,but was dropped out because of its high sensitivity. Finally, all these classes areusing the module Helpers which contains methods for reading and convertingthree kinds of GPS input files: NMEA, GPX and JSON, and also the mathemat-ical formulas methods used by DrivenTrackCost and OptimalTrackCost classes.

Figure 3.10 presents the sequence diagram, showing how objects operate withone another and in what order. This allows the specification of simple runtimescenarios in a graphical manner. In general, the PDA should be requested, sothe diagram starts with an interaction from exterior calling get driving modemethod. This message launches a sequence that runs one time for each of thethree required costs. This sequence launches by get cost method with trace anddriven distance as parameters, activating in DrivenTrackCost the calculations toget driven track. In order to continue and be able to compute also the optimaltrack, the GPS point where the driven distance stopped is needed. That’s whyis important that all of these messages happen synchronously. Finally, aftercontribution from RatioCalculator class, the cost can be returned. Only aftercomputing all 3 costs, a final status of the car is given as a boolean result.

The flow chart 3.11 below illustrates at a deeper level the implementationand functionality of the algorithm.

22

Figure 3.8: PDA Components

3.4 Testing

One of the most di�cult parts of this thesis was the testing section. It is wellknown that there is always the necessity to prove that the code is functionaland ready for production use. In order to integrate completely the algorithm inHERE SDK, unit testing and integration testing was mandatory.

The HCVD team advice was to use Test Driven Development (TDD) for thealgorithm implementation, because HERE teams are used to agile programmingapproach [18]. TDD is a software development process that is based on therepetition of a very short development cycle [3]:

1. the developer writes a failing test case (this will define a desired improve-ment or new function);

2. produce code to pass the test;3. re-factors the new code to acceptable standards.For the unit testing, the author used the mocking technique. Mock objects

are simulating behavior of complex, real (non-mock) objects and they are usefulwhen an object is impractical or impossible to incorporate into a unit test. Forexample, the implemented code for PDA needed to use Routing API from HERESDK in order to get the minimum distance for Optimal Track, but in the unittesting part the Routing API would have not influence the behavior of PDAfunctions. Routing API is suppling non-deterministic results. Also the states ofthis class are very di�cult to reproduce because of its dependencies. The mainadvantage from avoiding Routing API in unit testing was that running the unittests was fast, because it was no need to wait for Routing Calculations (whichwere very slow). To create a mocked class the author chose to use Google C++Mocking Framework [1]. The framework has a pivotal role in testing becausethe evaluation of the results is done automatically by framework, when mockedobject is destroyed.

For the integration testing, the author divided the all the possible cases in6 tests, as shown in Appendix D:

1. Invalid test: when the system cannot start a PDA object, so the parking

23

status is UNKNOWN (not parking/driving status);2. Start Detection test with valid trace: when the system starts correctly a

PDA object, has a valid driven track file (input file: trace01.nmea) and is ableto detect a DRIVING mode only;

3. Start Detection test with valid trace: when the system starts correctly aPDA object, has a valid driven track file (input file: trace02.nmea) and is ableto detect a DRIVING mode and switch to a PARKING mode depending on theinput;

4. Start Detection test with invalid trace: when the system start correctlya PDA object, but the trace is corrupted (or simply not long enough) in orderfor the algorithm to start computing car’s mode, so the parking status shall beUNKNOW;

5. Start Detection multiple times test: the system can start the PDA objectonly one time, any other time that the operation is repeated shall be signaledwith an error;

6. Cancel Detection test: if the system starts a PDA object, the system canalso cancel the same PDA object. All the values shall be reset to default andthe parking status to be UNKNOWN.

24

Figure 3.9: UML Diagram for Parking Detector Algorithm

25

Figure 3.10: Sequence Diagram for Parking Detector Algorithm

26

Figure 3.11: PDA Flow

27

28

Chapter 4

Results and Analysis

The fourth chapter presents and discuss the results regarding the best configu-ration for the algorithm presented as a solution in chapter three.

4.1 Notations and Values

As mentioned in Methods chapter, in order to decide the best configuration forthe algorithm, a set of 40 configurations was analyzed. These configurations arementioned in figure 4.1.

The name for one configuration has the following template (presented as astring concatenation): the method used for finding driven track + ” ” + theimplementation used for computing optimal track + ” ” + the first chosen dis-tance + ” ” + the second chosen distance + ” ” + the third chosen distance(these three distances are the ones for looking behind from the last GPS posi-tion, all in meters) + ” ” + the first chosen threshold + ” ” + the second chosenthreshold + ” ” + the third chosen threshold. For example, the name for thefirst configuration is ”Haversine Haversine 400 800 1200 105 115 13”. This canbe translated as: the implementation used for finding the driven tracks is byHaversine formula, the method used for calculating the optimal tracks is byHaversine formula also, the chosen distances are: 400 m, 800 m, and 1200 m;and the chosen thresholds are: 1.05, 1.15 and 1.3. The comma could not be rep-resented in the name, so the respected rule is the comma should be immediatelyafter the first digit, which will always be ”1”.

It is apparent from the structure of one configuration that 3 distances areneeded and that the first configuration starts with first distance equal to 400meters. This number is not chosen randomly. Legally, to make a U-turn safely,you must be able to see well in both directions. It is illegal to make a U-turn ona curve in the road, on or near a railway crossing or hilltop, or near a bridge ortunnel that blocks your view. You shall never make a U-turn unless you can seeat least 150 meters in both directions, which means at least 300 meters. Besidesthe legally aspects, the GPS satellite can recognize that a U-turn happened inthe driven trace of a car if a minimum distance of 400 meters was traveled.In response to this research the starting configuration distance was set to 400meters. The same thinking was applied for the second and third distance, whichare double and respective triple of the first one.

29

Figure 4.1: Algorithm Configurations

30

Figure 4.2: Algorithm Test Files

The next three numbers from the structure of one configuration are the

31

thresholds. The minimum threshold that makes sense and shows the slightestdi↵erence in the ratio between the driven track and optimal track is 1.05. Forthresholds less than 1.05, the di↵erence between optimal and driven track wastoo small to influence the algorithm (less than approximately 150 meters). Atthe initial threshold di↵erent numbers from the interval [0.05,0.20] were addedto obtain the second minimum threshold. Being interested only in the first 3digits of the fractional part, made the author decide that adding 0.10 for thesecond threshold, and 0.20 for the third threshold gives an observable di↵erencefor the final costs needed in the algorithm.

Another important notation is the one for the input files. Fifty NMEA fileswere created and renamed with a intuitive description like in figure 4.2. All thetest files were generated manually in GNSS tool presented in Chapter 3. Thebest way to create NMEA files for testing a navigation application would bewith drive testing, but because of the resources allocated for this project, drivetests were not possible. The cheapest solution for HERE to replace drive testswas to introduce the GNSS tool. This tool is supporting only the map fromBerlin, Germany, so as a result all the test files are created with Berlin GPScoordinates. Even if the input files were not a result of a real car driving around,the final files presented interesting and possible cases of di↵erent behaviors ofa car. The first set of files aimed to represent the basic driven track of a car(e.g.: a straight line or a small loop in the end of the track), while the next setof files emphasized on the unexpected driven track of a car (e.g.: a double loopin the middle of the track, which can be the result of the driver looking for anATM machine). Another way to distinguish between these files is the size, sothe number of NMEA sentences. The correlation between the number of NMEAsentences and the number of GPS points is resulting in how long is the driventrack created for the respective file. In the end, the files contained distancesbetween 0 and 50 kilometers. What is interesting in creating data manually isthat the author knew the correct result of the algorithm for a certain input file,which allows easily to compare an actual result with a final one.

For example, ”test01 loopend” means that is the first test file generated inGNSS tool (test01) and at the end of the GPS track has a loop (loopend). Thealgorithm should find parking mode in the last part of the trace where is theunexpected behavior (the loop). The table 4.1 illustrates ”Haversine Haversine400 800 1200 105 115 13” configuration for ”test01 loopend” input file. Whatis important to understand from this table is related with the ”Distances” col-umn. As it can be seen, the first distance is 400, which represent the firstdistance from the configuration. After that this distance is increased with 500meters. The idea behind this is that it does not make sense, in testing param-eters for final configuration, to check the status of the car from meter to meter(as it would happen in real cases and final implementation of the algorithm).In researching phase, in order for something to change and for the algorithm torecognize that something is di↵erent from a few seconds ago, we need at least500 meters in between. In this case, the maximum is 5400 meters because thetrace created is smaller than 5900 meters (5400 + 500). So for the first testfile, 11 results are generated which can be observed in ”Result” column, with”0” - meaning driving mode and 1 - parking mode. However, the input fileswere created manually, and the author decided the ”Actual Result” column atthe time the files were generated. This was a time-consuming way of check-ing if the results were correct, but in end the only e�cient solution. Knowing

32

Algorithm Configuration: ”Haversine Haversine 400 800 1200 105 115 13”GPS trace file Distances Result

(R)ActualResult(A)

R � A R � ARatio

test01 loopend

400 0 0 0900 0 0 01400 0 0 01900 0 0 02900 0 0 03400 1 1 03900 1 1 04400 1 1 04900 1 1 05400 1 1 0 1

Table 4.1: Configuration 1 for test file 1

the generated and correct result leads to ”Result vs. Actual Result” or ”R �A” column. Applying XOR operation between these two results is giving thewanted output. XOR is 1 only if the input values are di↵erent, and 0 if areequal. That means that wherever is a ”0” in this column, the generated resultsare the expected ones. In the ”Ratio” column a simple excel function is applied:COUNTIF (F4 : F12; ” = 0”) : COUNT (F4 : F12), which is giving a ratiobetween the correct results and the total results. In this case are 11 correctresults divided by 11 results, giving the ratio ”1”. This is a great example, ratio”1” showing that the algorithm is functional, for that particular test case. Thecomplete table can be analyzed in the Appendix A.

4.2 Results

In the end, the tables were obtained with the final results for:1. all configurations for Haversine Haversine 400 800 1200;2. all configurations for Haversine Haversine 500 1000 1500;3. all configurations for Haversine Haversine 600 1200 1800;4. all configurations for Haversine Haversine 700 1400 2100;5. all configurations for Haversine Haversine 800 1600 2400;6. all configurations for Haversine HereAPI 400 800 1200;7. all configurations for Haversine HereAPI 500 1000 1500;8. all configurations for Haversine HereAPI 600 1200 1800;9. all configurations for Haversine HereAPI 700 1400 2100;10. all configurations for Haversine HereAPI 800 1600 2400;In the appendix chapter are attached all the tables for Haversine Haversine

configurations. What is interesting in all the tables above is the geometricmean, which is computed with the final results ”R � A” from all the 50 inputfiles. The geometric mean is better suited than arithmetic mean since it ismuch more robust and sensible [12]. The final result was unexpected: thebest configuration was Haversine HereAPI implementation with 400 800 1200distances and 115 125 14 thresholds because the geometric mean was equal to0.83, being the best result from all 40 final tables.

33

4.3 Reliability and Validity

The reliability of the configurations is very good because the conditions can becontrolled very precisely, as discussed in the beginning of this chapter. Creatingthe input files manually o↵ers flexibility and gives the opportunity to touch allthe unexpected behaviors, knowing the expected result in any case. This caninclude also some impossible events.

Unfortunately, the validity su↵ers for the same reasons that the reliability isgood. Since everything is created virtually, a real case taken from a drive testmight be quite di↵erent from the case created manually by a human (being adriver in tra�c is completely di↵erent than being one in front of a computer).However, the main purpose for the input files was to detect the best configura-tion for the algorithm regardless of the authenticity of the driven track. Ana-lyzing the validity from this point of view, the obtained results are consideredimportant data to HERE because these are providing better information abouthow would an algorithm work with only raw data like altitude and longitude.

4.4 Discussion of classification results and errorcases

Given the recommended SimpleClassifier, it is worth looking at classificationresults in a bit more detail. Taking into account all computed results for all40 configurations, there are 43,040 entries in the output table. From the total10,712 are wrong and 32,328 are correct results. That means that almost 25%of the entries were computed bad. The numerous reasons could be classified intwo categories: false positives and false negatives.

4.4.1 False positives

Analyzing 25% entries, can be said that some of them had been wrongly classi-fied as parking mode while being in fact driving mode. Manually inspection ofthese segments can roughly assign 4 categories to those False Positives:

1. Beginning of track problem 52%: A lot of wrong search segments appearedat the beginning of a track (within first 1000-1500 meters) as in figure 4.3. Thisis due to the fact that for short tracks a few meters of di↵erence between tracklength and route length might already be significant with respect to the costratio. These cases can be easily excluded since it is unlikely that a parkingsearch starts right at the beginning of a journey.

34

Figure 4.3: Red Segment - Track Start Problems

2. Map matching problems 18%: Some wrong search segments are relatedto map matching problems as presented in figure 4.4. If the map matcher isputting a track point to the wrong road element, route calculations may besignificantly longer or shorter. Additionally, some of the recorded tracks didntseem to be properly map matched and showed large jitters, which also easilyresulted in longer tracks.

Figure 4.4: Red Segment - Map Matching Problems

3. Wrong annotation 11%: Some wrong search segments are actually ex-

35

plainable due to a detour as shown in figure 4.5. This typically indicates awrong annotation, so human mistakes.

Figure 4.5: Red Segment - Wrong Annotation

4. Unknown reasons 19%: The remaining wrong search segments remainnot easily explainable like in figure 4.6. Often, these segments had been rela-tively short. So a smoothing of the predicted mode might remove a lot of thesecases. It looks like they often relate to map matching problems as well. Furtherinvestigation needed.

Figure 4.6: Red Segment - Unknown

36

4.4.2 False negatives

There are almost 6000 segments classified as driving while being annotated asparking. In most cases, this is related to a part of a track that appears to beagain relatively optimal (in the routing sense) after a passage of searching. Ina way, this can be seen as an annotation problem. When doing the annotation,there was no clear concept of expiration of search behavior. Implicitly, this isrelated to the largest segment length (approximative 1.5 km) that is used forthe features like track costs. Adding a clear distance-based threshold criteriaon when to switch back from search mode to drive mode should improve in thissituation.

Another reason for wrongly annotated parking search segments might be,that the track was not properly split because very short stopovers had notbeen identified properly. For instance a mail delivery service in a neighborhoodmight show very convoluted tracks, that are nevertheless clearly directed andoptimal between each stopover. The identification of stopovers will be muchmore reliable if additional sensor data from the car could be evaluated such asdoor events or engine-stop events.

37

38

Chapter 5

Conclusions

5.1 Results

The results and evaluations done in chapter 4 are encouraging. It has beenshown that the configuration chosen for implementation is cheap and e↵ectivein predicting parking behavior. The implementation of the algorithm was suc-cessfully integrated with the existing HERE SDK and doesnt interfere with theusual system notifications, being connected only to the GPS part (Map Matcherimplementation). Any changes that might occur are only in the software andmemory occupied. The parameters used in parking detection can be madeuser controlled by adding a few commands to the existing API. This will allowHERE to decide the maximum number of distances to be supported, what arethe distances, or thresholds, etc. All the goals that have been listed in section1.3 have been achieved and some more improvements have been added to theimplementation.

Predicting parking search behavior showed a very good detection score withmore than 75% right results. The analysis of the remaining False Positivesand False Negatives indicates small need for improvements. First of all by dis-abling detection at the beginning of a drive. Secondly, the occasional oscillationsbetween driving and parking mode might be prevented by smoothing. Addition-ally, switching back from parking mode to driving could be delayed and coupledto some distance threshold criteria. The distinction between parking behaviorand the other potential reasons for non-optimal driving remains di�cult by pureGPS track analysis.

5.2 Implementation

Integrating PDA API into HERE SDK was advantageous as the range of oper-ation increased to a large extent. PDA API uses only the Map Matcher fromHERE SDK and does not influence the system in any way. The algorithm doesnot need to be started or stopped, these operations happening automatically atthe start/stop of the system, independent of the user. The following ideas areimportant for a reliable implementation of parking space detection:

1. Proper detection of stopovers by evaluating car sensor data e.g.: doorevents;

39

2. Disable detection on e.g. the first kilometer after a start or stopover;3. Use smoothing to filter out short misclassified segments and to avoid

oscillation between the two modes;4. Use an as-good-as-possible map matcher.

5.3 Recommendations

Driven by the fact that parking behavior can be detected with relatively highaccuracy, a further system and patent application emerged from this project.The author recommendation for HERE is that also some of the configurationsshould be patented, along with a strategy to support drivers in finding a park-ing space through applying knowledge of recent parking search trajectories ofother drivers nearby. The central idea of this strategy is that streets that aredriven while doing a parking search can be notified to a server as having noparking space available. Another driver, reaching the area shortly afterwardswith the same intent, could then be proposed a parking search route that avoidsthose streets that had been checked recently without success. One of the majorbenefits of this approach is that it also works with sparse probe data. Othersystems that, for instance, send the information of an empty parking spot tothe server whenever a drive starts, only provides meaningful information if theprobe data is dense.

For the future work, more tests can be done, especially drive tests. It iscritical to test the behavior of Map Matcher in real time and to analyze how isthe algorithm updated.

The distinction between parking behavior and the other potential reasonsfor non-optimal driving remains di�cult by pure GPS track analysis, that’swhy as a future addition the algorithm could be integrated with car’s sensors.Nevertheless, o↵ering assistance in the ambiguous cases might still be positivelyacknowledged by the driver. On the other hand, if other car sensors data clearlyindicate parking at the end of a track, valuable statistics can be extracted fromthe previously driven trajectory and send to the cloud. For instance, averageparking search times in urban areas at a given time could be gathered. Thisinformation can be useful for more accurate ETA prediction. Moreover, knowl-edge of longer parking search times within urban areas at a given time of daycan be re-used as a significant feature to better distinguish between parkingsearch trajectories and other non-optimal driving patterns.

40

Appendix A

Final Results forHaversine Haversineconfigurations

Table A.1: Final Results for algorithm configuration ”Haver-sine Haversine 400 800 1200” and di↵erent parameters

Begin of TableGPS File Hav Hav

400 800 1200105 115 13

Hav Hav400 800 1200115 125 14

Hav Hav400 800 1200125 135 15

Hav Hav400 800 1200135 145 16

test01 loopend 1 1 1 1test02 circle 0 0 0 0test03 straight 0,84615385 0,84615384 0,92307692 0,92307692test04 loopend 0,66666667 0,83333333 0,83333333 0,83333333test05 loopend 1 1 1 1test06 straight 0,58333333 1 1 1test07 straight 0,55555556 0,77777777 1 1test08 straight 0,56 0,6 0,76 0,8test09 straight 0,73333333 0,84444444 0,91111111 0,93333333test10 straight 0,88888889 0,92592592 0,92592592 0,96296296test11 loopbeginning 0,11764706 0,17647058 0,23529411 0,41176470test12 loopmiddle 0,42222222 0,6 0,64444444 0,73333333test13 noloop 0,64516129 0,70967741 0,80645161 0,87096774test14 straight 0,92857143 0,94047619 0,95238095 0,95238095test15 loopend 0,94736842 0,94736842 1 1test16 loopend 0,84615385 0,84615384 0,84615384 0,76923076test17 loopend 0,71428571 0,71428571 0,85714285 0,85714285test18 loops 0 0,11111111 0,16666666 0,27777777test19 straight 0,38461538 0,5 0,61538461 0,76923076test20 straight 0,92307692 0,96153846 0,96153846 1test21 straight 0,95 0,96666666 0,98333333 1test22 loopend 0,88235294 0,88235294 0,88235294 0,82352941

41

Continuation of Table A.1GPS File Hav Hav

400 800 1200105 115 13

Hav Hav400 800 1200115 125 14

Hav Hav400 800 1200125 135 15

Hav Hav400 800 1200135 145 16

test23 smallloopend 0,625 0,75 0,75 0,75test24 smallloopend 0,44444444 0,57142857 0,44444444 0,55555555test25 smallloopend 0,75 0,75 1 1test26 loopmiddle 0,11111111 0,22222222 0,33333333 0,44444444test27 loopmiddle 0,14285715 0,28571428 0,28571428 0,28571428test28 straight 0,54545455 0,63636363636 0,72727272 0,81818181test29 straight 0,25 0,66666666 0,83333333 0,83333333test30 straight 0,81481481 0,85185185 0,96296296 0,96296296test31 loopend 0,58333333 0,83333333 0,91666666 0,91666666test32 loopend 0,66666667 0,83333333 1 1test33 straight 0,25 0,5 1 1test34 loopend 0,41176471 0,88235294 0,94117647 1test35 straight 0,66666667 1 1 1test36 straight 0,83333333 0,91666666 0,97222222 1test37 straight 0,29411765 0,47058823 0,52941176 0,64705882test38 straight 0,70833333 0,79166666 0,91666666 1test39 loop 0 0,05555555 0,16666666 0,33333333test40 circle 0,07142857 0,1428571428 0,28571428 0,35714285test41 straight 0,9245283 0,943396226 0,94339622 0,96226415test42 loopend 0,9 0,95 1 1test43 loopend 0,6666667 0,66666666 1 0,5test44 straight 0,69230769 0,84615384 0,84615384 0,92307692test45 straight 0,71428571 0,80952380 0,85714285 1test46 straight 0,74074074 0,81481481 0,925925925 0,92592592test47 loopend 0,9375 0,9375 0,875 0,9375test48 loopend 0,55 0,55 0,65 0,75test49 straight 0,9 0,9 1 1test50 straight 0,76190476 0,85714285 0,90476190 0,95238095geometric mean 0,56845594 0,64250225 0,74097898 0,79193224

End of Table



500 1000 1500105 115 13

Hav Hav500 1000 1500115 125 14

Hav Hav500 1000 1500125 135 15

Hav Hav500 1000 1500135 145 16

test01 loopend 1 1 1 1test02 circle 0 0 0 0test03 straight 0,75 0,83333333 0,8333333 0,91666666test04 loopend 0,6 0,8 0,8 1test05 loopend 1 1 1 1test06 straight 0,5 0,91666666 1 1test07 straight 0,44444444 0,77777777 0,77777778 1

42


500 1000 1500105 115 13

Hav Hav500 1000 1500115 125 14

Hav Hav500 1000 1500125 135 15

Hav Hav500 1000 1500135 145 16

test08 straight 0,5 0,625 0,70833333 0,83333333test09 straight 0,68888888 0,8 0,86666666 0,95555555test10 straight 0,81481481 0,88888888 0,92592592 0,96296296test11 loopbeginning 0 0,11764705 0,23529411 0,41176470test12 loopmiddle 0,38636363 0,52272727 0,63636363 0,70454545test13 noloop 0,51612903 0,61290322 0,70967741 0,83870967test14 straight 0,9047619 0,92857142 0,94047619 0,94047619test15 loopend 0,9473684 0,94736842 1 1test16 loopend 0,6153846 0,69230769 0,69230769 0,69230769test17 loopend 0,7142857 0,71428571 0,85714285 0,85714285test18 loops 0,05555555 0,05555555 0,11111111 0,166666666test19 straight 0,30769230 0,38461538 0,61538461 0,73076923test20 straight 0,92307692 0,96153846 0,96153846 1test21 straight 0,9 0,95 0,98333333 1test22 loopend 0,88235294 0,88235294 0,94117647 0,88235294test23 smallloopend 0,75 0,75 0,875 0,75test24 smallloopend 0,33333333 0,33333333 0,44444444 0,55555555test25 smallloopend 0,5 0,75 1 1test26 loopmiddle 0 0,11111111 0,22222222 0,33333333test27 loopmiddle 0 0,14285714 0,14285714 0,14285714test28 straight 0,45454545 0,54545454 0,63636363 0,81818181test29 straight 0,25 0,5 0,66666666 0,83333333test30 straight 0,81481481 0,88888888 0,96296296 0,96296296test31 loopend 0,58333333 0,75 0,91666666 1test32 loopend 0,66666666 0,83333333 0,83333333 1test33 straight 0,33333333 0,33333333 0,66666666 1test34 loopend 0,625 0,8125 0,9375 1test35 straight 0,666666666 0,83333333 1 1test36 straight 0,833333333 0,88888888 0,91666666 0,97222222test37 straight 0,29411764 0,352941176 0,41176470 0,64705882test38 straight 0,66666666 0,75 0,79166666 0,95833333test39 loop 0 0 0 0,055555555test40 circle 0 0,07142857 0,28571428 0,28571428test41 straight 0,88679245 0,90566037 0,92452830 0,96226415test42 loopend 0,85 0,9 0,925 1test43 loopend 0,2 0,8 0,6 0,8test44 straight 0,61538461 0,69230769 0,84615384 0,84615384test45 straight 0,66666666 0,76190476 0,85714285 0,90476190test46 straight 0,70370370 0,74074074 0,88888888 0,92592592test47 loopend 0,75 0,9375 0,875 0,875test48 loopend 0,6 0,55 0,65 0,7test49 straight 0,89473684 0,89473684 0,94736842 0,94736842test50 straight 0,66666666 0,85714285 0,90476190 0,90476190geometric mean 0,57721128 0,59031435 0,69941482 0,73901027

End of Table

43



600 1200 1800105 115 13

Hav Hav600 1200 1800115 125 14

Hav Hav600 1200 1800125 135 15

Hav Hav600 1200 1800135 145 16

test01 loopend 0,81818181 0,72727272 0,72727272 0,72727272test02 circle 0 0 0 0test03 straight 0,64285714 0,64285714 0,71428571 0,71428571test04 loopend 0,57142857 0,57142857 0,57142857 0,71428571test05 loopend 0,71428571 0,71428571 0,71428571 0,71428571test06 straight 0,35714285 0,71428571 0,78571428 0,85714285test07 straight 0,36363636 0,54545454 0,54545454 0,72727272test08 straight 0,38461538 0,5 0,53846153 0,65384615test09 straight 0,61702127 0,72340425 0,80851063 0,91489361test10 straight 0,75862068 0,79310344 0,79310344 0,86206896test11 loopbeginning 0 0,05263157 0,21052631 0,31578947test12 loopmiddle 0,34782608 0,4130434 0,5 0,60869565test13 noloop 0,45454545 0,51515151 0,60606060 0,63636363test14 straight 0,88372093 0,90697674 0,91860465 0,91860465test15 loopend 0,71428571 0,85714285 0,90476190 0,90476190test16 loopend 0,6 0,5333333333333330,53333333 0,46666666test17 loopend 0,375 0,5 0,625 0,625test18 loops 0 0 0,05 0,1test19 straight 0,22222222 0,29629629 0,33333333 0,51851851test20 straight 0,85714285 0,89285714 0,89285714 0,92857142test21 straight 0,87096774 0,93548387 0,93548387 0,96774193test22 loopend 0,77777777 0,83333333 0,83333333 0,77777777test23 smallloopend 0,6 0,6 0,6 0,6test24 smallloopend 0,27272727 0,36363636 0,27272727 0,27272727test25 smallloopend 0,4 0,4 0,6 0,4test26 loopmiddle 0 0,2 0,2 0,2test27 loopmiddle 0 0 0,11111111 0,11111111test28 straight 0,38461538 0,38461538 0,53846153 0,69230769test29 straight 0,2142857 0,42857142 0,5 0,57142857test30 straight 0,7241379 0,82758620 0,89655172 0,89655172test31 loopend 0,4285714 0,64285714 0,78571428 0,85714285test32 loopend 0,5 0,5 0,625 0,625test33 straight 0,2 0,2 0,4 0,6test34 loopend 0,5 0,61111111 0,83333333 0,88888888test35 straight 0,375 0,5 0,625 0,75test36 straight 0,7837837 0,86486486 0,86486486 0,91891891test37 straight 0,1578947 0,31578947 0,36842105 0,52631571test38 straight 0,6153846 0,65384615 0,73076923 0,84615381test39 loop 0 0 0 0test40 circle 0 0,0625 0,0625 0,125test41 straight 0,81818181 0,85454545 0,89090909 0,90909090test42 loopend 0,78048780 0,85365853 0,87804878 0,92682926

44


600 1200 1800105 115 13

Hav Hav600 1200 1800115 125 14

Hav Hav600 1200 1800125 135 15

Hav Hav600 1200 1800135 145 16

test43 loopend 0,14285714 0,57142857 0,57142857 0,57142857test44 straight 0,53333333 0,53333333 0,66666666 0,73333333test45 straight 0,56521739 0,65217391 0,73913043 0,82608695test46 straight 0,55172413 0,65517241 0,75862068 0,86206896test47 loopend 0,72222222 0,77777777 0,77777777 0,83333333test48 loopend 0,45454545 0,54545454 0,63636363 0,68181818test49 straight 0,76190476 0,80952380 0,85714285 0,85714285test50 straight 0,43478260 0,78260869 0,82608695 0,91304347geometric mean 0,4921095613 0,52517223 0,54823488 0,61195717

End of Table



700 1400 2100105 115 13

Hav Hav700 1400 2100115 125 14

Hav Hav700 1400 2100125 135 15

Hav Hav700 1400 2100135 145 16

test01 loopend 0,72727272 0,81818181 0,81818181 0,72727272test02 circle 0 0 0 0test03 straight 0,64285714 0,64285714 0,64285714 0,64285714test04 loopend 0,42857142 0,57142857 0,57142857 0,71428571test05 loopend 0,71428571 0,71428571 0,71428571 0,57142857test06 straight 0,30769230 0,46153846 0,69230769 0,84615384test07 straight 0,3 0,4 0,5 0,7test08 straight 0,26923076 0,46153846 0,46153846 0,57692307test09 straight 0,59574468 0,68085106 0,78723404 0,87234042test10 straight 0,71428571 0,78571428 0,82142857 0,82142857test11 loopbeginning 0 0,10526315 0,10526315 0,26315789test12 loopmiddle 0,34782608 0,36956521 0,43478260 0,52173913test13 noloop 0,45454545 0,48484848 0,57575757 0,63636363test14 straight 0,82352941 0,85882352 0,90588235 0,91764705test15 loopend 0,7 0,75 0,9 0,9test16 loopend 0,5333333 0,6 0,5333333 0,46666666test17 loopend 0,375 0,375 0,625 0,625test18 loops 0 0 0 0test19 straight 0,14814814 0,22222222 0,33333333 0,40740740test20 straight 0,85185185 0,88888888 0,88888888 0,88888888test21 straight 0,82258064 0,93548387 0,93548387 0,95161290test22 loopend 0,77777777 0,77777777 0,77777777 0,77777777test23 smallloopend 0,6 0,6 0,5 0,6test24 smallloopend 0,36363636 0,45454545 0,27272727 0,27272727test25 smallloopend 0,4 0,4 0,2 0,6test26 loopmiddle 0 0 0,1 0,2test27 loopmiddle 0 0 0 0

45


700 1400 2100105 115 13

Hav Hav700 1400 2100115 125 14

Hav Hav700 1400 2100125 135 15

Hav Hav700 1400 2100135 145 16

test28 straight 0,30769230 0,38461538 0,46153846 0,53846153test29 straight 0,07142857 0,35714285 0,5 0,71428571test30 straight 0,72413793 0,82758620 0,86206896 0,89655172test31 loopend 0,46153846 0,61538461 0,69230769 0,76923076test32 loopend 0,5 0,5 0,625 0,625test33 straight 0,2 0,2 0,4 0,4test34 loopend 0,5 0,5 0,72222222 0,88888888test35 straight 0,25 0,5 0,625 0,75test36 straight 0,78378378 0,86486486 0,86486486 0,918918918test37 straight 0,15789473 0,26315789 0,31578947 0,578947368test38 straight 0,56 0,64 0,68 0,84test39 loop 0 0 0 0test40 circle 0 0 0 0test41 straight 0,81481481 0,85185185 0,87037037 0,925925925test42 loopend 0,731707317 0,78048780 0,87804878 0,926829268test43 loopend 0,428571428 0,42857142 0,14285714 0,571428571test44 straight 0,5 0,64285714 0,64285714 0,714285714test45 straight 0,52173913 0,60869565 0,73913043 0,782608695test46 straight 0,53571428 0,60714285 0,71428571 0,821428571test47 loopend 0,66666666 0,72222222 0,72222222 0,888888888test48 loopend 0,36363636 0,5 0,63636363 0,636363636test49 straight 0,76190476 0,80952380 0,85714285 0,857142857test50 straight 0,34782608 0,65217391 0,82608695 0,913043478geometric mean 0,4588788551 0,53758103 0,55553257 0,664365733

End of Table



800 1600 2400105 115 13

Hav Hav800 1600 2400115 125 14

Hav Hav800 1600 2400125 135 15

Hav Hav800 1600 2400135 145 16

test01 loopend 0,72727272 0,72727272 0,81818181 0,81818181test02 circle 0 0 0 0test03 straight 0,5 0,64285714 0,64285714 0,71428571test04 loopend 0,42857142 0,57142857 0,57142857 0,57142857test05 loopend 0,57142857 0,71428571 0,71428571 0,71428571test06 straight 0,23076923 0,30769230 0,46153846 0,61538461test07 straight 0,2 0,4 0,4 0,5test08 straight 0,26923076 0,38461538 0,46153846 0,53846153test09 straight 0,56521739 0,69565217 0,73913043 0,86956521test10 straight 0,64285714 0,75 0,82142857 0,82142852test11 loopbeginning 0 0 0,11111111 0,16666666test12 loopmiddle 0,28260869 0,34782608 0,39130434 0,47826086

46


800 1600 2400105 115 13

Hav Hav800 1600 2400115 125 14

Hav Hav800 1600 2400125 135 15

Hav Hav800 1600 2400135 145 16

test13 noloop 0,45454545 0,48484848 0,57575757 0,57575757test14 straight 0,81176470 0,87058823 0,88235294 0,91764705test15 loopend 0,65 0,75 0,8 0,85test16 loopend 0,5 0,5 0,42857142 0,42857142test17 loopend 0,5 0,5 0,625 0,625test18 loops 0 0 0 0test19 straight 0,11111111 0,14814814 0,25925925 0,33333333test20 straight 0,85185185 0,85185185 0,88888888 0,88888888test21 straight 0,77419354 0,91935483 0,93548387 0,95161290test22 loopend 0,72222222 0,77777777 0,72222222 0,83333333test23 smallloopend 0,55555555 0,55555555 0,55555555 0,44444444test24 smallloopend 0,36363636 0,36363636 0,36363636 0,36363636test25 smallloopend 0,2 0,4 0,4 0,2test26 loopmiddle 0 0 0,1 0,1test27 loopmiddle 0 0 0 0test28 straight 0,25 0,33333333 0,5 0,5test29 straight 0,07142857 0,28571428 0,5 0,71428571test30 straight 0,58620689 0,79310344 0,86206896 0,89655172test31 loopend 0,38461538 0,53846153 0,69230769 0,69230769test32 loopend 0,375 0,5 0,625 0,625test33 straight 0,2 0,2 0,4 0,4test34 loopend 0,5 0,55555555 0,61111111 0,77777777test35 straight 0,25 0,375 0,625 0,75test36 straight 0,78378378 0,86486486 0,86486486 0,91891891test37 straight 0,11111111 0,22222222 0,38888888 0,55555555test38 straight 0,52 0,6 0,68 0,84test39 loop 0 0 0 0test40 circle 0 0 0 0test41 straight 0,79629629 0,83333333 0,85185181 0,87037037test42 loopend 0,70731707 0,78048780 0,80487802 0,90243902test43 loopend 0,42857142 0,42857142 0,42857142 0,42857142test44 straight 0,42857142 0,5 0,64285714 0,78571428test45 straight 0,52173913 0,60869565 0,69565217 0,86956521test46 straight 0,53571428 0,60714285 0,67857142 0,75test47 loopend 0,70588235 0,70588235 0,64705882 0,76470588test48 loopend 0,38095238 0,42857142 0,52380952 0,57142857test49 straight 0,76190476 0,80952380 0,85714285 0,85714285test50 straight 0,30434782 0,65217391 0,73913043 0,82608695geometric mean 0,4166962380 0,52259476 0,55848651 0,60509734

End of Table

47

48

Appendix B

Configurations GraphsComparisons

Figure B.1: Haversine vs HereAPI - 400m

49



50



51

52

Appendix C

PDA Code

Copyright (C) 2016 HERE Global B.V. and/or its a�liated companies. Allrights reserved.

This software, including documentation, is protected by copyright controlledby HERE Global B.V. All rights are reserved. Copying, including reproducing,storing, adapting or translating, any or all of this material requires the priorwritten consent of HERE Global B.V. This material also contains confidentialinformation, which may not be disclosed to others without prior written consentof HERE Global B.V.

1 #i f n d e f CARLO PARKINGDETECTOR H2 #de f i n e CARLO PARKINGDETECTOR H3

4 // common in c l ud e s5 #inc lude <c a r l o /common/ d e f i n e s . h>6 #inc lude <c a r l o /common/SharedPointer . h>7 #inc lude <c a r l o / navcore /ParkingDetectorTypes . h>8

9 namespace c a r l o10 {11 namespace i n t e r n a l12 {13 // forward d e c l a r a t i o n s14 c l a s s NavCoreModuleImpl ;15 c l a s s ParkingDetectorImpl ;16

17 } // namespace i n t e r n a l18

19 /⇤⇤20 ⇤ Detects behaviour o f a moving car21 ⇤ The complete l i s t o f r e cogn i s ed modes i s de f i n ed in22 ⇤ c a r l o : : ParkingDetectorTypes : : ParkingStatus23 ⇤24 ⇤ The copy cons t ruc to r a l l ows you to have many in s t an c e s25 ⇤ o f ParkingDetector po in t ing to the same r e f e r e n c e26 ⇤ counted implementation in s t ance .27 ⇤/28 c l a s s CARLOAPI ParkingDetector29 {30

31 pub l i c :32

33 /⇤⇤34 ⇤ Defau l t con s t ruc to r .

53

35 ⇤36 ⇤ Creates a not i n i t i a l i z e d ParkingDetector ob j e c t .37 ⇤/38 ParkingDetector ( ) ;39

40 /⇤⇤41 ⇤ Copy cons t ruc to r .42 ⇤43 ⇤ @param [ in ] other Reference to the44 ⇤ ParkingDetector i n s t ance to copy .45 ⇤/46 ParkingDetector ( const ParkingDetector& other ) ;47

48 /⇤⇤49 ⇤ Assignment operator .50 ⇤51 ⇤ @param [ in ] other Ins tance to be as s i gned from .52 ⇤53 ⇤ @return Reference to t h i s i n s t ance .54 ⇤/55 ParkingDetector& operator=( const ParkingDetector& other ) ;56

57 /⇤⇤58 ⇤ Destructor .59 ⇤/60 ˜ParkingDetector ( ) ;61

62 /⇤⇤63 ⇤ I nd i c a t e s whether or not the ob j e c t i s f u l l y cons t ruc ted .64 ⇤65 ⇤ @return \c t rue i f the ob j e c t i s f u l l y constructed ,66 ⇤ \c f a l s e o therw i s e .67 ⇤/68 bool i s v a l i d ( ) const ;69

70 /⇤⇤71 ⇤ Asynchronously s t a r t d e t e c t i ng parking mode .72 ⇤73 ⇤ The c a l l e r must supply a Park ingDetec to rL i s t ene r ob j e c t to74 ⇤ r e c e i v e ParkingDetector c a l l b a c k s whi l e d e t e c t i on i s running75 ⇤ The cur rent method completes with the c a l l b a c k s :76 ⇤ on s t a r t d e t e c t i o n don e and on parking mode changed77 ⇤78 ⇤ @param [ out ] id The reque s t id to be used in79 ⇤ Park ingDetec to rL i s t ene r : : o n s t a r t d e t e c t i o n don e and80 ⇤ Park ingDetec to rL i s t ene r : : on parking mode changed81 ⇤ @return82 ⇤ CARLOERRORNONE i f the operat i on completes s u c c e s s f u l l y ,83 ⇤ CARLO ERROR NOT VALID i f d e t e c t i on i s not proper ly i n i t i a l84 ⇤/85 ErrorCode s t a r t d e t e c t i o n ( RequestId& id ) ;86

87 /⇤⇤88 ⇤ Synchronously cance l a l l d e t e c t i on a c t i v i t i e s .89 ⇤90 ⇤ Parking de t e c t i on i s cance l ed and � no more c a l l b a c k s .91 ⇤92 ⇤ @param [ in ] id The reque s t id p r ev i ou s l y returned by any93 ⇤ o f the asynchronous methods in t h i s c l a s s .94 ⇤ @return95 ⇤ CARLOERRORNONE i f the operat i on completes s u c c e s s f u l l y ,96 ⇤ CARLO ERROR NOT VALID i f de t e c t i s not proper ly i n i t i a l i z e d ,

54

97 ⇤ CARLO ERROR INVALID PARAMETERS i f passed id does not match98 ⇤ cur rent de t e c t i on s e s s i o n99 ⇤/

100 ErrorCode cance l ( RequestId id ) ;101

102 /⇤⇤103 ⇤ Synchronously re turn the cur rent parking mode .104 ⇤105 ⇤ @param [ out ] s t a tu s parking mode to be returned as r e f e r e n c e106 ⇤ @return107 ⇤ CARLOERRORNONE i f the opera t i on completes s u c c e s s f u l l y ,108 ⇤ CARLO ERROR NOT VALID i f d e t e c t i on i s not proper ly

i n i t i a l i z e d109 ⇤/110 ErrorCode get parking mode (111 ParkingDetectorTypes : : ParkingStatus& s ta tu s ) const ;112

113 pr i va t e :114

115 SharedPointer< i n t e r n a l : : ParkingDetectorImpl > m impl ;116

117 f r i e nd c l a s s i n t e r n a l : : NavCoreModuleImpl ;118 } ;119

120 } // namespace c a r l o121

122 #end i f // CARLO PARKINGDETECTOR H

Listing C.1: PDA API header implemented in C++

1 // header in c lude2 #inc lude <c a r l o / navcore /ParkingDetector . h>3 // pimpl in c lude4 #inc lude ”ParkingDetectorImpl . h”5 // i n t e r n a l i n c lude6 #inc lude ”common/LoggingMacros . h”7 namespace c a r l o8 {9 ParkingDetector : : ParkingDetector ( )

10 {11 }12

13 //��

14

15 ParkingDetector : : ParkingDetector ( const ParkingDetector& other )16 {17 m impl = other . m impl ;18 }19

20 //��

21

22 ParkingDetector&23 ParkingDetector : : operator=( const ParkingDetector& other )24 {25 i f ( t h i s != &other )26 {27 m impl = other . m impl ;28 }29

55

30 r e turn ⇤ t h i s ;31 }32

33 //��

34

35 ParkingDetector : : ˜ ParkingDetector ( )36 {37 }38

39 //��

40

41 bool42 ParkingDetector : : i s v a l i d ( ) const43 {44 r e turn m impl . get ( ) != NULL;45 }46

47 //��

48

49 ErrorCode50 ParkingDetector : : s t a r t d e t e c t i o n ( RequestId& id )51 {52 auto impl = m impl ;53 i f ( ! impl . i s v a l i d ( ) )54 {55 CLOGE(”ParkingDetector has not been i n i t i a l i z e d c o r r e c t l y ” )

;56

57 r e turn CARLO ERROR NOT VALID;58 }59

60 r e turn impl!s t a r t d e t e c t i o n ( id ) ;61 }62

63 // ��64

65 ErrorCode66 ParkingDetector : : c ance l ( RequestId id )67 {68 auto impl = m impl ;69 i f ( ! impl . i s v a l i d ( ) )70 {71 CLOGE(”ParkingDetector has not been i n i t i a l i z e d c o r r e c t l y ” )

;72


76 r e turn impl!cance l ( id ) ;77 }78

79 //��

80

81 ErrorCode

56

82 ParkingDetector : :83 get parking mode ( ParkingDetectorTypes : : ParkingStatus& s ta tu s )

const84 {85 auto impl = m impl ;86 i f ( ! impl . i s v a l i d ( ) )87 {88 CLOGE(”ParkingDetector has not been i n i t i a l i z e d c o r r e c t l y ” )

;89


93 r e turn impl!get parking mode ( s t a tu s ) ;94 }95

96 //��

97

98 } // c a r l o

Listing C.2: PDA API source code implemented in C++

1 #i f n d e f CARLO PARKINGDETECTORIMPL H2 #de f i n e CARLO PARKINGDETECTORIMPL H3

4 // module i n c l ud e s5 #inc lude <c a r l o / navcore /ParkingDetector . h>6 #inc lude <c a r l o / navcore /ParkingDetectorTypes . h>7 #inc lude <c a r l o / navcore / Park ingDetec to rL i s t ene r . h>8 #inc lude <c a r l o / navcore /RouterL i s tener . h>9 #inc lude <c a r l o / navcore /RouterPenalty . h>

10 #inc lude <c a r l o /common/ErrorCodes . h>11 #inc lude <c a r l o /common/GeoCoordinates . h>12 #inc lude <c a r l o / u t i l i t i e s /MapHelper . h>13

14 // i n t e r n a l i n c l ud e s15 #inc lude ”common/AtomicType . h”16 #inc lude ”common/ c a r l o s t d . h”17 #inc lude ”common/RefCountable . h”18 #inc lude ”common/RuntimeImpl . h”19 #inc lude ”common/ShutdownListener . h”20 #inc lude ”common/TimeUti ls . h”21 #inc lude ” rout ing /RouterImpl . h”22 #inc lude ”module/NavCoreModuleImpl . h”23 #inc lude ” po s i t i o n i n g /MapMatcherEngineListener . h”24 #inc lude ” po s i t i o n i n g /MapMatcherEngine . h”25

26 namespace c a r l o27 {28 namespace i n t e r n a l29 {30 /⇤⇤31 ⇤ The implementation f o r the ParkingDetector API .32 ⇤/33 c l a s s ParkingDetectorImpl : pub l i c RefCountable ,34 pub l i c ShutdownListener ,35 protec t ed MapMatcherEngineListener ,36 protec t ed RouterL i s tener37 {38 pub l i c :39 ParkingDetectorImpl ( ) ;

57

40

41 ParkingDetectorImpl ( RuntimeImpl⇤ runtime ,42 NavCoreModuleImpl⇤ nav core ,43 Park ingDetec to rL i s t ene r& l i s t e n e r ) ;44

45 ˜ParkingDetectorImpl ( ) ;46

47 // from ShutdownListener48 void on shutdown ( ) ;49

50 // from ParkingDetector51 ErrorCode s t a r t d e t e c t i o n ( RequestId& id ) ;52 ErrorCode cance l ( RequestId id ) ;53 ErrorCode54 get parking mode ( ParkingDetectorTypes : : ParkingStatus& s ta tu s )

const ;55

56 protec t ed :57 // from MapMatcherEngineListener58 v i r t u a l void on map match posit ion (59 const MapMatchedLocation& pos i t i on ,60 const ngeo : : p o s i t i o n i n g : : MapMatchedPosition&

ngeo pos ) ;61 // from RouterL i s t ener62 v i r t u a l void on ca l c u l a t e r ou t e done (63 RequestId r ou t e r e qu e s t i d ,64 const std : : vector< Route >& routes ,65 ErrorCode e r r o r ) ;66

67 pr i va t e :68 void on map match pos i t i on in t e rna l (69 const MapMatchedLocation& po s i t i o n ) ;70

71 void s t a r t d e t e c t i o n i n t e r n a l ( RequestId id ) ;72

73 void che ck t r a c e ( ) ;74

75 void c a l c u l a t e p a r k i n g s t a t u s ( ) ;76

77 void s t a r t c a l c u l a t e r o u t e s ( ) ;78

79 f l o a t g e t d r i v e n t r a c k u s i n g d i s t me t e r s (80 u in t 32 t d i s tance , u i n t 32 t& l o c a t i o n i nd ex ) ;81

82 f l o a t g e t r a t i o ( f l o a t dr iven t rack , f l o a t r ou t e l eng th ) ;83

84 pr i va t e :85 RuntimeImpl⇤ m runtime ;86 NavCoreModuleImpl⇤ m navcore ;87 Park ingDetec to rL i s t ene r& m l i s t e n e r ;88 AtomicType< RequestId > m cur r en t r eque s t i d ;89

90 s t r u c t RouteRequest91 {92 RouteRequest ( )93 : r o u t e r e q u e s t i d ( INVALID REQUEST ID )94 , c a l c u l a t e r ou t e don e ( f a l s e )95 , r ou t e l eng th ( 0u )96 , d r i v en d i s t an c e ( 0 )97 {98 }99 RequestId r o u t e r e q u e s t i d ;

58

100 bool c a l c u l a t e r ou t e don e ;101 u in t 32 t r ou t e l eng th ;102 f l o a t d r i v en d i s t an c e ;103 } ;104

105 RouteRequest m requests [ 3 ] ;106 AtomicType<ParkingDetectorTypes : : ParkingStatus>107 m status ;108 TimeStampMs m las t t ime ;109 std : : vector< GeoCoordinates > m trace ;110 SharedPointer< RouterImpl > m router impl ;111 } ;112 } // i n t e r n a l113 } // c a r l o114 #end i f // CARLO PARKINGDETECTORIMPL H

Listing C.3: PDA Implementation Header in C++

1 // header in c lude2 #inc lude ” park ingde t e c to r /ParkingDetectorImpl . h”3

4 namespace c a r l o5 {6 namespace i n t e r n a l7 {8 namespace9 {

10 /// s t a r t i n g d i s t anc e ( in meters ) when i t makes sense11 /// to s t a r t d e t e c t i on o f the d r i v i ng mode12 s t a t i c const u i n t 32 t INIT DISTANCE = 1300u ;13

14 /// wai t ing time ( in mi l i s e conds ) t i l l another p o s i t i o n15 /// i s added in the t r a c e16 s t a t i c const u i n t 32 t WAITING TIME = 1000u ;17

18 /// r equ i r ed d i s t anc e to f i nd three po in t s behind19 /// in order to check the s t a tu s o f the car20 /// d i s t an c e 0 = DISTANCE ⇤ 1 ;21 /// d i s t an c e 1 = DISTANCE ⇤ 2 ;22 /// d i s t an c e 2 = DISTANCE ⇤ 323 s t a t i c const u i n t 32 t DISTANCE = 400u ;24

25 /// the sho ld s f o r the r a t i o s o f the three d i s t an c e s26 /// above and t h e i r cor re spond ing rout ing d i s t an c e s27 s t a t i c const f l o a t THRESHOLD 0 = 1 . 1 5 ;28 s t a t i c const f l o a t THRESHOLD 1 = 1 . 2 5 ;29 s t a t i c const f l o a t THRESHOLD 2 = 1 . 4 ;30 }31

32 // ��33

34 ParkingDetectorImpl : : ParkingDetectorImpl (35 RuntimeImpl⇤ runtime ,36 NavCoreModuleImpl⇤ nav core ,37 Park ingDetec to rL i s t ene r& l i s t e n e r )38 : ShutdownListener ( runtime )39 , m runtime ( runtime )40 , m navcore ( nav core )41 , m l i s t e n e r ( l i s t e n e r )42 , m cu r r en t r eque s t i d ( INVALID REQUEST ID )43 , m status ( ParkingDetectorTypes : : ParkingStatus : :UNKNOWN)44 , m la s t t ime ( 0u )45 {

59

46 CLOGT( ”ParkingDetectorImpl i n i t i a l i z i n g s u c c e s s f u l ” ) ;47

48 // r e g i s t e r to RouterL i s tener v ia RouterImpl49 m router impl . r e s e t ( CARLONEW RouterImpl ( m runtime ,50 m navcore ,51 ⇤ t h i s ) ) ;52 }53

54 // ��55

56 ParkingDetectorImpl : : ˜ ParkingDetectorImpl ( )57 {58 run shutdown ( ) ;59

60 m runtime!un r e g i s t e r s hu tdown l i s t e n e r ( t h i s ) ;61 }62

63 // ��64

65 ErrorCode66 ParkingDetectorImpl : : s t a r t d e t e c t i o n ( RequestId& id )67 {68 CARLO ASSERT( m runtime!i s v a l i d ( ) ) ;69

70 RequestId new id = m runtime!c r e a t e r e q u e s t i d ( ) ;71

72 i f ( ! m cu r r en t r eque s t i d . compare se t va lue (73 INVALID REQUEST ID, new id ) )74 {75 CLOGW( ”Fa i l ed to s t a r t d e t e c t i on as76 prev ious r eque s t i s s t i l l ongoing ” ) ;77 r e turn CARLO ERROR BUSY;78 }79

80 AsyncCallBase⇤ c a l l =81 c r ea t e a sync ( th i s ,82 &ParkingDetectorImpl : : s t a r t d e t e c t i o n i n t e r n a l , new id ) ;83 i f ( c a l l )84 {85 id = new id ;86 m cur r en t r eque s t i d = id ;87 c a l l!s e t r e q u e s t i d ( new id ) ;88 m runtime!t a s k s ch edu l e r ( ) . add ( c a l l , ” c a r l o ” ) ;89

90 r e turn CARLOERRORNONE;91 }92

93 r e turn CARLOERRORNOMEMORY;94 }95

96 // ��97

98 void99 ParkingDetectorImpl : : s t a r t d e t e c t i o n i n t e r n a l ( RequestId id )

100 {101 m runtime!t a s k s ch edu l e r ( ) . a s s e r t c o n t e x t ( ” c a r l o ” ) ;102

103 ErrorCode e r r o r = CARLOERRORNONE;104

105 // r e g i s t e r to MapMatcherEngine106 m navcore!map matcher engine ( ) . r e g i s t e r l i s t e n e r ( t h i s ) ;107

60

108

109 AsyncCallBase⇤ c a l l =110 c r ea t e a sync ( &m l i s t ene r ,111 &Park ingDetec to rL i s t ene r : : on s t a r t d e t e c t i on done ,112 id , e r r o r ) ;113

114 i f ( c a l l )115 {116 c a l l!s e t r e q u e s t i d ( id ) ;117 m runtime!t a s k s ch edu l e r ( ) . add ( c a l l , ” c l i e n t ” ) ;118 }119

120 }121

122 //��

123

124 ErrorCode125 ParkingDetectorImpl : : c ance l ( RequestId id )126 {127 CLOGT( ”ParkingDetectorImpl : : c ance l ( ) ” ) ;128

129 ErrorCode e r r o r = CARLO ERROR INVALID PARAMETERS;130

131 i f ( ! m cu r r en t r eque s t i d . compare se t va lue (132 INVALID REQUEST ID, id ) )133 {134 i f ( m runtime!add cance l ed r eque s t ( id ) )135 {136 m runtime!r emove cance l ed reques t ( id ) ;137 // cance l ongoing route r eque s t s138 m navcore!map matcher engine ( ) . u n r e g i s t e r l i s t e n e r ( t h i s

) ;139 m status = ParkingDetectorTypes : : ParkingStatus : :UNKNOWN

;140

141 e r r o r = CARLOERRORNONE;142 }143 }144 r e turn e r r o r ;145 }146

147 //��

148 ErrorCode149 ParkingDetectorImpl : : get parking mode (150 ParkingDetectorTypes : : ParkingStatus& s ta tu s ) const151 {152 s t a tu s = m status . va lue ( ) ;153

154 r e turn CARLOERRORNONE;155 }156

157 //��

158

159 void160 ParkingDetectorImpl : : on map match posit ion (161 const MapMatchedLocation& pos i t i on ,

61

162 const ngeo : : p o s i t i o n i n g : : MapMatchedPosition& ngeo pos )163 {164 // t h i s c a l l might come on the g e o l o c a t i on s en s o r thread165 i f ( p o s i t i o n . map match . coo rd ina t e s . i s v a l i d ( ) )166 {167 // d i spatch to c a r l o thread168 i f ( m runtime!t a s k s ch edu l e r ( ) . on one o f motor s ( ” c a r l o ” ) )169 {170 on map match pos i t i on in t e rna l ( p o s i t i o n ) ;171 }172 e l s e173 {174 // t h i s should only get c a l l e d once the GeoLocator c a l l175 // on loca t i on updated synchronous ly176 AsyncCallBase⇤ c a l l = c r ea t e a sync (177 th i s , &ParkingDetectorImpl : :178 on map match pos i t i on inte rna l , p o s i t i o n ) ;179 c a l l!s e t r e qu e s t i d n e ed ed ( f a l s e ) ;180 c a l l!s e t p r i o r i t y ( AsyncCallBase : : POLL ) ;181 m runtime!t a s k s ch edu l e r ( ) . add ( c a l l , ” c a r l o ” , t rue ) ;182 }183 }184 }185

186 //��

187

188 void189 ParkingDetectorImpl : :190 on map match pos i t i on in t e rna l ( const MapMatchedLocation& po s i t i o n

)191 {192 CARLO ASSERT(m runtime!t a s k s ch edu l e r ( ) . a s s e r t c o n t e x t ( ” c a r l o ” )

) ;193

194 TimeStampMs now time = po s i t i o n . input . timestamp ;195 i f ( m las t t ime + WAITING TIME <= now time )196 {197 m las t t ime = now time ;198 m trace . push back ( p o s i t i o n . map match . coo rd ina t e s ) ;199 che ck t r a c e ( ) ;200 }201 }202

203 //��

204

205 void206 ParkingDetectorImpl : : ch e ck t r a c e ( )207 {208 u in t 32 t d i s t anc e = 0u ;209 i f ( m trace . s i z e ( ) > 2u )210 {211 u in t 32 t i t = m trace . s i z e ( ) � 1u ;212 f o r ( ; i t > 0u ; �� i t )213 {214 d i s t anc e += MapHelper : :215 d i s t ance met e r s ( m trace [ i t ] , m trace [ i t �1] ) ;216

217 i f ( d i s t anc e >= INIT DISTANCE )

62

218 {219 s t a r t c a l c u l a t e r o u t e s ( ) ;220 m trace . e r a s e (221 m trace . begin ( ) , m trace . begin ( ) + i t ) ;222 break ;223 }224 }225 }226 }227

228 //��

229

230 void231 ParkingDetectorImpl : : s t a r t c a l c u l a t e r o u t e s ( )232 {233 CARLO ASSERT ( m trace . s i z e ( ) > 1u ) ;234

235 RoutePlan route p l an ;236 Locat ion l o c ;237 u in t 32 t i t = 0u ;238 f o r ( ; i t < 3u ; i t++ )239 {240 ErrorCode e r r o r ;241 u in t 32 t l o c i nd ex = m trace . s i z e ( ) � 1u ;242 r ou t e p l an . waypoints . c l e a r ( ) ;243

244 m requests [ i t ] . d r i v en d i s t an c e =245 g e t d r i v e n t r a c k u s i n g d i s t me t e r s (246 DISTANCE ⇤ ( i t + 1u ) , l o c i nd ex ) ;247

248 l o c . g eo po in t = m trace [ l o c i nd ex ] ;249 r ou t e p l an . waypoints . push back ( l o c ) ;250

251 l o c . g eo po in t = m trace [ m trace . s i z e ( )� 1u ] ;252 r ou t e p l an . waypoints . push back ( l o c ) ;253

254 e r r o r = m router impl!c a l c u l a t e r o u t e (255 route p lan ,256 RouterOptions ( ) , RouterPenalty ( ) ,257 m requests [ i t ] . r o u t e r e q u e s t i d ) ;258 i f ( e r r o r != CARLOERRORNONE )259 {260 CLOGF( ”Error on c a l c u l a t e r o u t e method %l l u . ” , e r r o r )

;261 }262 }263 }264

265 //��

266

267 void268 ParkingDetectorImpl : : o n c a l c u l a t e r ou t e done (269 RequestId r ou t e r e qu e s t i d ,270 const std : : vector< Route >& routes ,271 ErrorCode e r r o r )272 {273 CARLO ASSERT(m runtime!t a s k s ch edu l e r ( ) . a s s e r t c o n t e x t ( ” c l i e n t ”

) ) ;

63

274

275 i f ( r o u t e r e q u e s t i d == INVALID REQUEST ID )276 {277 CLOGF( ”Received broken on ca l c u l a t e r ou t e done response . ”

) ;278 r e turn ;279 }280

281 i n t 8 t r eques t f ound = �1;282 u in t 32 t i t = 0u ;283 f o r ( ; i t < 3 ; i t++ )284 {285 i f ( r o u t e r e q u e s t i d == m requests [ i t ] . r o u t e r e q u e s t i d )286 {287 r eques t f ound = i t ;288 break ;289 }290 }291

292 i f ( r eques t f ound > �1 )293 {294 CLOGI( ”Received route f o r r eque s t id : ” ,295 m requests [ r eques t f ound ] . r o u t e r e q u e s t i d ) ;296

297 m requests [ r eques t f ound ] . c a l c u l a t e r ou t e don e = true ;298

299 i f ( e r r o r == CARLOERRORNONE && route s . s i z e ( ) >= 1 )300 {301 CLOGI( ”Received l ength f o r r eque s t id : ” ,302 m requests [ r eques t f ound ] . r o u t e r e q u e s t i d ) ;303 route s . f r on t ( ) . g e t l e ng th (304 m requests [ r eques t f ound ] . r ou t e l eng th ) ;305 }306

307 }308 e l s e309 {310 CLOGF( ”Received unrequested on ca l cu l a t e r ou t e done

response ” ,311 e r r o r ) ;312 r e turn ;313 }314

315 i f ( m requests [ 0 ] . c a l c u l a t e r ou t e don e &&316 m requests [ 1 ] . c a l c u l a t e r ou t e don e &&317 m requests [ 2 ] . c a l c u l a t e r ou t e don e )318 {319 f o r ( i t = 0u ; i t < 3u ; i t++ )320 {321 m requests [ i t ] . r o u t e r e q u e s t i d = INVALID REQUEST ID ;322 m requests [ i t ] . c a l c u l a t e r ou t e don e = f a l s e ;323 }324

325

326 AsyncCallBase⇤ c a l l = c r ea t e a sync ( th i s ,327 &ParkingDetectorImpl : : c a l c u l a t e p a r k i n g s t a t u s ) ;328 c a l l!s e t r e q u e s t i d ( m cur r en t r eque s t i d . va lue ( ) ) ;329 m runtime!t a s k s ch edu l e r ( ) . add ( c a l l , ” c a r l o ” , t rue ) ;330

331 r e turn ;332 }333

64

334 }335

336 // ��337

338 void339 ParkingDetectorImpl : : on shutdown ( )340 {341 CLOGD( ”Shutt ing down ParkingDetectorImpl ” ) ;342 cance l ( m cu r r en t r eque s t i d . va lue ( ) ) ;343 }344

345 //��

346

347 f l o a t348 ParkingDetectorImpl : : g e t d r i v e n t r a c k u s i n g d i s t me t e r s (349 u in t 32 t d i s tance , u i n t 32 t& l o c a t i o n i nd ex )350 {351 f l o a t d i s t = 0 ;352 whi le ( l o c a t i o n i nd ex >= 1 && d i s t <= di s t ance )353 {354 d i s t += MapHelper : : d i s t ance met e r s355 ( m trace [ l o c a t i o n i nd ex ] , m trace [ l o c a t i on index �1 ] ) ;356 l o c a t i on index ��;357 }358 r e turn d i s t ;359 }360

361 //��

362

363 f l o a t364 ParkingDetectorImpl : :365 g e t r a t i o ( f l o a t dr iven t rack , f l o a t r ou t e l eng th )366 {367 f l o a t co s t = 0 ;368

369 i f ( r ou t e l eng th <= 0 )370 {371 CLOGF( ” Inva l i d opera t i on . ” ) ;372 }373 e l s e374 {375 i f ( d r i v en t r a ck < r ou t e l eng th )376 {377 co s t = 1 ;378 }379 e l s e380 {381 co s t = dr i v en t r a ck / r ou t e l eng th ;382 }383 }384 r e turn co s t ;385 }386

387 //��

388

389 void

65

390 ParkingDetectorImpl : : c a l c u l a t e p a r k i n g s t a t u s ( )391 {392 CARLO ASSERT(m runtime!t a s k s ch edu l e r ( ) . a s s e r t c o n t e x t ( ” c a r l o ”

) ) ;393

394 ParkingDetectorTypes : : ParkingStatus l a s t s t a t u s = m status .va lue ( ) ;

395

396 m status . s e t v a l u e ( ParkingDetectorTypes : : ParkingStatus : :DRIVING ) ;

397

398 f l o a t c o s t 0 = g e t r a t i o399 ( m requests [ 0 ] . d r i v en d i s t anc e , m requests [ 0 ] . r ou t e l eng th )

;400 f l o a t c o s t 1 = g e t r a t i o401 ( m requests [ 1 ] . d r i v en d i s t anc e , m requests [ 1 ] . r ou t e l eng th )

;402 f l o a t c o s t 2 = g e t r a t i o403 ( m requests [ 2 ] . d r i v en d i s t anc e , m requests [ 2 ] . r ou t e l eng th )

;404

405 i f ( c o s t 0 >= THRESHOLD 0 | |406 c o s t 1 >= THRESHOLD 1 | |407 c o s t 2 >= THRESHOLD 2 )408 {409 m status . s e t v a l u e (410 ParkingDetectorTypes : : ParkingStatus : :PARKING ) ;411 }412

413 i f ( l a s t s t a t u s != m status . va lue ( ) )414 {415 AsyncCallBase⇤ c a l l =416 c r ea t e a sync ( &m l i s t ene r ,417 &Park ingDetec to rL i s t ene r : :

on parking mode changed ,418 m cur r en t r eque s t i d . va lue ( ) , m status . va lue ( )

) ;419 i f ( c a l l )420 {421 c a l l!s e t r e q u e s t i d ( m cur r en t r eque s t i d . va lue ( ) ) ;422 m runtime!t a s k s ch edu l e r ( ) . add ( c a l l , ” c l i e n t ” ) ;423 }424 }425 }426 //

��

427 } // i n t e r n a l428

429 } // c a r l o

Listing C.4: PDA Implementation Source Code in C++

66

Appendix D

PDA Integration Test

1

2 #inc lude ”mobi l i tygraph /MobilityGraphModuleCommon . h”3

4 #inc lude ”NdsConstants . h”5 #inc lude ”TestBaseNavCore . h”6

7 #inc lude <g t e s t / g t e s t . h>8 #inc lude <gmock/gmock . h>9

10 #inc lude <c a r l o /common . h>11 #inc lude <common/LoggingMacros . h>12 #inc lude <common/ po s i t i o n i n g /GeoLocatorListener . h>13 #inc lude <common/Lockable . h>14 #inc lude ”PosServerSocket . h”15

16 #inc lude <c a r l o /common/ d e f i n e s . h>17 #inc lude <c a r l o /common/SharedPointer . h>18 #inc lude <algor ithm>19

20 #inc lude <c a r l o / navcore / Park ingDetec to rL i s t ene r . h>21 #inc lude <c a r l o / navcore /ParkingDetector . h>22 #inc lude <c a r l o / navcore /ParkingDetectorTypes . h>23

24 #inc lude <algor ithm>25 #inc lude <s t d i o . h>26

27 #inc lude <sys / time . h>28 #inc lude <iostream>29 #inc lude <f stream>30 #inc lude <s t r i ng>31 #inc lude <c s t r i ng>32 #inc lude <streambuf>33

34 us ing namespace c a r l o ;35 us ing namespace c a r l o : : i n t e r n a l ;36

37 us ing : : t e s t i n g : : ;38 us ing : : t e s t i n g : : Return ;39 us ing : : t e s t i n g : : ReturnRef ;40 us ing : : t e s t i n g : : Mock ;41 us ing : : t e s t i n g : : Invoke ;42 us ing : : t e s t i n g : : AnyNumber ;43 us ing : : t e s t i n g : : AtLeast ;

67

44 us ing : : t e s t i n g : : Matcher ;45 us ing : : t e s t i n g : : ByRef ;46 us ing : : t e s t i n g : : Eq ;47

48 c l a s s NavCoreModuleImpl ;49

50 //��

51

52 c l a s s ParkingDetectorListenerMock : pub l i c Park ingDetec to rL i s t ene r53 {54 pub l i c :55

56 MOCKMETHOD2( on s t a r t d e t e c t i on done ,57 void ( RequestId r eque s t i d ,58 ErrorCode e r r o r ) ) ;59

60 MOCKMETHOD2( on parking mode changed ,61 void ( RequestId r eque s t i d ,62 const ParkingDetectorTypes : : ParkingStatus& s ta tu s )

) ;63

64 } ;65

66 //��

67 s t a t i c const u i n t 32 t WAITING TIME DETECTION = 10000u ;68

69 c l a s s ParkingDetectorTest : pub l i c TestBaseNavCore70 {71 pub l i c :72 ParkingDetectorTest ( )73 : m req id ( INVALID REQUEST ID )74 {75 }76

77 s t a t i c void SetUpTestCase ( )78 {79 std : : remove ( ”map matcher . dat” ) ;80 ASSERT TRUE ( m pos server . s t a r t ( ) ) ;81 s l e e p ( 1 ) ; // wait f o r the thread to be running82 }83

84 s t a t i c void TearDownTestCase ( )85 {86 m pos server . stop ( ) ;87 s l e e p ( 1 ) ; // wait f o r the thread to be stopped88 }89

90 v i r t u a l void SetUp ( )91 {92 TestBaseNavCore : : SetUp ( ) ;93

94 ErrorCode e r r =95 m nav core . c r e a t e p a r k i n g d e t e c t o r (96 &m park i n g d e t e c t o r l i s t e n e r , m req id ) ;97 ASSERT TRUE( m req id != INVALID REQUEST ID ) ;98 ASSERT EQ( CARLOERRORNONE, e r r ) ;99

100 i f ( ! m s igna l . wait ( true , MAXTIMEOUTCREATE ) )

68

101 {102 m nav core . cance l ( m req id ) ;103 }104 m req id = INVALID REQUEST ID ;105

106 ASSERT TRUE( m parking . i s v a l i d ( ) ) ;107

108 }109

110 v i r t u a l void TearDown( )111 {112 m parking = ParkingDetector ( ) ;113 TestBaseNavCore : : TearDown( ) ;114 }115

116 pub l i c : // from NavCoreModuleListener117 void118 on c r e a t e pa rk i ng de t e c t o r done ( RequestId id ,119 ParkingDetector& parking ,120 c a r l o : : ErrorCode e r r o r )121 {122 ASSERT EQ( CARLOERRORNONE, e r r o r ) ;123 ASSERT EQ( m req id , id ) ;124 m parking = parking ;125 m signa l . s e t ( ) ;126 }127

128 pub l i c :129 void s e t s i g n a l 1 ( t e s t i n g : : Unused , t e s t i n g : : Unused )130 {131 m signa l . s e t ( ) ;132 }133

134 void s e t s i g n a l 2 ( t e s t i n g : : Unused , t e s t i n g : : Unused )135 {136 m signa l . s e t ( ) ;137 }138

139 bool w a i t f o r r e s u l t ( )140 {141 i f ( ! m s igna l . wait ( true , WAITING TIME DETECTION ) )142 {143 m parking . cance l ( m req id ) ;144 r e turn f a l s e ;145 }146 r e turn true ;147 }148

149 pub l i c :150 ParkingDetectorListenerMock m pa r k i n g d e t e c t o r l i s t e n e r ;151 ParkingDetector m parking ;152 RequestId m req id ;153

154 protec t ed :155 c a r l o : : i n t e r n a l : : S i gna l m s igna l ;156 s t a t i c PosServerSocket m pos se rver ;157 s t a t i c TrackSender m track sender ;158 } ;159

160 PosServerSocket ParkingDetectorTest : : m pos se rver =161 PosServerSocket ( ) ;162 TrackSender ParkingDetectorTest : : m track sender =

69

163 TrackSender ( ParkingDetectorTest : : m pos se rver ) ;164

165 // ��166

167 TEST F( ParkingDetectorTest , I nva l i d )168 {169 ParkingDetector parking ;170 EXPECT FALSE( parking . i s v a l i d ( ) ) ;171

172 RequestId req = INVALID REQUEST ID ;173 EXPECT EQ(174 CARLO ERROR NOT VALID, parking . s t a r t d e t e c t i o n ( req ) ) ;175

176 ParkingDetectorTypes : : ParkingStatus mode ;177 EXPECT EQ(178 CARLO ERROR NOT VALID, parking . get parking mode (mode) ) ;179 EXPECT EQ(180 ParkingDetectorTypes : : ParkingStatus : :UNKNOWN, mode ) ;181

182 EXPECT EQ( CARLO ERROR NOT VALID, parking . cance l ( req ) ) ;183

184 }185

186 // ��187

188 TEST F189 ( ParkingDetectorTest , StartDetect ionVal idTraceReturnsDriv ingMode )190 {191 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,192 on s t a r t d e t e c t i o n don e (193 Eq( ByRef ( m req id ) ) , CARLOERRORNONE ) )194 . Times ( 1 )195 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 1 ) ) ;196

197 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,198 on parking mode changed (199 Eq( ByRef ( m req id ) ) ,200 ParkingDetectorTypes : : ParkingStatus : : DRIVING) )201 . Times ( 1 )202 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 2 ) ) ;203

204 EXPECT EQ(205 CARLO ERRORNONE, m parking . s t a r t d e t e c t i o n ( m req id ) ) ;206

207 m track sender . c onve r t t r a ck ( ” parking / t race01 . nme” ) ;208

209 EXPECTTRUE( w a i t f o r r e s u l t ( ) ) ;210 }211

212 // ��213

214 TEST F215 ( ParkingDetectorTest , StartDetect ionVal idTraceReturnsParkingMode )216 {217 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,218 on s t a r t d e t e c t i o n don e (219 Eq( ByRef ( m req id ) ) , CARLOERRORNONE ) )220 . Times ( 1 )221 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 1 ) ) ;222

223 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,224 on parking mode changed (

70

225 Eq( ByRef ( m req id ) ) ,226 ParkingDetectorTypes : : ParkingStatus : : DRIVING) )227 . Times ( 0 ) ;228

229 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,230 on parking mode changed (231 Eq( ByRef ( m req id ) ) ,232 ParkingDetectorTypes : : ParkingStatus : :PARKING) )233 . Times ( 1 )234 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 2 ) ) ;235




244 // ��245

246 TEST F247 ( ParkingDetectorTest , StartDetectionInvalidTraceReturnsUnkownMode )248 {249 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,250 on s t a r t d e t e c t i o n don e (251 Eq(ByRef ( m req id ) ) ,CARLOERRORNONE) )252 . Times (1 )253 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 1 ) ) ;254


258 ParkingDetectorTypes : : ParkingStatus mode ;259 EXPECT EQ(260 CARLO ERRORNONE, m parking . get parking mode ( mode) ) ;261 EXPECT EQ( ParkingDetectorTypes : : ParkingStatus : :UNKNOWN,mode) ;262



268 // ��269

270 TEST F271 ( ParkingDetectorTest , StartDetect ionMult ip leTimesReturnsErrorBusy )272 {273 RequestId req = INVALID REQUEST ID ;274

275 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,276 on s t a r t d e t e c t i o n don e (277 Eq(ByRef ( m req id ) ) , CARLOERRORNONE) )278 . Times ( 1 )279 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 1 ) ) ;280

281 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,282 on parking mode changed (283 Eq( ByRef ( m req id ) ) ,284 ParkingDetectorTypes : : ParkingStatus : : DRIVING) )285 . Times ( 1 )286 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 2 ) ) ;

71

287

288

289 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,290 on s t a r t d e t e c t i o n don e (291 Eq( ByRef ( req ) ) , CARLOERRORNONE ) )292 . Times ( 0 ) ;293

294 EXPECT EQ(295 CARLO ERRORNONE, m parking . s t a r t d e t e c t i o n ( m req id ) ) ;296 EXPECT EQ(CARLO ERROR BUSY, m parking . s t a r t d e t e c t i o n ( req ) ) ;297



303 // ��304

305 TEST F306 ( ParkingDetectorTest , StartAndCancelDetectionReturnsNoError )307 {308 RequestId req = INVALID REQUEST ID ;309

310 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,311 on s t a r t d e t e c t i o n don e (312 Eq( ByRef ( m req id ) ) , CARLOERRORNONE) )313 . Times ( 1 )314 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 1 ) ) ;315

316 EXPECT CALL( m pa rk i n g d e t e c t o r l i s t e n e r ,317 on parking mode changed (318 Eq( ByRef ( m req id ) ) ,319 ParkingDetectorTypes : : ParkingStatus : : DRIVING) )320 . Times (1 )321 . WillOnce ( Invoke ( th i s ,&ParkingDetectorTest : : s e t s i g n a l 2 ) ) ;322

323



329 EXPECT EQ(330 CARLO ERROR INVALID PARAMETERS, m parking . cance l ( req ) ) ;331

332 EXPECT EQ(CARLOERRORNONE, m parking . cance l ( m req id ) ) ;333

334 ParkingDetectorTypes : : ParkingStatus mode ;335 EXPECT EQ(CARLOERRORNONE, m parking . get parking mode (mode) ) ;336 EXPECT EQ( ParkingDetectorTypes : : ParkingStatus : :UNKNOWN, mode) ;337

338 EXPECTTRUE( w a i t f o r r e s u l t ( ) ) ;339 }

Listing D.1: PDA Integration Test Code in C++

72

Bibliography

[1] Google Developers . The google c++ mocking framework.https://github.com/google/googletest. Online; accessed 2016.

[2] Ariel Shapira. Parking: The problem and the solution.http://goo.gl/22VFCJ, 2015. Online; accessed 2016.

[3] K. Back. Test Driven Development: By Example. ” Pearson Education,Inc. ”, 2003.

[4] Berklas. Gps exchange format. http://www.topografix.com/gpx.asp, 2008.Online; accessed 2016.

[5] Betke, Klaus. The nmea 0183 protocol.http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf, 2001. Online;accessed 2016.

[6] G. V. Brummelen. Heavenly Mathematics: The Forgotten Art of SphericalTrigonometry. Princeton University Press, 2013.

[7] Carl Franzen. Nokia’s ’here’ maps will power microsoft, facebook, amazon.http://goo.gl/PtxdCl, 2012. Online; accessed 2016.

[8] Dale DePriest. Nmea data. http://www.gpsinformation.org/dale, 2013.Online; accessed 2016.

[9] Eric Gakstatter. What exactly is gps nmea data? http://goo.gl/wCWUf0,2015. Online; accessed 2016.

[10] Eric Raymond. Gpsd - the architecture of open source applications.http://www.aosabook.org/en/gpsd.html, 2016. Online; accessed 2016.

[11] Eric Raymond. Gpsd: a gps service daemon. http://www.catb.org/gpsd,2016. Online; accessed 2016.

[12] P. Fleming and J. Wallace. How not to lie with statistics: The correct wayto summarize benchmark results. Communications of the ACM, page 4,1986.

[13] Garmin. What is gps? http://www8.garmin.com/aboutGPS/, 2016. Online;accessed 2016.

[14] Geografic Information Systems. Why is law of cosines more preferable thanhaversine when calculating distance between two latitude-longitude points?http://goo.gl/Z4uOjG, 2016. Online; accessed 2016.

73

[15] HERE. We are HERE. https://company.here.com/here, 2013. Online;accessed 2016.

[16] HERE. Find your way indoor, here. http://360.here.com/2015/12/07/new-world-here, 2015. Online; accessed 2016.

[17] ISO. Iso 8601:2004. http://goo.gl/7i5T4S, 2004. Online; accessed 2016.

[18] A. Manifesto. The agile movement. http://agilemethodology.org/, 2008.Online; accessed 2016.

[19] Movable Type Ltd. Calculate distance, bearing and morebetween latitude/longitude points. http://www.movable-type.co.uk/scripts/latlong.html, 2016. Online; accessed 2016.

[20] National Geo-spatial Intelligence Agency. World geodetic system 1984 (wgs84). http://goo.gl/nrvXhX, 2004. Online; accessed 2016.

[21] Peter Bennett. The nmea faq. http://www.kh-gps.de/nmea.faq, 1997. On-line; accessed 2016.

[22] Richard Trenholm. Nokia sells. http://goo.gl/EklPGL, 2015. Online; ac-cessed 2016.

[23] Siemens. About the company siemens. http://goo.gl/uSGPed, 2015. Online;accessed 2016.

[24] Siemens. Background information for smart parking. http://goo.gl/viMMJf,2015. Online; accessed 2016.

[25] T. Bray, Ed. The javascript object notation (json) data interchange format.https://www.rfc-editor.org/rfc/rfc7159.txt, 2014. Online; accessed 2016.

74

https://company.here.com/here

TRITA TRITA-ICT-EX-2016:104

www.kth.se

Enhancing Parking Behavior Detectionkth.diva-portal.org/smash/get/diva2:1085169/FULLTEXT01.pdfAbstract A review of navigation systems nowadays shows that new features are required

Documents