Ruttoptimering vid massbeställning av taxi

INOM

EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2016 ,

Ruttoptimering vid

massbeställning av taxi

GUSTAF ENGELBREKTSSON

KTH

Ruttoptimering vid massbeställning av taxi

GUSTAF ENGELBREKTSSON

Examensarbete kandidatnivå ICT-skolan

Industriell handledare: Anders Söderman, Claremont AB Examinator: Johan Montelius

TRITA-ICT-EX-2016:55

Referat

För att företags personal ska utvecklas kan anställda be- höva skickas på konferenser och kurser. Anställda behöver transporteras till och från sammankomster och för detta är taxi ett möjligt färdmedel. Claremont är ett Stockholms- baserat IT-konsultföretag som alltid har behov att utveck- la sina 220 konsulters kompetens, där taxi är ett vanligt transportmedel till sammankomster eller flygplatser. För att minska utgifter för transporter kan samåkning med taxi ske.

I dagsläget sker logistikplaneringen för samåkning ge- nom att företaget själva eller taxibolag manuellt utan hjälp av datorkraft försöker ta fram möjliga rutter för samåkning, rutter som i slutändan inte alltid blir bra. Kan denna pro- cess automatiseras och beräknas med datorkraft kan bra ruttförslag ges vilket resulterar i att planeringstid, restid och pengar sparas.

Problemet samåkning med taxi från en plats till flera eller från flera platser till en har modellerats som en instans av Vehicle Routing Problem. Vehicle Routing Problem be- skriver hur många och i vilken ordning ett eller flera fordon ska besöka olika destinationer.

En systemarkitektur har tagits fram där adresser ma-

tas in och ett förslag på rutter returneras till användaren

i form av en lista med adresser, där adresserna är gruppe-

rade i olika rutter. Visualisering sker även på en karta för

kontroll av lösningen och ackumulerad tid samt uppskattat

pris visas. Systemarkitekturen använder sig av avancerade

algoritmer och heuristiker i Open Source Routing Machine

Abstract

Route optimization of taxi bulk ordering

In order for companies’ staff to improve their knowledge employees may need to be sent to conferences and courses.

Employees needs transport to and from gatherings and for this taxi is a possible mean of conveyance. Claremont is a Stockholm based IT-consulting firm that always have the need to improve their 220 consultants’ competence, where taxi is a common mode of conveyance to gatherings or air- ports. To reduce expenditures, it is possible to use rideshar- ing with taxis.

Currently the logistics planning for ridesharing is per- formed by the company themselves or taxi companies man- ually without help from computer power, where they try to produce possible routes for ridesharing that in the end not always turns out good. If this process can be automa- tized and calculated with computer power it is possible to give satisfactory route suggestions which results in savings in planning time, travel time and costs.

The problem ridesharing with taxis from many-to-one or one-to-many locations has been modelled as an instance of the Vehicle Routing Problem. The Vehicle Routing Prob- lem describes how many and in which order one or multiple vehicles should visit multiple destinations.

A system architecture has been developed where ad-

dresses are inputted and a suggestion for routes is returned

to the user in the form of lists of addresses, where the ad-

dresses are grouped in different routes. Visualization is

also performed on a map for checking the solution and ac-

cumulated time with approximated price is displayed. The

system architecture uses advanced algorithms and heuris-

tics in the Open Source Routing Machine and Optaplanner

to solve the problem.

Innehåll

1 Inledning 1

1.1 Bakgrund . . . . 1

1.2 Problem . . . . 2

1.3 Syfte . . . . 2

1.4 Mål . . . . 2

1.5 Metod . . . . 2

1.6 Avgränsning . . . . 2

1.7 Disposition . . . . 3

2 Teoribakgrund 5 2.1 Vehicle Routing Problem . . . . 5

2.1.1 Olika probleminstanser . . . . 5

2.2 Prismodell för taxi . . . . 6

2.3 Redogörelse för använda verktyg . . . . 6

2.3.1 REST & MVC . . . . 6

2.3.2 Optaplanner . . . . 7

2.3.3 Spring . . . . 8

2.3.4 AngularJS & Leaflet . . . . 8

2.3.5 Open Source Routing Machine & Open Street Map . . . . 8

3 Metod & Genomförande 9 3.1 Utvecklingsprocess . . . . 9

3.1.1 Definition och identifikation av problem . . . . 9

3.1.2 Litteraturstudie . . . . 11

3.1.3 Planering av struktur, val av verktyg och utveckling av system 11 3.2 Testning . . . . 12

3.2.1 Testdata . . . . 12

3.2.2 Testsystem . . . . 12

3.3 Framtagning av prisuppgift för drift . . . . 13

4 Systemarkitektur 15

4.1 Översikt . . . . 15

4.2.1 Grafiskt gränssnitt . . . . 16

4.2.2 Bakomliggande struktur . . . . 18

4.3 Serverarkitektur . . . . 19

4.3.1 Övergripande struktur . . . . 20

4.3.2 Beräkning av kantvikter . . . . 20

4.3.3 Optimering: framtagning av lösning . . . . 20

4.3.4 Verifiering . . . . 21

4.4 Optimering av tid för beräkning . . . . 21

4.4.1 Identifikation av tidskrävande moment . . . . 22

4.4.2 Lokalsökning krävs . . . . 22

4.4.3 Konfiguration av Optaplanner . . . . 22

4.5 Slutgiltig tid för skapande av lösningsförslag . . . . 24

4.6 Kostnad för drift . . . . 24

4.6.1 Geocoding . . . . 24

4.6.2 Serverdrift . . . . 26

5 Diskussion och slutsatser 29 5.1 Återkoppling till syfte . . . . 29

5.2 Acceptabel förlängning i restid . . . . 29

5.3 Begränsningar med geocoding . . . . 30

5.4 Möjliga framtida arbeten . . . . 30

5.4.1 Alternativ systemarkitektur . . . . 30

5.4.2 Taxibokning via API . . . . 31

5.4.3 Bättre användarupplevelse . . . . 32

5.5 Alternativa lösningar & arbetets bidrag till forskning . . . . 32

5.6 Metoder och val av verktyg . . . . 32

Litteratur 33

Kapitel 1

Inledning

Samåkning med taxi kan spara in pengar hos taxiresenärer. Idag finns diverse web- baserade tjänster för samåkning med taxi där många bygger på att personer ett tag före resan skriver in sin startpunkt och destination, för att eventuellt paras ihop med lämpliga medpassagerare. Det är oklart vilka medpassagerarna blir, helt okända människor kan bli medpassagerare vilket ibland kan upplevas som mindre trevligt. Ibland kan det även krävas att planering sker ett tag före avresa.

Via är en tjänst som implementerar taxi-samåkning i realtid, i en applikation slås startpunkt och destination in och en lämplig taxi hittas direkt. Är för tillfäl- let endast tillgänglig i New York och Chicago, större städer med många taxibilar tillgängliga [34]. Bandwagon är en tjänst som finns för enstaka terminaler på flyg- platser och event. Här slås en destination in och en eventuell matchning ska ske inom tio minuter [4]. Taxi for Two liknar Bandwagon men har möjligheten att även i förväg hitta människor att samåka med [30]. Det dessa tjänster har gemensamt är att samåkning sker med okända människor.

1.1 Bakgrund

Claremont är ett IT-konsultföretag som de senaste åren växt kraftigt [25]. För att deras anställda ska utveckla sin kompetens behöver de ibland skicka många (över 220) av sina anställda på kurs eller konferens. Vanligtvis är det taxi exempelvis till Arlanda från konsulternas bostäder i Stockholmsområdet som är aktuellt som transportmedel. Idag sker planeringen för detta med manuellt arbete utan datorbe- räkning, där företaget antingen själva försöker ordna samåkning eller ber taxibolag lösa problemet. Kan denna beräkning utföras av en dator minskas arbetsbelastning- en.

Problemet att optimera körrutter från en och samma startpunkt till multipla

destinationer samt tvärtom är NP-svårt (förklaring i sektion 2.1), vilket medför

att optimala körrutter inte kan beräknas inom rimlig tid (förutom för väldigt små

instanser) [19]. En optimal lösning kan däremot approximeras [6], vilket kan ge

fungerande körrutter.

KAPITEL 1. INLEDNING

1.2 Problem

Beräkning av samåkning med taxi ska inte behöva ske manuellt utan beräkning ska kunna ske med datorkraft. Problemet samåkning med taxi behöver modelleras och för att beräkning ska kunna ske inom rimlig tid krävs en systemarkitektur som använder sig av avancerade algoritmer för att approximera optimala körrutter.

Arkitekturen måste vara skalbar för att kunna hantera större probleminstanser. För att systemet ska vara användarvänligt samtidigt som kontroll av föreslagna lösningar måste kunna ske krävs ett grafiskt gränssnitt.

1.3 Syfte

Syftet är att förenkla för grupper att ta sig hem och till punkter via samåkning.

Syftet för uppgiften är att ta reda på och redogöra för en systemarkitektur som löser detta problem inom rimlig tid.

1.4 Mål

Målet är en fungerande prototyp till en systemarkitektur som klarar av att approx- imera optimala körrutter för samåkning med Taxi. Uppdelning i flera taxibilar från olika startpunkter till en och samma destination samt olika destinationer med sam- ma startpunkt ska fungera. Indata ska vara i form av en lista på adresser, därefter ska en lösning på samåkningsproblemet hittas snabbt och presenteras. Att även ta fram en prisuppgift för drift bidrar till att se om systemet kan vara lönsamt. Sys- temarkitekturen ska bidra till ökad lönsamhet för samåkning inom skilda grupper samt mindre arbete för planering av samåkning. Samåkning bidrar till minskade transporter, vilket bidrar till minskade utsläpp och mindre trängsel.

1.5 Metod

Samåkningsproblemet har identifierats som en instans av Capacitated Open Vehicle Routing Problem (COVRP). Komplexa ramverk har hittats och en systemarkitektur har utvecklats och implementerats. Den mest tidskrävande delen av systemarkitek- turen har identifierats och prestandaoptimerats. API-tjänster för geocoding (över- sättning av adresser till koordinater) har undersökts för möjliggörande av framtag- ning av prisuppgift för drift.

1.6 Avgränsning

Fokus ska inte vara på tjänstens visuella design, grundläggande funktion före form kommer prioriteras. Fokus är att få till hyfsade lösningar för större probleminstanser inom kort tid, om arkitekturen även visar sig fungera bra för mindre probleminstan- ser får det ses som en bonus.

2

1.7. DISPOSITION

Arbetet i denna rapport fokuserar på Stockholm och exempelvis översättning från adresser till koordinater kommer inte diskuteras för andra regioner. Systemar- kitekturen i sig är dock inte tänkt att ha några geografiska begränsningar inbyggda, det som är regionspecifikt är kartunderlag.

En taxi förutsätts ta snabbaste vägen och inte den för kunden billigaste vägen, vilket medför att enbart körtid optimeras och inte kostnad. En taxi förutsätts ha rörliga priser, i verkligheten förekommer det fastpris till utvalda destinationer.

Kontakt och förhandling med företag som erbjuder API-tjänster kommer inte att ske förutom enstaka prisförfrågningar och förfrågningar om vad deras API-tjänster erbjuder.

1.7 Disposition

Det första kapitlet introducerade bakgrunden, problemet, syfte, mål och avgräns-

ning för uppsatsen. Kapitel 2 presenterar nödvändiga kunskaper för att förstå upp-

satsen. Kapitel 3 redogör för utvecklingsprocessen och hur samåkningsproblemet

med taxi lösts. Kapitel 4 presenterar den resulterande systemarkitekturen och drifts-

kostnad. Kapitel 5 diskuterar några problem och framtida arbeten.

Kapitel 2

Teoribakgrund

Detta kapitel redogör för teori som läsaren behöver bekanta sig med för att förstå rapporten. Sektion 2.1 redogör för Vehicle Routing Problem och dess klasser, sek- tion 2.2 visar en typisk prismodell för en taxi och sektion 2.3 presenterar de verktyg och ramverk som systemarkitekturen använder.

2.1 Vehicle Routing Problem

Handelsresandeproblemet (Travelling Salesman Problem (TSP)) beskriver i vilken ordning en handelsman ska besöka en uppsättning städer, där målet är att minimera restiden [23]. Vehicle Routing Problem (VRP) är en generalisering av TSP som först definierades 1959, där VRP beskriver i vilken ordning en eller flera lastbilar ska besöka multipla servicestationer från en huvudstation [7]. VRP och TSP är NP- svåra problem vilket betyder att probleminstanser inte går att lösa inom rimlig tid (förutom väldigt små) [19].

Typiskt för NP-svåra problem är att om en optimal lösning ska hittas måste exempelvis alla möjliga lösningar testas för att se vilken som är bäst. Komplexiteten för att testa alla möjliga lösningar blir inte polynomisk, vanligt är att för varje ökning i indata dubbleras antalet möjliga lösningar som måste testas. [18, s. 33-35]

För att hitta lösningar inom rimlig tid till det NP-svåra problemet VRP kan avancerade algoritmer användas som approximerar optimala lösningar [6]. Approx- imationsalgoritmer hittar lösningar i polynomisk tid (rimlig tid), men lösningar är inte optimala utan är istället nära optimala [18, s. 599].

2.1.1 Olika probleminstanser

VRP har utvecklas sedan 1959 och kan delas in i olika klasser, där några klasser är: [33]

• Capacitated VRP (CVRP). Varje kund (”servicestation” i originella defi-

nitionen) har ett i förväg känt behov av en handelsvara. Fordonsflottan består

KAPITEL 2. TEORIBAKGRUND

av ett fast antal fordon som utgår från en enda depå, där varje fordon har en fast kapacitet för antal handelsvaror som får plats.

• Open VRP (OVRP). I vanliga VRP behöver ett fordon åka tillbaks till depån när sista kunden i en slinga har besökts, i Open VRP behöver inte detta ske.

• Time Windowed VRP. Varje kund har ett tidsfönster för när ett fordon kan tillgodose ett behov. Exempelvis kanske en kund som väntar på en hem- leverans enbart är hemma vissa tider.

Dessa problemklasser kan kombineras, exempelvis kan CVRP och OVRP kom- bineras till COVRP vilket bildar en klass där fordon inte behöver åka tillbaks till depån efter sista kundbesöket och varje kund har ett visst behov av en handelsvara.

Fler problemklasser än de presenterade finns.

2.2 Prismodell för taxi

Kostnadsmodellen för en taxi kan förenklat bestå av en startkostnad och rörlig kostnad för avstånd och tid. Om c är startkostnad, a pris per timme, t antal timmar, b pris per kilometer och d antal körda kilometer kan sambandet definieras:

c + a ∗ t + b ∗ d

Om n är antalet rutter och i en rutt blir den totala kostnaden för samåkning

då:

X

i=1

(c + a ∗ t

+ b ∗ d

)

Prismodellen kompliceras för en riktig resa av exempelvis olika pris beroende på vilken tid på dygnet resan sker, fastpris till utvalda destinationer och extra avgifter vid vissa knutpunkter [27]. Att försöka definiera och ge ett exakt pris i ett program utan samarbete med taxibolag får därför anses för komplicerat. Syftet med prismodellen är att kunna ge en ungefärlig uppskattning för slutanvändarens pris, för att slutanvändaren därefter kan begära en offert från olika taxibolag.

2.3 Redogörelse för använda verktyg

2.3.1 REST & MVC

Representational State Transfer (REST) är en tillståndslös lättviktig klient-server arkitektur för kommunikation mellan nätverksapplikationer, där HTTP vanligtvis används som underliggande protokoll. REST är plattforms- och språkoberoende vilket medför mindre begränsningar än vissa alternativ till REST som exempelvis remote procedure call. [9, 8]

6

2.3. REDOGÖRELSE FÖR ANVÄNDA VERKTYG

Model-View-Controller (MVC) är en arkitektur där en applikation delas upp i tre delar. En Model behandlar data och kan exempelvis innehålla funktioner för att behandla data i en databas. En View är användarinterfacet, exempelvis HTML.

En Controller innehåller logiken som bestämmer vad View-delen ska visa och vad Model-delen ska göra. MVC är en kraftfull arkitektur som används av många po- pulära ramverk för webbapplikationer. [16]

2.3.2 Optaplanner

Optaplanner är en motor för optimering av planeringsproblem som definieras med villkorsprogrammering. Planeringsproblem såsom planering av tentamina och VRP kan modelleras och optimeras i Optaplanner, exempelvis finns VRP modellerat som ett exempel i Optaplanner. Planeringsproblem som modelleras i Optaplanner är NP-svåra, vilket innebär att Optaplanner använder avancerade algoritmer för att approximera en optimal lösning inom rimlig tid. [31]

Heuristik är problemberoende och kan ses som en algoritm som använder kva- lificerade gissningar för att lösa ett problem, nackdelen är att en lösning inte är garanterat optimal medan fördelen är att en lösning kan hittas inom rimlig tid.

En konstruktionsheuristik bygger en lösning snabbt som är avsedd att användas av exempelvis lokalsökning som kräver en lösning att utgå ifrån [31].

Lokalsökning utgår från en existerande lösning och förbättrar den. Lokalsökning använder en sökstig och utvärderar i varje steg vilket steg som ska tas näst. Ett exempel på en algoritm som använder sig av lokalsökning är Hill Climbing, som utgår från en existerande lösning för att sedan iterativt testa ändringar och välja bättre ändringar. Ett problem med Hill Climbing är att algoritmen kan fastna i ett lokalt optimum. [31]

Metaheuristik är ett algoritmramverk som till skillnad från heuristik är pro- blemoberoende. Metaheuristik använder sig precis som av heuristik kvalificerade gissningar där exempelvis lokalsökning är en möjlig algoritm som används av me- taheuristik. [12]

Ett exempel på en metaheuristik är tabusökning. Tabusökning fungerar på ett liknande sätt som lokalsökning men kommer ihåg möjliga steg som är tabu. Ta- busökning undviker tack vare minnet att fastna i lokala optimum. [31]

En generell lösningsfas för Optaplanner sker genom att en konstruktionsheuristik först snabbt tar fram ett lösningsförslag, som metaheuristik sedan utgår ifrån för att skapa lösningsförslag som är närmare den optimala lösningen. Metaheuristik kan vara exempelvis tabusökning. [31]

Optaplanner valdes framför alternativ på grund av dess stora möjligheter till

konfiguration av exempelvis vilka algoritmer som används, detta eftersom syste-

markitekturen har som mål att snabbt ta fram resultat kan algoritmer behöva ut-

värderas ur ett prestandaperspektiv. Optaplanner är dessutom skrivet i Java vilket

uppsatsarbetaren är bekant med, jämfört med exempelvis Lisp som ett möjligt al-

ternativ använder.

KAPITEL 2. TEORIBAKGRUND

2.3.3 Spring

Spring-ramverket är en plattform för Java som tillhandahåller infrastruktur för Java- applikationer. Stöd för att serialisera (Java-objekt till JSON) är inbyggt vilket gör det enkelt att konstruera en serverapplikation som följer REST och MVC. [17]

Spring har valts då många exempel för Spring från början använder REST samt då Spring är skrivet i Java kan Optaplanner byggas in i samma tjänst, om en plattform skrivet i ett annat språk än Java skulle Optaplanner behöva köras som en egen Java-server.

2.3.4 AngularJS & Leaflet

Eftersom REST används krävs det att en klient klarar av att skicka REST-förfrågningar till en server. AngularJS är ett ramverk för Javascript som gör det möjligt att ren- dera HTML-sidor dynamiskt med asynkron laddning [2]. AngularJS valdes framför alternativ eftersom det har ett inbyggt stöd för REST samt uppsatsarbetaren har begränsad erfarenhet utav AngularJS.

I användargränssnittet behöver lösningar kunna presenteras visuellt, detta för att snabbt kunna verifiera lösningar och under testning se att inga lösningar är för dåliga. Leaflet är ett Javascript-bibliotek som innehåller funktioner för att visa kartor och lager med linjer och markörer [1]. Leaflet valdes då det har tydliga lättanvända exempel samt stöd för flera olika karttjänster.

2.3.5 Open Source Routing Machine & Open Street Map

Open Street Map (OSM) är en öppen karttjänst där användare själva kan uppdatera kartan. Då OSM är öppen data är det möjligt för en användare att få tillgång till all data utan begränsningar [26]. Detta kan jämföras med stängda karttjänster såsom Google Maps, Hitta & Eniro där det inte är tillåtet eller möjligt att exportera kartdatabaser. En nackdel med OSM är att gatunummer i Sverige vanligtvis inte finns vilket gör att OSM inte kan användas för att få koordinater från adresser (geocoding).

Tjänster såsom Google Maps låter en användare att i realtid beräkna rutter med begränsningar. Open Source Routing Machine (OSRM) är skrivet i C++ och använder sig av kartdata från OSM för att beräkna rutter i realtid. Eftersom OSRM är öppet och möjligt att själv köra finns inga begränsningar för antalet maximala förfrågningar som får ske. [22]

8

Kapitel 3

Metod & Genomförande

Detta kapitel redogör för utvecklingsprocessen i sektion 3.1 där det förklaras hur problemet samåkning med taxi definieras, redogör för testning i sektion 3.2 och framtagning av prisuppgift för driftsättning av systemet i sektion 3.3.

3.1 Utvecklingsprocess

Ett mål är att lösningsförslag ska ges snabbt, vilket innebär att från grunden skapa avancerade algoritmer som löser problemet blir för tidskrävande och medför en hög risk. Alternativet är att konstruera ett komplext system av komplexa pusselbitar, vilket sparar tid och medför lägre risk.

Vid definition och identifikation av problemet i sektion 3.1.1 valdes en kvalitativ metod med en induktiv ansats, eftersom kvalitativ forskning är lämpligt när ämnen behöver förstås [15]. Vid utveckling i de tre utvecklingsfaserna i sektion 3.1.3 valdes en mer deduktiv ansats med en kvantitativ metod där ändringar gjordes som sedan testades med stora datamängder för att observera resultat, detta eftersom kvanti- tativ forskning är lämpligt när mätbara resultat från experiment kan ges [15].

3.1.1 Definition och identifikation av problem

En förstudie skedde där problemet definierades och identifierades. Möten med An- ders Söderman från Claremont AB skedde, där Anders presenterade problemet som Claremont hade och vad som skulle behöva lösas. Problemet definierades som be- räkning av samåkning i stor skala för taxi till en och samma punkt från flera desti- nationer, eller från en och samma punkt till flera destinationer.

Problemet identifierades till en instans av COVRP (Capacitated Open Vehicle Routing Problem, sektion 2.1.1), där

1. den gemensamma plats som samåkning ska ske till eller från motsvarar en depå i VRP

2. varje passagerares behov av antal varor är ett (en passagerare vid varje plats)

KAPITEL 3. METOD & GENOMFÖRANDE

gemensam plats

1

1

1

1

1 1

1

1

1

Figur 3.1: COVRP för samåkning. Cirkel representerar en passagerare, siffran inuti behov.

3. varje taxi har kapaciteten fyra passagerare 4. kantvikten är restiden (inte kostnad).

Figur 3.1 illustrerar hur samåkningsproblemet ses som en COVRP-instans. Varje cirkel är en passagerares plats som ska besökas och i varje cirkel visas behovet. Då en taxi har plats för max fyra passagerare blir antalet passagerare för varje rutt 1-4. Notera även att det i figuren endast förekommer en kant till den gemensamma platsen för varje rutt i (C)OVRP. Detta kan jämföras med (C)VRP där en taxi behöver besöka den gemensamma platsen både före första passageraren och efter den sista i en rutt, vilket i en graf bildar två kanter till den gemensamma platsen i varje rutt istället för en.

När samåkningsproblemet ses som en komplett graf (kanter mellan alla noder) där den gemensamma platsen är en nod och varje passagerare en nod, beror antalet kanter i en komplett graf på antalet noder n: [35]

n 2

!

= n(n − 1) 2

Figur 3.2 illustrerar denna komplexitet för antalet kanter. Denna komplexitet in- nebär att antalet avstånd som behöver beräknas växer ungefär i O(n

), vilket gör

10

3.1. UTVECKLINGSPROCESS

gemensam plats

a

b c

d

Figur 3.2: Komplexiteten för antalet kanter.

det möjligt att beräkna kantvikter inom rimlig tid, förutsatt att exempelvis inget externt API behöver anropas en gång för varje kant.

3.1.2 Litteraturstudie

Litteraturstudier genomfördes kontinuerligt under arbetets gång. När problemet identifierades bestod informationssökning av taxi-specifik litteratur vilket inte bi- drog till en gynnsam identifikation. Litteratur om ”one-to-many”, ”many-to-one”

och ”one-to-many-to-one” hittades sedan, problemklasser där exempelvis ett fordon ska från en punkt till flera olika [14]. Efter det inhämtades och studerades litteratur som berör VRP. Dokumentation till de verktyg som användes studerades före samt under utvecklingsfasen.

3.1.3 Planering av struktur, val av verktyg och utveckling av system I denna fas delades först systemarkitekturen in i delar och verktyg i form av ramverk valdes. Utvecklingen delades sedan in i tre utvecklingsfaser. Utveckling av använ- dargränssnittet skedde parallellt med alla tre utvecklingsfaser. Utvecklingsfaserna var följande:

1. Få alla delar att samverka. Målet var att fånga in användardata, skicka det till en serverdel som stoppar in användardatan i alla ramverk som används och sedan visar någonting på en karta för användaren. Syftet med denna del var att få en fungerande pipeline-arkitektur för hela systemarkitekturen som sedan kunde vidareutvecklas.

2. Anpassning till ändamål. Målet var att anpassa systemarkitekturen till det definierade problemet taxi-samåkning och returnera fungerande lösningar.

3. Prestandaoptimering av systemet. Identifikation av tidskrävande faser

under uträkningen och optimera dem genom att exempelvis konfigurera ram-

verk för prestanda.

KAPITEL 3. METOD & GENOMFÖRANDE

3.2 Testning

Under utvecklingen skedde testning kontinuerligt genom att adresser eller koordina- ter matades in i systemet för att observera utfall. Syftet med testdatan som presen- teras i sektion 3.2.1 var att med hjälp av testdatan som underlag kunna utvärdera systemarkitekturens prestanda och precision för lösningsförslag, där bland annat olika metaheuristiker i Optaplanner kunde jämföras med varandra med avseende på prestanda och precision.

3.2.1 Testdata

Vid testning av hela systemet förutom delen med adressöversättning användes fem olika probleminstanser i varierande storlek, där koordinater användes direkt och steget för adressöversättning utelämnades.

1. Tre destinationer med en sjö som separerar några koordinater. Förväntat ut- fall: minst två taxibilar ska användas, ingen rutt ska gå en onödig omväg runt hela sjön.

2. Tre destinationer, två norrut längs en motorväg och en söderut. Förväntat utfall: de två destinationerna norrut får samåka medan destinationen söderut får en egen taxi.

3. 13 destinationer i Stockholmsområdet, med ett specialfall där två destinatio- ner är fågelvägen väldigt nära varandra men separerade med ett vattendrag.

Förväntad utfall: destinationerna som separeras av ett vattendrag tilldelas olika taxibilar och de andra destinationerna får en fungerande lösning.

4. 261 byggnadsminnen i Stockholms län, gemensam plats Östermalmstorg. Syf- tet var att testa hastigheten för systemet, kontrollera ackumulerad restid, prisapproximation samt visuellt kontrollera föreslagen lösning. Datan hämta- des som en KML-fil från [20] och ett enklare program i Python skapades för att konvertera KML-filen till JSON-format för Javascript.

5. 189 kyrkliga kulturminnen i Stockholms län, gemensam plats Arlanda. Syftet och tillvägagångssättet var samma som med 4 och datan hämtades från [21].

3.2.2 Testsystem

För testning användes Ubuntu 16.04 körandes i en virtuell maskin (VirtualBox) på ett Windowssystem. Den virtuella maskinen hade tillgång till fyra processorkärnor med frekvensen 4,6GHz och 4GB RAM. Vid testning kördes applikationen direkt i utvecklingsverktyget JetBrains IntelliJ IDEA som använde sig utav Spring Boot.

12

3.3. FRAMTAGNING AV PRISUPPGIFT FÖR DRIFT

3.3 Framtagning av prisuppgift för drift

Två kostnadsdelar behövde undersökas, pris för serverdrift samt pris för geocoding.

För serverdrift identifierades krav och en exempelsida för molndrift hittades.

För geocoding identifierades krav för tjänsten och en jämförelse skedde sedan där APIer undersöktes och testades. För att förenkla testning förutsattes att ett API ger samma svar som respektive karttjänst, där sökning på kartan skedde utzoomat till Sverige (förhindra lyft för lokala resultat) och där ”, Sverige” las till i söksträngen för att begränsa resultat till Sverige. Undantaget för denna metodik var Mapbox där APIet användes direkt.

Prisuppgift för geocoding skedde genom att respektive dokumentation studera-

des och tolkades. I fallet med Googles API för geocoding kontaktades Google för

en prisuppgift samt deras klient-API testades genom att i hög frekvens använda

geocoding med hjälp av en hemsida [5] som skickade geocoding-förfrågor med hög

frekvens till Googles API.

Kapitel 4

Systemarkitektur

I detta kapitel presenteras systemarkitekturen. I sektion 4.1 presenteras en översikt för systemarkitekturen, i sektion 4.2 presenteras klientarkitekturen, i sektion 4.3 presenteras serverarkitekturen, i sektion 4.4 beskrivs hur systemarkitekturen pre- standaoptimerats, i sektion 4.5 presenteras slutgiltig tid för att hitta lösningar samt i sektion 4.6 har en prisuppgift för drift tagits fram.

4.1 Översikt

AngularJS Synligt för

användaren Spring

Indata Geocoding

Leaflet

REST OSRM Optaplanner

REST

Figur 4.1: Översikt för systemarkitekturen med använda ramverk.

Systemarkitekturen kan delas in i två samverkande delar, en klientdel och en

serverdel. Klientdelen består av geocoding och det grafiska gränssnitt användaren

ser, klientdelen körs i en vanlig webbläsare. Serverdelen tar emot en förfrågan från

klientdelen och tar fram ett förslag på samåkning som sedan returneras till använ-

daren. I figur 4.1 ses hur de olika använda ramverken samverkar med varandra,

KAPITEL 4. SYSTEMARKITEKTUR

1

{

2

commonLocation: {

3

id: 0,

4

address: "Arlanda",

5

latitude: 59.424617,

6

longitude: 17.935052

7

},

8

locations: [ // Lista där varje objekt

9

{ // är en passagerares plats.

10

id: 1, // Unikt ökande id-nummer.

11

address: "Kistagången 16, Kista",

12

latitude: 59.404343,

13

longitude: 17.949938

14

},

15

{

16

id: 2,

17

...

18

}

19

...

20

]

21

}

Figur 4.2: Format för kommunikation mellan klient och server med exempeldata.

där den röda rutan är klientdelen och den gröna rutan är serverdelen. Kommuni- kation sker mellan med REST via HTML POST, datans utseende som skickas från AngularJS till Spring syns i figur 4.2.

4.2 Klientarkitektur

Hela klientarkitekturen exekveras i en vanlig webbläsare där HTML & CSS används för exempelvis fält och knappar. Javascript med AngularJS används för logik och bakomliggande struktur. I sektion 4.2.1 presenteras det grafiska gränssnittet och i sektion 4.2.2 presenteras den bakomliggande strukturen.

4.2.1 Grafiskt gränssnitt

Det grafiska gränssnittet kontrolleras av användaren och styr strukturen bakom.

Det grafiska gränssnittet visas i figur 4.3, för illustrationen har kartan förmins- kats, knappar med testfall tagits bort och endast ett ruttförslag med text är synligt istället för samtliga. På kartan kan även ses att geocoding via Mapbox har returne-

16

4.2. KLIENTARKITEKTUR

Figur 4.3: Lösningsförslag för samåkning där Bromma Flygplats är gemensam plats.

rat felaktig plats för ”Polishögskolan” som i verkligheten är placerad en bit längre norrut.

För användaren finns två textfält för inmatning av data, i ett skrivs adressen för den gemensamma samåkningsplatsen in och i det andra skrivs varje passagerares adress in separerade med semikolon (;). Klickar användaren på knappen ”Calculate”

tar bakomliggande struktur hand om logiken och uppdaterar sidan när ett svar erhålls. Presentation sker genom att samtliga ruttförslag visas på en karta och varje rutt skrivs ut för sig separerade från varandra. Uppskattad kostnad och total restid skrivs även ut.

För att göra ruttförslagen mer överblickbara finns knappar för att visa varje rutt för sig samt visa rutter markerade som varningar. Det är möjligt att med knapparna

”Plot previous route” och ”Plot next route” stega sig igenom varje rutt för sig, vilket medför att enstaka rutter enkelt kan kontrolleras. Vill en enstaka utvald rutt visas kan knappen ”Show” användas för att enbart visa den rutten på kartan.

Ingen omladdning av webbsidan sker när användaren interagerar med den vilket

KAPITEL 4. SYSTEMARKITEKTUR

gör exempelvis byte av rutt för visualiering responsivt.

4.2.2 Bakomliggande struktur

Start

Vänta på indata

Adresser till koordinater Om beräkna

Uppdatera karta Om visa existerande rutt

Skicka förfrågan till server

Vänta på svar

Visa resultat och uppdatera karta

Figur 4.4: Översikt för klientarkitekturen.

För att HTML-kontrollerna ska få en funktion krävs en bakomliggande struktur.

AngularJS har hand om HTML-kontrollernas funktion och styr allt dynamiskt som exempelvis uppdatering av kartan. Rent praktiskt har en AngularJS-kontroller ska- pats som innehåller funktioner vilka exekveras när något händer, exempelvis tryck på en knapp eller svar på en förfrågan. Figur 4.4 visar en översikt för flödet, där

”Vänta på svar” utförs asynkront och klienten blockeras inte under ”Vänta på svar”.

När en användare i det grafiska gränssnittet använder knappen ”Calculate” och vill beräkna ruttförslag anropas en funktion i AngularJS-kontrollern som tar fram koordinaterna för adresserna, denna geocoding sker genom att Mapboxs REST-API förfrågas en gång för varje adress asynkront.

Varje gång Mapboxs REST-API returnerar ett svar sker det genom att en callback-funktion i AngularJS-kontrollern anropas, där callback-funktionen sparar det returnerade koordinatparet tillsammans med adressen och ett unikt ökande id-

18

4.3. SERVERARKITEKTUR

nummer som startar på 1. Eftersom asynkrona anrop används till Mapboxs REST- API är det inte förutbestämt i vilken ordning svar ges. För att ordning inte ska påverka används en klassisk barriär för synkronisering, där callback-funktionen i sitt sista anrop även anropar serverdelen i systemarkitekturen asynkront.

När serverarkitekturen är färdig med sin beräkning och klientarkitekturen mot- tager svaret i en callback-funktion uppdateras kartan och listan med rutter. Funk- tioner finns implementerade för att visa enstaka rutter och visa alla rutter flaggade med en varning.

4.3 Serverarkitektur

När serverdelen av systemarkitekturen mottager en förfrågan att lösa en instans av samåkningsproblemet sker olika steg efter varandra, där stegen illustreras i figur 4.5.

En kantmatris beräknas med OSRM, optimala rutter approximeras med Optaplan- ner, ruttförslagen verifieras och returneras till sist. Spring-ramverket används för att sammankoppla alla delar med hjälp av dess inbyggda funktioner för exempelvis serialisering.

Start

Vänta på förfrågan

Beräkna kantmatris med OSRM

Optimera med Optaplanner

Verifiera ruttförslag

Returnera ruttförslag

Figur 4.5: Översikt för serverarkitekturen.

KAPITEL 4. SYSTEMARKITEKTUR

4.3.1 Övergripande struktur

En klass i Java har skapats som huvudklass för serverstrukturen, som har som upp- gift att göra om indata från ett Javaobjekt till en lösning lagrad i ett Javaobjekt färdigt för serialisering. En REST-kontroller har registrerats i Spring för applikatio- nen, där applikationen avserialiserar indata i JSON-form (figur 4.2) till Javaobjekt, för att därefter skapa en ny instans av huvudklassen vid varje förfrågan.

Applikationen har organiserats genom att ha skilda paket för beräkning av kant- matris, optimering och verifikation. I ordning skapar huvudklassen nya instanser av objekt från respektive paket och använder dem. När ett lösningsförslag har generats och verifierats uppdateras variabler innehållandes den data som klientdelen kräver, denna data serialiseras sedan automatiskt när kontrollern returnerar ett svar till en förfrågan.

4.3.2 Beräkning av kantvikter

Under optimeringsfasen (sektion 4.3.3) frågar Optaplanner efter avstånd mellan punkter med väldigt hög frekvens, vilket innebär att avstånd mellan punkter måste vara beräknade i förväg för att undvika en stor prestandaförlust. Avstånden mås- te även kunna nås snabbt i konstant tid vilket gör att en matris med kantvikter lämpligen lagras i en klassisk array i Java, där varje adressobjekts siffer-id (”id” i figur 4.2) kan användas som index.

Avstånd som är korta fågelvägen kan vara väldigt långa i reell restid, detta ef- tersom Stockholm har gott om vattendrag med enstaka broar. Att använda avstånd via fågelvägen som kantvikter förutsätts därför vara ineffektivt. För att beräkna avstånd mellan geografiska punkter krävs körsträcka eller körtid. Körtid förutsätts vara ett bättre mått än körsträcka, eftersom taxipassagerare och taxichaufförer tro- ligtvis prioriterar kort restid framför kort körsträcka.

För att beräkna kantvikter används OSRMs REST-API, där en förfrågan till en lokal OSRM-server sker från Spring-applikationen synkront via HTTP. OSRM returnerar en matris bestående av körtider mellan alla punkter som vid mottagande lagras i en vanlig Java-array.

4.3.3 Optimering: framtagning av lösning

I denna del används Optaplanner för att ta fram en lösning, dvs. möjliga rutter för samåkning eller en approximation av den optimala COVRP-lösningen.

Modellering i Optaplanner

COVRP är modellerat i Optaplanner med anpassning till samåkningsproblemet med taxi. För COVRP specifikt till samåkingsproblemet med taxi i Optaplanner görs följande:

1. Den gemensamma platsen för samåkning läggs till (”Depå” i klassiska VRP) med sin koordinat.

20

4.4. OPTIMERING AV TID FÖR BERÄKNING

2. Varje passagerare läggs till med sin egna koordinat.

3. Antalet tillgängliga taxibilar sätts till antalet passagerare för att simulera en obegränsad tillgång. Varje taxi behöver även en ”Depå” att utgå ifrån vilken blir den gemensamma platsen.

Regler för poäng

Eftersom Optaplanner måste kunna jämföra möjliga lösningar mot varandra krävs möjlighet att ge olika generade lösningar poäng. Möjlig poäng delas in i två typer, hårda villkor och mjuka villkor. Hårda villkor får inte brytas medan mjuka villkor fungerar som poängen för en lösning. Denna applikation använder två villkor:

• Hårt villkor: Antalet passagerare i ett fordon får inte överstiga kapaciteten.

• Mjukt villkor: Körtiden för fordon agerar poäng.

Resultatet av reglerna blir att summan av all restid optimeras ^P

t

, där n är antalet rutter och t

tiden för en rutt. Eftersom poäng behöver beräknas för varje möjligt lösningsförslag som testas används inkrementell beräkning av poängen för bättre prestanda.

Bearbetning av lösning

När Optaplanner är klar hämtas det relevanta för lösningen och sparas i objekt, där exempel på icke-relevant data är oanvända taxibilar. En del data förbereds även för klientdelen, exempelvis slumpmässiga färger för varje rutt.

4.3.4 Verifiering

Denna del har två uppgifter: kontrollera att ingen rutt tar för lång tid och gene- rera mer data till klientdelen. Den data som genereras till klientdelen är linjer för ruttvisualisering, uppskattad kostnad och restid.

Detta sker genom att OSRMs API först frågas en gång i taget för varje av Optaplanner genererad rutt synkront, därefter används den returnerade datan från OSRM för att ta reda på data för ruttvisualisering (bearbetas mer i klientdelen), ackumulerad restid, ackumulerad körsträcka och om rutten tar för lång tid. En rutt anses ta för lång tid om något av följande två villkor uppfylls:

• Restiden för den sista destinationen i en rutt mer än fördubblas.

• Restiden för den sista destinationen i en rutt ökar med mer än 30 minuter.

4.4 Optimering av tid för beräkning

Identifikation av tidskrävande moment och optimering av beräkningstiden för Op-

taplanner presenteras här.

KAPITEL 4. SYSTEMARKITEKTUR

4.4.1 Identifikation av tidskrävande moment Tidskrävande moment delas in i fyra delar:

• geocoding

• beräkning av kantvikter med OSRM

• optimering med Optaplanner

• verifiering.

Eftersom gratistjänsten Mapbox är implementerad för geocoding och är tänkt att ersättas vid driftsättning ignoreras geocoding-momentet i identifikationen och optimeringen. För testfallen med byggnadsminnen och kyrkliga kulturminnen har delen beräkning av kantvikter visat sig kräva mindre än en sekund för båda testfallen och verifieringsdelen strax över en sekund.

För delen optimering med Optaplanner kan Optaplanners tidtagning mätas in i två delar, konstruktionsheuristik och lokalsökning (eller metaheuristik). Konstruk- tionsheuristik har visat sig kräva tider i storleksordningen 10ms för nämnda testfall medan lokalsökning har fått termineras manuellt efter flera minuters körtid. Detta innebär att lokalsökning med Optaplanner har optimerats för att snabbare hitta möjliga lösningar och själv avgöra när lokalsökning är färdig.

4.4.2 Lokalsökning krävs

I figur 4.6 visas ett exempel med testdatan alla byggnadsminnen i Stockholms län, där lokalsökning först inte körs (fig. 4.6a) och sedan där den körs (fig. 4.6b). Notera hur lokalsökning ersätter tre taxibilar i ett mindre område med en taxibil. Utan lokalsökning i figur 4.6a blev ackumulerad kostnad för samåkning ca 51000kr och med lokalsökning i figur 4.6b ca 67000kr.

Används endast en snabb konstruktionsheuristik utan mer tidskrävande lokal- sökning fås en lösning som vid en första anblick kan ses ut att fungera, men om lokalsökning får köras förbättras resultatet avsevärt. Kontentan är att enbart kon- struktionsheuristik tar fram ett lösningsförslag som enbart uppfyller grundläggande villkor för COVRP, lokalsökning eller metaheuristik kan sedan använda detta lös- ningsförslag för att söka efter mer optimala lösningar.

4.4.3 Konfiguration av Optaplanner Konstruktionsheuristik för initialisering

Vid testning av olika enskilda konstruktionsheuristiker uppmättes ingen större skill- nad i tid. First Fit Decreasing spenderade inte längre tid än andra heuristiker och valdes eftersom den i teorin ska vara effektiv när modellen i Optaplanner har stöd för att uppskatta svårighet för förändringar av passagerare under lösningen [31].

22

4.4. OPTIMERING AV TID FÖR BERÄKNING

(a) Utan lokalsökning. (b) Med lokalsökning.

Figur 4.6: Resultat av lokalsökning

Automatisk terminering av lokalsökning

Eftersom lokalsökning i Optaplanner inte själv slutförs inom tillräckligt kort tid behöver termineringsvillkor formuleras. Då målet med systemarkitekturen är att snabbt hitta en fungerande lösning för samåkningsproblemet med taxi är tanken att låta lokalsökningen avbrytas när den bästa poängen för genererade lösningar konvergerar, målsättningen är att om lokalsökning får fortgå efter att poängen har konvergerat ska inte det slutgiltiga lösningsförslaget bli mer än några procent bättre.

Vid testning har det visat sig att vänta för kort tid på att lösningen ska konver- gera (100ms) har avbrutit lokalsökningen för tidigt, vilket resulterat i att lösnings- förslaget ser ut som om lokalsökning försummats som i figur 4.6a. 500ms har för samtliga testfall visat sig vara en tillräckligt lång väntetid för att hitta acceptabla lösningar och inte avbryta lokalsökningen för tidigt.

Konfiguration av lokalsökning

Tabusökning i kombination med late acceptance valdes som metaheuristik eftersom

den i tester hade bra prestanda och returnerade en av de lägsta ackumulerade res-

tiderna. ”Hill climbing” är ett alternativ till tabusökning men varianten har för lätt

att fastna i lokala optimum [31], vilket inte passar bra ihop med att lokalsöknings-

KAPITEL 4. SYSTEMARKITEKTUR

fasen är inställd att avbryta när poängen konvergerar.

4.5 Slutgiltig tid för skapande av lösningsförslag

För samtliga testfall skapas lösningsförslag inom några sekunder på testsystemet.

För testfallen med byggnadsminnen och kyrkliga kulturminnen i Stockholms län varierar typisk uppmätt tid mellan 2,5-4s på testsystemet, varar Optaplanner an- vänder ungefär 2-3s samt beräkning av kantvikter med OSRM och verifiering ca 500ms vardera. I tabell 4.1 visas dessa tider.

Tabell 4.1: Ungefärliga tider för skapande av lösningsförslag OSRM Optaplanner Verifiering

ca 0,5s ca 2-3s ca 0,5s

För att testa skillnaden i hur beräkningstid påverkar ackumulerad restid, kon- figurerades Optaplanner i ett test att hitta lösningar under fem minuter istället för att avbryta vid konvergering. Detta resulterade för testfallet med byggnadsminnen i en besparing på mindre än 1% för den ackumulerade restiden.

4.6 Kostnad för drift

För att driva den utvecklade tjänsten tillkommer en kostnad för drift. Det finns två identifierade kostnadsområden, kostnad för serverdrift och kostnad för geocoding. I sektion 4.6.1 jämförs några tjänster för geocoding och en prisbild tas fram samt i sektion 4.6.2 tas en prisbild för serverdrift fram. Totalt blir en uppskattad kostnad 109 USD per månad exklusive eventuella skatter, varav 99 USD för geocoding och 10 USD för serverdrift.

4.6.1 Geocoding

Att fritt använda geocoding (översättning från gatuadresser till koordinater) som fungerar tillräckligt bra utan begränsningar för denna systemarkitektur i Stock- holmsområdet har inte visat sig möjligt. Detta eftersom OSM har visat sig sakna gatunummer för många testade adresser och företag som erbjuder tjänster för geoco- ding har begränsningar för användningen. För att möjliggöra framtagandet av en ungefärlig prisbild för drift har krav för geocoding och en jämförelse mellan tjänster gjorts. Syftet är därför inte att undersöka olika API-tjänster på djupet.

Krav

De krav och utvärderingskriterier som identifierats för en geocoding-tjänst är:

• Geocoding ska fungera i Uppland. Resultatet behöver inte vara exakt rätt byggnad men korrekt gata krävs och ett felaktigt resultat får inte vara för

24

4.6. KOSTNAD FÖR DRIFT

långt bort från den korrekta koordinaten. Om felaktiga koordinater ges för längre gator som exempelvis Sveavägen i Stockholm, finns risken att dåliga rutter genereras då restid till andra koordinater påverkas. Ges fel gator som är nära fågelvägen riskerar även resultatet att påverkas om exempelvis ett vattendrag går emellan felaktiga koordinater och korrekta. Kartdatan ska även vara uppdaterad, annars finns risken att nya adresser inte finns med.

• Väntetiden får vara max några sekunder, detta då denna väntetid direkt på- verkar väntetiden för användaren. För att detta ska vara möjligt kan stöd för batch-förfrågningar krävas (flera koordinater i en fråga), detta för att undvika att antalet förfrågningar är lika med antalet adresser.

• Ett API som kan användas med antingen Spring eller Javascript, det måste vara möjligt att implementera använding av APIet. Förslagvis följer APIet REST-principen och använder sig av HTTP för plattformsoberoende.

• Pris, om möjligt.

Jämförelse

De tjänster som har identifierats för geocoding där Sverige är sökbart är Map- box [11], Google Maps API [13], Bing Geocode Dataflow API [10] och Here REST API [28]. Tjänster där nybyggda vägar saknades som exempelvis Norra Länken ex- kluderades direkt som möjliga kandidater. Två exempel på karttjänster där nya vägar inte fanns med vid skrivande stund var ViaMichelin och Yandex.

I tabell 4.2 på sida 26 ses en mindre jämförelse mellan de fyra tjänsterna. Överlag har Mapbox en bra prismodell för denna systemarkitektur men har en otillräcklig träffsäkerhet i mer glesbefolkade områden.

Google Maps API ger ett resultat som får anses vara tillräckligt bra för sys- temarkitekturen, problemet kan vara en hög driftskostnad. För tillgång till batch- förfrågningar eller en högre ”rate-limit” i server-APIet med max 50 förfrågningar istället för 10 varje sekund krävs en ”Premium-plan”.

Klient-APIet erbjuder inte stöd för batchförfrågningar och dess ”rate-limit” vi- sade sig vid testning utföra geocoding inom några sekunder för de första 10-20 adresserna, därefter begränsades frekvensen till mindre än en beräkning per se- kund vilket är för långsamt. Google Maps API för klient-sidan är mer riktat till fler enstaka förfrågningar och inte riktat till enstaka tillfällen med ett större antal förfrågningar.

Kontakt har etablerats med Googles säljavdelning för prisuppgift för geocoding för denna systemarkitektur men ingen prisuppgift kunde ges, eftersom priset beror på många faktorer såsom hur kommersiellt syftet är. Risk är en hög driftskostnad eftersom fördelar såsom tillgång till en servicetekniker ingår, vilket inte krävs för att driva denna systemarkitektur i en mindre skala.

Bing Geocode Dataflow API skulle kunna fungera också men ställer större krav

på att slutanvändaren kontrollerar att adresser på landsbygden är korrekta. Bäst

KAPITEL 4. SYSTEMARKITEKTUR

Tabell 4.2: Jämförelse mellan fyra tjänster för geocoding.

Träffsäkerhet Begränsningar & pris Mapbox Stockholm med förorter funge-

rar vid stickprov. Orter och adresser på landsbygden i Upp- land fungerar inte.

I gratisversionen 50000 kartvisningar per månad och 600 förfrågningar per minut. För API med stöd för batch-förfrågningar krävs en

”enterprise-plan” där inget explicit pris finns.

Google Maps API

Överlag bra. Missar enstaka adresser på landsbygden men returnerar ibland orten istället vilket borde räcka för ändamå- let.

Finns API för klient- och ser- versidan. Server-API begränsat till 2500 förfrågningar per dag och 10 per sekund. Premium- plan utan explicit pris krävs för batch-förfrågningar. Klient-API har ingen explicit gräns.

Bing Geocode Dataflow API

Liknar Google Maps med vilka adresser som klaras av. Ett pro- blem är dock att fall där Google Maps returnerar inget svar eller korrekt ort, returnerar Bing helt fel platser.

Oklar prisbild och oklara be- gränsningar. Någon form av kontakt behöver troligtvis eta- bleras för pris.

Here REST API

Bra. Några enstaka adresser på landsbygden som Google och Bing har svårigheter för klaras här av.

Finns en ”Starter plan” för 99 USD per månad med stöd för batch-geocoding.

för driftssättning kan Here REST API vara eftersom de har en bra träffsäkerhet och en tydlig prisbild där inga avtal behöver förhandlas.

Gemensamt med dessa tjänster är att krav vanligtvis är att slutanvändaren ska se resultatet på en karta från dem själva. Tack vare användningen av Leaflet är det enkelt att byta karttjänst, exempelvis rutter som visas på kartan renderas som en polylinje och kräver inget stöd hos karttjänsten. Gemensamt är även att resultat från geocoding normalt sett inte får sparas i en databas utan endast får cachas kortare tider.

4.6.2 Serverdrift

Krav för en server är möjlighet att köra OSRM och en Tomcat-server för Spring.

Tillräcklig prestanda krävs även och priset för drift är kopplat till den prestan- da som krävs, högre prestanda innebär snabbare beräkningar. För stabilitet, enkel skalbarhet och kontroll är en virtuell server lämplig.

26

4.6. KOSTNAD FÖR DRIFT

Ett företag som erbjuder virtuella servrar och gör det möjligt att enkelt byta till

en med mer prestanda är Digital Ocean [29] . En virtuell server med en enkärning

processor och 1GB RAM kostar 10 USD per månad. Önskas bättre prestanda kan

servern uppgraderas till exempelvis två kärnor och 2GB RAM för 20 USD per

månad. Fördelen med dessa virtuella servrar är att full kontroll ges till en virtuell

maskin, vilket gör det möjligt att köra exempelvis OSRM utan begränsningar i

operativsystemet.

Kapitel 5

Diskussion och slutsatser

I denna sektion diskuteras några specifika ämnen, i sektion 5.1 diskuteras återkopp- ling till syftet och tider för lösningsförslag, i sektion 5.2 och 5.3 diskuteras två ämnen med förslag på lösningar, i sektion 5.4 diskuteras några specifika möjliga framtida arbeten, i sektion 5.5 diskuteras kort alternativa lösningar och detta ar- betes bidrag till forskning samt i sektion 5.6 reflekteras det kring val av metod och verktyg.

5.1 Återkoppling till syfte

Systemarkitekturen klarar av att för testfall ta fram lösningsförslag som vid kontroll rutt för rutt på en karta ser ut att vara rimliga inom rimlig tid. Resultatet får därför anses lyckat och målen uppfyllda, med undantag för delen med geocoding som visade sig vara komplicerad eftersom öppna data inte kunde användas.

För att minska beräkningstider kan ytterligare optimering av systemarkitektu- ren ske i verifieringssteget, istället för att synkront skicka en fråga i taget till OSRM kan flera frågor skickas parallellt, mycket tid förloras troligtvis i overhead eftersom en server behöver anropas med HTTP vid varje anrop. Beräkning av kantmatris med OSRM får anses ske väldigt snabbt, ca 500ms för ca 200 koordinatpar får an- ses vara över förväntan. Optaplanner kan vara möjligt att optimera ännu mer, men tider i lägre storleksordningar är troligtvis svårt att erhålla.

5.2 Acceptabel förlängning i restid

Vad som är en acceptabel skillnad i restid skulle behöva utforskas mer. Att varna vid en förlängning på mer än 30 minuter borde ersättas med en funktion där accepterad restid ändras efter hur lång den ordinarie restiden tar. 30 minuter kan sägas fungera någorlunda för ändamålet samåkning i Stockholm.

Om acceptabel förlängning i restid utforskades skulle en begränsning för max-

imal restid kunna implementeras. Detta kan ske genom att ett hårt villkor läggs

till för maximal restid. Detta skulle kunna resultera i bättre lösningsförslag, om en

KAPITEL 5. DISKUSSION OCH SLUTSATSER

användare löser en varning genom att manuellt placera en passagerare i en egen taxi skulle kanske den taxibilen kunna avlasta en annan taxi.

5.3 Begränsningar med geocoding

Eftersom OSM inte innehåller gatunummer för många vägar betyder det att fritt kunna använda geocoding med hög precision utan begränsningar inte visat sig möj- ligt. Det har även visat sig att undersökta proprietära APIer för geocoding har begränsningar i frekvensen för maximala antalet förfrågningar, vilket påverkar ti- den från inmatning av data till lösningsförslag för mycket sett till tiden det tar för de andra delarna i systemarkitekturen.

En lösning till detta skulle kunna vara att acceptera en något lägre precision och ignorera gatunummer, vilket innebär att OSM blir möjligt att använda. Om det är möjligt att via OSM hämta en gatas längd skulle kortare gator kunna använda geocoding visa OSM och längre gator där resultatet riskerar påverkas negativt kunna använda ett proprietärt API.

Geocoding är viktigt och om ett API returnerar felaktiga koordinater finns risken att felet upptäcks först vid samåkning vilket kan leda till förseningar. Om använda- ren av systemet själv kunde kontrollera resultatet för geocoding skulle denna risk minskas.

5.4 Möjliga framtida arbeten

5.4.1 Alternativ systemarkitektur

Ett förslag till en förändring i systemarkitekturen för att kringå begränsningar kring geocoding illustreras i figur 5.1. En ansvarig matar in en lista med epostadresser och systemarkitekturen skickar epost till varje adress. I varje epostmeddelande finns en länk där varje passagerare själv matar in sin adress och ser hittade koordina- ter på en karta, där användaren själv ansvarar för att de av geocoding returnera- de koordinaterna är korrekta. När alla passagerare har matat in sina adresser är geocoding-steget klart och ett lösningsförslag kan hittas som sedan presenteras för den ansvarige.

På detta sätt kan risken för felaktiga koordinater elimineras då varje passagera- re verifierar sin egen adress. Begränsningar kring maximal frekvens för geocoding- förfrågningar kringgås även. En skillnad med denna systemarkitektur är dock att resultat inte kan erhållas direkt, utan alla passagerare måste skriva in sin adress vilket kan ta tid. Problem riskerar att uppstå i den processen och ett enklare admi- nistrationsgränssnitt skulle behövas för en ansvarig, där exempelvis status för vilka passagerare som inte skrivit in sina adresser syns.

30

5.4. MÖJLIGA FRAMTIDA ARBETEN

AngularJS Synligt för

ansvarig

Synligt för enskilda användare Spring

Indata med epostadresser Skicka epost till

varje epostadress

Visa alla rutter med Leaflet

Användare skriver in

sin egna adress Geocoding Spara temporärt

i databas Om alla skrivit in sin adress OSRM Optaplanner

Figur 5.1: Förslag på en annorlunda systemarkitektur.

5.4.2 Taxibokning via API

För att förenkla för användaren skulle korrekta prisuppgifter tas fram och taxi- bokning kunna ske. För att undersöka denna möjlighet har tre större taxibolag i Stockholm kontaktats angående denna möjlighet. Frågan var om de erbjuder ett API och följande tre olika svar gavs:

• Plan för framtagning av API finns men ingen tidsplan kunde ges.

• Modernisering av API sker i dagsläget och intresse för samarbete finns.

• Ett API finns som följer en standard kallat SUTI med möjlighet att fråga om pris och göra bokningar.

SUTI undersöktes kort och en kortare förklaring hittades med dokumentation [32].

Hur mycket insats som krävs för implementation och om det är möjligt att im-

plementera är oklart. Ett API kräver även stöd för multipla via-destinationer för

KAPITEL 5. DISKUSSION OCH SLUTSATSER

korrekt prisuppgift, något som kanske inte är möjligt med existerande APIer såsom SUTI.

5.4.3 Bättre användarupplevelse

Fokus med denna rapport har inte varit på användarupplevelsen utan att ta fram bakomliggande arkitektur. Förutom en bättre design skulle funktioner för att ex- empelvis i användargränssnittet kunna dela upp dåliga rutter i flera för att sedan exportera allt skapas.

Det kan vara svårt att garantera att ett lösningsförslag enbart innehåller bra rutter, därför är det viktigt att en slutanvändare på ett enkelt sätt kan kontrollera varje rutt enskilt. Det är möjligt nu men skulle kunna göras bättre, exempelvis genom att visa adresser på kartan vid varje markör.

5.5 Alternativa lösningar & arbetets bidrag till forskning

Ses samåkningsproblemet fortfarande som en instans av VRP finns det många ap- proximationsmetoder att använda för att hitta lösningar, ett exempel är att se VRP som en trädstruktur där heuristik sedan används för att hitta lösningar [24]. An- nan avancerad heuristik kan även utforskas mer för att hitta bättre och snabbare lösningar till samåkningproblemet, exempelvis genetiska algoritmer [3].

Detta arbete bidrar till forskning genom att visa att samåkning med taxi från en plats till flera eller från flera platser till en kan ses som en instans av COVRP.

Arbetet visar även att det med hjälp av öppna data och öppna ramverk är möjligt att hitta ruttförslag inom kort tid i Stockholmsområdet med koordinater som indata.

5.6 Metoder och val av verktyg

Metoden att först definiera och identifiera problemet, för att sedan utveckla i olika faser visade sig fungera bra under examensarbetets gång. En viktig del som missades tidigt i arbetet var dock att OSM inte är möjligt att använda för exakt geocoding, hade detta insetts tidigare kanske systemarkitekturen hade designats annorlunda.

Val av verktyg får anses lyckade eftersom systemarkitekturen klarar av att snabbt ta fram lösningsförslag. OSRM hade bättre prestanda än förväntat och Op- taplanner var tack vare sin stora komplexitet möjligt att konfigurera för prestanda, något som kanske inte hade varit möjligt med liknande alternativ eller om egna algoritmer för exempelvis lokalsökning hade skrivits. AngularJS fungerade även om de flesta Javascript-ramverk med största sannolikhet hade fungerat minst lika bra.

32

Litteratur

[1] Vladimir Agafonkin. Leaflet — an open-source JavaScript library for inte- ractive maps. 2015. url: http://leafletjs.com/ (hämtad 2016-05-08).

[2] AngularJS: Miscellaneous: FAQ. 2016. url: https://docs.angularjs.org/

misc/faq (hämtad 2016-05-08).

[3] Barrie M. Baker och M. A. Ayechew. “A genetic algorithm for the vehicle rou- ting problem”. I: Computers & Operations Research 30.5 (april 2003), s. 787–

800. issn: 0305-0548. doi: 10.1016/S0305- 0548(02)00051- 5. url: http:

/ / www . sciencedirect . com / science / article / pii / S0305054802000515 (hämtad 2016-06-12).

[4] Bandwagon. Bandwagon. url: http://www.bandwagon.io/ (hämtad 2016-04-28).

[5] Chris Bell. Batch geocoding. url: https://www.doogal.co.uk/batchgeocoding.

php (hämtad 2016-05-30).

[6] Olli Bräysy och Michel Gendreau. “Vehicle Routing Problem with Time Win- dows, Part I: Route Construction and Local Search Algorithms”. I: Transpor- tation Science 39.1 (2005), s. 104–118. issn: 0041-1655. url: http://www.

jstor.org/stable/25769233 (hämtad 2016-04-29).

[7] G. B. Dantzig och J. H. Ramser. “The Truck Dispatching Problem”. I: Ma- nagement Science 6.1 (1959), s. 80–91. issn: 0025-1909. url: http://www.

jstor.org/stable/2627477 (hämtad 2016-05-23).

[8] Dr. M. Elkstein. Learn REST: A Tutorial. url: http://rest.elkstein.org/

(hämtad 2016-05-22).

[9] Roy T. Fielding och Richard N. Taylor. “Principled Design of the Modern Web Architecture”. I: Proceedings of the 22Nd International Conference on Software Engineering. ICSE ’00. New York, NY, USA: ACM, 2000, s. 407–

416. isbn: 978-1-58113-206-9. doi: 10 . 1145 / 337180 . 337228. url: http : //doi.acm.org/10.1145/337180.337228 (hämtad 2016-05-22).

[10] Geocode Dataflow API. Microsoft. url: https://msdn.microsoft.com/en- us/library/ff701733.aspx (hämtad 2016-05-23).

[11] Geocoding. Mapbox. url: https://www.mapbox.com/geocoding/ (hämtad

2016-05-23).

LITTERATUR

[12] Fred Glover och Kenneth Sörensen. “Metaheuristics”. I: Scholarpedia 10.4 (2015), s. 6532. issn: 1941-6016. doi: 10.4249/scholarpedia.6532. url:

http://www.scholarpedia.org/article/Metaheuristics (hämtad 2016-06-12).

[13] Google Maps APIs. Google Developers. url: https://developers.google.

com/maps/ (hämtad 2016-05-23).

[14] Irina Gribkovskaia och Gilbert Laporte. “One-to-Many-to-One Single Ve- hicle Pickup and Delivery Problems”. I: The Vehicle Routing Problem: La- test Advances and New Challenges. Utg. av Bruce Golden, S. Raghavan och Edward Wasil. Operations Research/Computer Science Interfaces 43. DOI:

10.1007/978-0-387-77778-8_16. Springer US, 2008, s. 359–377. isbn: 978-0- 387-77777-1. url: http://link.springer.com/chapter/10.1007/978-0- 387-77778-8_16 (hämtad 2016-04-22).

[15] Anne Håkansson. “Portal of Research Methods and Methodologies for Rese- arch Projects and Degree Projects”. I: The 2013 World Congress in Compu- ter Science, Computer Engineering, and Applied Computing WORLDCOMP 2013; Las Vegas, Nevada, USA, 22-25 July. CSREA Press U.S.A, 2013, s. 67–

73. url: http://kth.diva-portal.org/smash/record.jsf?pid=diva2%

3A677684&dswid=-8985 (hämtad 2016-04-06).

[16] Jeff Atwood. Understanding Model-View-Controller. 2016. url: https : / / blog.codinghorror.com/understanding-model-view-controller/ (häm- tad 2016-05-23).

[17] Rod Johnson m. fl. Spring Framework Reference Documentation. 2015. url:

http : / / docs . spring . io / spring / docs / current / spring - framework - reference/htmlsingle/ (hämtad 2016-05-22).

[18] Jon Kleinberg och Éva Tardos. Algorithm Design. Pearson New International Edition. Pearson, 2014. isbn: 1-292-02394-5.

[19] J. K. Lenstra och A. H. G. Rinnooy Kan. “Complexity of vehicle routing and scheduling problems”. I: Networks 11.2 (1 juni 1981), s. 221–227. issn: 1097- 0037. doi: 10.1002/net.3230110211. url: http://onlinelibrary.wiley.

com/doi/10.1002/net.3230110211/abstract (hämtad 2016-04-29).

[20] Lista över byggnadsminnen i Stockholms län. I: Wikipedia. Page Version ID:

34130502. 19 april 2016. url: https://sv.wikipedia.org/w/index.php?

title = Lista _ %C3 % B6ver _ byggnadsminnen _ i _ Stockholms _ l % C3 % A4n &

oldid=34130502 (hämtad 2016-05-26).

[21] Lista över kyrkliga kulturminnen i Stockholms län. I: Wikipedia. Page Version ID: 30990250. 12 nov. 2015. url: https://sv.wikipedia.org/w/index.

php?title=Lista_%C3%B6ver_kyrkliga_kulturminnen_i_Stockholms_l%

C3%A4n&oldid=30990250 (hämtad 2016-05-26).

34