Kandidatarbete
Digital visualisering av skallgångskedjor
- Google Maps som spårningsverktyg
Författare: Carl Einarsson, Joel Carlsson Handledare: Daniel Toll
Sammanfattning
Varje år försvinner tusentals personer. År 2017 anmäldes 7100 personer som försvunna i Sverige. De allra flesta återfinns inom sex månader, men i genomsnitt 30 personer återfinns aldrig. Svensk polis deltar i sökningar efter minst 300 personer varje år. Polisen samarbetar i sina sökinsatser med försvarsmakten och andra organisationer som Missing People. Missing People som har över 60 000 personer anmälda som volontära sökare, hjälper till genom, bland annat, anordna skallgångskedjor.
I detta examensarbete, undersöks verktyg och tekniker som skulle kunna komma till användning vid sökinsatser. Examensarbetet undersöker verktyg som finns tillgängliga i Google Maps API för att se hur det går att visualisera
1hur ett område är sökt och hur länge sedan det genomsöktes. Tre visualiseringstekniker från Google Maps API implementeras och testas för ändamålet. Teknikerna är Heatmaps, Polygons och Circles. Varje teknik implementeras och testas mot ett antal identifierade krav i en iteration.
Kraven är framtagna genom att analysera frågeställningen mot de relaterade arbeten, webbplatser och artiklar som detta examensarbete byggt sin bakgrund på.
Slutsatsen visar att Heatmaps från Google Maps API inte fyller den önskade funktionen. Om heatmaps ska användas kan ett annat kartverktyg än google maps behöva användas eftersom Google Maps Heatmaps-verktyg inte går att ställa så att de passar kraven som satts upp. Polygons misslyckas på ett av testerna, vilket kan gå att lösa med en algoritm för att förstora polygonen.
Circles fungerar efter kraven och kan användas på önskvärt vis. Det krävs
dock mer forskning för att vidareutveckla hur verktyget hade kunnat
användas i ett skarpt läge.
Nyckelord: Visualiseringstekniker, Google Maps API, Heatmaps, Polygons,
Circles, Missing People, GPS, Koordinater, Javascript
Förord
Vi vill tacka vår handledare Daniel Toll för stort engagemang och flera
givande handledningstillfällen, samt de studenter som har opponerat på detta
examensarbete.
Innehåll
Sammanfattning 2
1 Introduktion 8
1.1 Bakgrund 9
1.1.1 Att genomsöka ett område 10
1.1.2 Synhållsradie 10
1.1.3 Visualiseringstekniker för GPS-data 11 1.1.4 Platsinformation & Värmekartor (Heatmaps) 13
1.1.5 Polygoner i Google Maps API 14
1.1.6 Polygons 15
1.1.7 Heatmaps 16
1.1.8 Circles 17
1.2 Relaterade arbeten 18
1.2.1 Utveckling av Location-Based Services för webbläsare 18 1.2.2 Analys av rörelsemönster för försvunna personer 18
1.2.3 Färgläggning av besökta platser 19
1.3 Problemställning 20
1.4 Motivation 20
1.5 Mål 21
1.6 Avgränsningar 22
1.7 Målgrupp 23
1.8 Disposition 24
2 Metod 25
2.1 Krav 26
2.1.1 Tekniska krav 27
2.1.2 Användbarhetskrav 27
2.2 Artefakten 27
2.3 Visuell design 28
2.4 Automatiska enhetstester 28
2.5 Validering 28
2.6 Tillförlitlighet och validitet 29
2.7 Etiska överväganden 29
3 Implementation 30
3.1 Samla koordinater 30
3.2 Datalagring 31
3.3 Åtkomst och lagring av API-nyckel 32
3.4 Kartfunktionalitet 32
3.5 Färgläggning 33
3.6 Iterationer 34
3.6.1 Iteration 1, Heatmaps 34
3.6.1.1 Vikter 34
3.6.1.2 Skapa Heatmap-lager 36
3.6.1.3 Konvertera koordinater 37
3.6.2 Iteration 2, Polygons 38
3.6.2.1 Gruppera koordinater 38
3.6.2.1.1 Tid 38
3.6.2.1.2 Avstånd 38
3.6.2.2 Form 40
3.6.2.3 Färgläggning 41
3.6.3 Iteration 3, Circles 42
3.6.3.1 Gruppera koordinater 42
3.6.3.2 Färgläggning 43
3.6.3.3 Skapa cirklar 43
4 Utvärdering 45
4.1 Enhetstester 45
4.2 Iteration 1, Heatmaps 46
4.3 Iteration 2, Polygons 50
4.4 Iteration 3, Circles 53
4.5 Summering av manuella tester 58
5 Diskussion 58
5.1 Iteration 1, Heatmaps 60
5.2 Iteration 2, Polygons 61
5.3 Iteration 3, Circles 63
6 Sammanfattning 64
6.1 Framtida arbete 66
6.1.1 Synhållsradien 66
6.1.3 Alternativ karttjänst 67
6.1.4 Undersöka Circles användning 68
6.1.5 Undersöka prestanda 68
Referenser 69
A Tester 75
Enhetstester 7
Manuella tester 79
B Testsviter 86
B.1 Heatmaps, Testsuite 1 86
B.2 Polygons, Testsuite 1 94
B.3 Circles, Testsuite 1 102
B.4 Enhetstester 110
C Metoder 116
1 Introduktion
Varje år försvinner tusentals personer [30]. År 2017 anmäldes 7100 personer som försvunna i Sverige. De allra flesta återfinns inom sex månader, men i genomsnitt 30 personer återfinns aldrig [30]. Svensk polis deltar i sökningar efter minst 300 personer varje år [29]. Polisen samarbetar i sina sökinsatser med försvarsmakten och andra organisationer som Missing People [3].
Missing People som har över 60 000 personer anmälda som volontära sökare, hjälper till genom, bland annat, anordna skallgångskedjor [3]. Missing People har bidragit till att personer återfunnits och har blivit en samhällsresurs att räkna med för sökoperationer[13].
I detta examensarbete, undersöks verktyg och tekniker som skulle kunna komma till användning vid sökinsatser. Examensarbetet kommer att utforska verktyg som finns tillgängliga i Google Maps API för att se hur det går att
2visualisera hur ett område är sökt och hur länge sedan det söktes.
Examensarbetet implementerar en digital miljö som använder koordinater som används i GPS:er och implementerar och testar olika visualiseringstekniker i miljön, för att försöka uppnå ett positivt svar på frågeställningen.
1.1 Bakgrund
Smarta mobiltelefoner är idag ofta utrustade med satellitnavigationssystem
[33]. Enheter med satellitnavigationsystemet GPS (Global Positioning
System) kan uppskatta enhetens geografiska position. Denna typen av teknik
kallas för LBS (Location Based Service) och öppnar för möjligheter att skapa
applikationer som hjälper användare att visualisera sin position och positionshistorik [2]. Nio av tio svenskar hade 2018 en smart mobiltelefon [32]. Organisationer likt Missing People som bedriver skallgångskedjor med volontära sökare [3] kan använda LBS-teknik när de i grupp arbetar för att täcka geografiska områden när de letar efter försvunna personer. LBS-teknik kan också användas för att skapa statistik över vilka platser som är besökta och genom att lagra positionshistorik, hjälpa till att avgöra hur väl ett område är genomsökt.
1.1.1 Att genomsöka ett område
Att ett område är “ genomsökt” menas i detta examensarbete att ett förutbestämt område har sökts igenom med sådan fullständighet att sökaren eller sökgruppen har varit på, eller haft sikt över all yta inom området och därför kan avgöra statusen för målets existens inom det förutbestämda området. Den yta som täcks utav sikten utifrån sökarens nuvarande position kommer i detta examensarbete att refereras till som “ synhållsradie” beskrivs nedan.
1.1.2 Synhållsradie
En person som söker efter ett objekt, kan genom synen uppskatta om objektet finns eller inte, över en yta som är större än den koordinat som personen befinner sig på. Denna yta kommer i detta examensarbete benämnas som
“ synhållsradien”. Synhållsradien kommer alltså att syfta till sträckan som den
sökande personen har möjlighet att se objektet från. Vad en människa ser från
dennes nuvarande position beror på många faktorer. Längden på människan,
stenar eller träd i omgivningen. Buskage eller gräs kan skymma ett objekt
beroende på längden och bredden av objektet. Hur detta examensarbete tar
hänsyn till terräng går att läsa om i avgränsningar ( Avsnitt 1.6). Huvudsyftet
med detta examensarbete kommer att vara att se om visualiseringen av ett område är möjlig och kommer därför att lägga huvudsaklig fokus på visualiseringen.
Det finns lösningar idag som hjälper användare att visualisera platser och områden, vilket presenteras i kommande stycken. Lösningarna som presenteras i kommande stycken inriktas inte direkt mot att kontrollera hur väl ett område är genomsökt när en eller flera personer letar efter ett objekt eller en person, för att säkerställa att ingen plats blir obesökt.
1.1.3 Visualiseringstekniker för GPS-data
Av de tekniker som finns idag för att visualisera GPS-data, finns det några tekniker som kommer spela roll i hur detta examensarbete kommer att formas. Dessa tekniker skiljer sig på olika sätt från vad detta examensarbete söker svar på. Examensarbetet kommer likväl använda inspiration från dessa arbeten.
Vid sökning på google med sökorden “visualizing historical gps data”
kommer flera exempel och idér på hur det går att visualisera positioner på en
karta. Ett exempel är DataV-projektet som förklaras i en artikel på
hackernoon [4]. DataV är en " Vector Field Generation Algoritm" som
simulerar blixt där ljusstyrkan är beroende av mängden objekt och tid från
och med nu. Ett annat exempel använder färger för att berätta hastigheten för
varje objekt. Exemplet där färger används för att beskriva hastigheten går att
se i Figur 1.1.
Figur 1.1: Visualisering av DataV-projektet [4], där en karta över ett område har färgade borstliknande linjer på sig. Dessa linjer visar hur enheter rör sig. Röd färg betyder låg hastighet. Blå betyder hög hastighet.
Att låta data försvinna långsamt från kartan genom att dämpa ljusstyrkan
kommer inte att användas i examensarbetet. Detta examensarbete kommer att
fokusera på att visa data och inte vad som händer när det försvinner. I
DataV-projektet håller inte punkterna som visar koordinater på kartan en
specifik storlek. Artikeln nämner inte skalning eller storlek. Detta arbete
kommer att behöva tänka på att markeringen för det genomsökta området ska
hålla en fast skala inte låta kanter förstoras eller förändras beroende på skalan
på kartan. Detta examensarbete ska inte bara visa den exakta placeringen av
koordinaten, utan också en synhållsradie runt koordinaten. Sättet att använda
färger för att simulera numeriska värden kan vara av intresse för detta
examensarbete. Detta examensarbete kan ta användning av att presentera
koordinater i färger, där färgen varierar beroende på tid från nutid. Om
objektet som en användare eller en användargrupp letar efter rör sig, finns det
intresse för att veta hur länge sedan platsen besöktes.
1.1.4 Platsinformation & Värmekartor (Heatmaps)
En annan intressant artikel som finns med sökorden "visualizing historical gps data" förklaras hur en användare kan ladda ner all platsinformation som Google har lagrat, från den inloggade användaren och ladda upp det till ett projekt som renderar datan som en värmekarta (Heatmap) över den vanliga kartan [5]. Projektet heter “ Location History Visualizer” [6]. När en följer guiden [5] och laddar ner all historisk platsdata för en användare och laddar
3upp den till Location History Visualizers webbsida visualiseras platshistoriken [6], en kan också navigera genom kartan och se visualiseringen av platsdatan. Värmekartan använder färger för att visa hur frekvent objekt från den nedladdade platsdatan förekommer för ett område.
Ju fler objekt i ett område, desto varmare (rödfärgad) är färgen. Få besök
betyder kall (blå färg). Om inga objekt från personens nedladdade platsdata
finns, visas kartan i sin vanliga färg. Att färglägga kartan endast vid besökta
platser och lämna kartan helt orörd vid obesökta platser, skulle kunna
användas i examensarbetet. I sådana fall bör det undersökas hur ett område
räknas och färgas, hur den här typen av algoritmer ser ut. Detta
examensarbete kan använda färgläggningen och färga baserat på hur lång tid
det var platsen besöktes. Location History Visualizer visar inte varje besök på
kartan. Istället beräknar det ett område och visar det området som en färgad
plats. Detta är en typ av visualisering som kan vara av intresse i detta
examensarbete, men istället för att räkna frekvenser i områden, räkna senaste
tidsstämpel.
1.1.5 Polygoner i Google Maps API
Google maps är en karttjänst som under skrivande stund påstås vara den mest använda karttjänsten [12]. Google maps har funnits sedan 2005 och har i nuläget en miljard användare varje månad [12].
Vid sökning på sökmotorn Google efter nyckelorden "map polygons", finns en intressant, icke vetenskaplig, icke referentgranskad artikel som visar en förklaring av hur Google maps fungerar med deras API (Application Programming Interface) för att skapa fyllda polygoner [7]. Polygonerna som Google kan återge på sina kartor kan ha olika färger och former för varje polygon, men inte olika färger i en polygon, det betyder att det kommer att vara svårt att skilja gamla besök från nya besök. Det är möjligt att skapa en ny polygon för en viss tidsperiod. Polygonerna skapas genom att skicka varje yttre koordinat i området till Google maps API.
Att polygoner endast använder sig av de yttersta koordinaterna innebär att en del av arbetet blir att söka och skapa algoritmen som hittar konturen för det sökta området för att skapa polygoner.
Implementationen i detta examensarbete kommer behöva ta hänsyn till den "synhållsradie" som berättar hur långt ifrån varandra kan två koordinater räknas som ett objekt utan att skapa en kant mellan.
Vid de tidigare nämnda sökningarna går det att finna flera tekniker för att
visualisera platsdata på en karta. Två frekvent förekommande tekniker är
Polygons [1.1.6] och Heatmaps [1.1.7]. En mindre frekvent förekommande
teknik i sökningar för att bygga bakgrunden i detta examensarbete är circles
[1.1.8], som kommer att spela en stor roll till slutsatsen i detta
examensarbete.
1.1.6 Polygons
Polygons är en 2 dimensionell form med tre eller fler sidor [8]. En polygon kan användas för att placeras ovanpå en digital karta. Figur 1.2 visar flera polygon på en karta.
Figur 1.2: Figuren visar en karta där ett område är markerat i en mångsidig
figur, en så kallad polygon. Bilden är tagen från den utvecklade miljön.
1.1.7 Heatmaps
Heatmaps även kallat värmekarta är en grafisk representation av data där de enskilda värdena i matrisen är representerade med färger. En heatmap på en karta kan se ut likt figur 1.3.
Figur 1.3: Figuren visar en så kallad heatmap. En karta där det finns
färgade markeringar. Färgerna på markeringarna varierar och simulerar ett
underliggande värde. Bilden är tagen från den utvecklade miljön.
1.1.8 Circles
Circles är en teknik som går att lägga som lager på Google Maps [24]. Circles lägger cirklar över koordinater, vilket visas i figur 1.4. Cirklarnas storlek går att styra i meter mot jordens yta, vilket gör det enkelt att styra storleken på den visualiserade ytan efter den faktiska ytan på jorden som den digitala kartan visualiserar.
Figur 1.4: Figuren visar en karta som är framtagen med Google Maps API.
Kartan har ett Circles-lager. Cirklarna varierar i färg mellan blått och rött.
Bilden är tagen från den utvecklade miljön.
1.2 Relaterade arbeten
I detta avsnitt presenteras de arbeten som kommer att spela roll i hur arbetet i detta examensarbete kommer att gå till väga. Varje arbete kommer på något vis guida detta examensarbetets utförande.
1.2.1 Utveckling av Location-Based Services för webbläsare
En studie om platsbaserade tjänster i kombination med Google maps har gjorts av fyra studenter för att visa hur LBS-tekniken går att utveckla med HTML5. Studien fokuserar främst på det tekniska perspektivet för hur man implementerar en platsbaserad tjänst med HTML5 och Google Maps. Syftet är att spåra ett objekt som ständigt rör sig. Detta examensarbete kan ta nytta av tekniska metoder från studien, som hur webbintegration med Google Maps implementeras samt hur strukturen för en LBS-tjänst för webbläsaren kan utvecklas [2].
I arbetet “ Web-Based Location Sharing Service for a Group of People to Get Together ” försöker författarna Ogawa Shuji, Niibori Michitoshi &
Kamada Masaru utveckla en webbaserad applikation som ska förenkla för personer att kunna hitta varandra när de ska träffas. Arbetet fokuserar på platsdelning mellan mobila enheter. Här testas möjligheterna att skapa en webbläsarbaserad webbapplikation som kan dela flera platser på en karta via URL-länkar [1]. Arbetet undersöker inte platshistorik och fokuserar strikt på den aktuella/senaste geografiska platsen. Systemet som forskargruppen bygger under studien är helt inriktad mot webbläsare.
1.2.2 Analys av rörelsemönster för försvunna personer
Vid sökning på Google Scholar med sökorden “ missing people search
techniques ” hittas ett arbete där fyra personer undersöker hur det på ett säkert
vis går att söka efter försvunna personer i Yosemite National Park i USA [9].
I arbetet försöker forskarna ta reda vilka områden personer är mest benägna att befinna sig i, och också hur långt personen kan ha rört sig baserat på hastighet och vart personen senast bekräftades vara. Hastigheten detta arbete använder som en genomsnittlig gånghastighet är 5,1 km/h. Detta är en hastighet som kan komma till användning, när koordinater behöver genereras under detta examensarbete. Arbetet skiljer sig i övrigt, mycket från detta examensarbete då arbetet riktar sig direkt mot en specifik park och uppgiften är att optimera sökandet i den parken medan vi testar möjligheten att ta fram en teknik för att visualisera ett ospecificerat områdes sökstatistik. Dock skulle en sökoperation i Yosemite National Park kunna ta användning av tekniker som detta examensarbete ämnar att testa. Forskarna tar reda på zoner där personer med störst sannolikhet är inom en viss tid efter sökandet, vilket kan kompletteras med en digital lösning som visar sökmönster inom ett område med tidsstämplar.
1.2.3 Färgläggning av besökta platser
Vid sökning på Google Scholar med sökorden “ heatmaps google maps”
hittas studien Effects of Color and Threshold on User Perception of Heat Maps där heatmaps färger och storlek på färgat område undersöks [11].
Studien undersöker hur personer upplever heatmaps i ett scenario där färgläggningen ska visualisera mängden besökare på restauranger i en stad.
Studien kommer fram till att majoriteten av svarande uppskattar heatmaps med mer än en färg. 74,4 % utav de 43 som ingick i undersökningen tyckte dessutom att flerfärgade heatmaps visar mer information än enfärgade.
Exempel på en flerfärgad heatmap finns i figur 1.3.
I studien undersöks också hur storleken på det färgade området på kartan upplevs. Resultatet visar att det spelar roll hur stort område som färgas på en karta. Av de storlekar som de testar, visas det att om heatmapen har för litet färglagt område, upplevs det som att kartan innehåller mindre information [11]. Den information som visas i undersökningen kan bli användbar i val av teknik då det visar att flera färger har ett positivt resultat. Detta argumenterar för att använda flerfärgade heatmaps istället för exempelvis polygoner, som är enfärgade.
1.3 Problemställning
Denna studie ämnar att besvara följande två problemställningar.
Hur kan historisk positionsdata bli visualiserad för att skapa en tydlig översikt över ett genomsökt område?
Går det att via Google Maps API visualisera vilka platser som är genomsökta och i vilken ordning?
1.4 Motivation
Detta examensarbete ämnas att vara till nytta för att driva tekniska lösningar framåt i sökoperationer. Problemet detta examensarbete lyfter, kommer att kunna vara av intresse för användare och organisationer som har nytta av att sammanställa besökta koordinater för att försäkra om att ett område är genomsökt. En organisation som kan ha nytta av tekniken är Missing People.
Missing People är en organisation som arbetar volontärt med bland annat polisen för att hitta försvunna personer. De använder sig av tekniker som skallgångskedjor, sökning med hund och sökning med terrängfordon [3].
En tänkbar användare av tekniken som utvecklas i detta examensarbete är
svamp- och bärplockare. De kan finna användning i tekniken för att se deras
sökmönster när de letar efter matnyttigheter i naturen. De kan via tekniken se var de har varit och på så vis förenkla avgörandet i vart de ska gå.
Tekniken kan också vara av intresse för den person som tappat bort sina nycklar i exempelvis en park och behöver veta att de har kammat av hela parkens yta för att hitta nycklarna. Personen kan se rörelsemönstret och få vetskap om vilka positioner denne har kvar att besöka för att skapa försäkran om att parken är genomsökt.
1.5 Mål
Tabell 1.1 visar de mål som steg för steg ska försöka uppnås för att komma till en slutsats för detta examensarbete.
M1 Undersök visualiseringstekniker
M2 Bestäm hur koordinatdata ska samlas in M3 Samla in koordinatdata
M4 Implementera visualiseringsmiljö
M5 Implementera den valda visualiseringstekniken M6 Testa den valda tekniken i visualiseringsmiljön M7 Testa tekniken mot kraven
M8 Analysera resultatet. Om det behövs, ta fram en ny visualiseringsteknik och iterera tillbaka till mål M5.
Tabell 1.1: Tabellen visar målen för detta examensarbete.
Det förväntade resultatet är att skapa en geografisk datavisualisering baserad på koordinater. Visualiseringen syftar till att kartlägga tidigare besökta positioner och få en tydlig bild av vilken del av området som sökts.
Heatmaps är en stark kandidat för att kunna visualisera både vilka platser
som är besökta och i vilken ordning platserna har besökts tack vare
möjligheten att ha flera färger i samma Heatmap.
Att använda polygons för att visualisera besökta platser med olika färger beroende på kronologisk kommer behöva en annan typ av implementation, i jämförelse med heatmaps. Besökta platser kommer att behöva grupperas ihop efter tid och avstånd för att sedan delas upp i olika koordinater. Det finns risker att det kan komma komplikationer under grupperingarna av koordinater, som gör resultatet mindre tillförlitligt.
Verktyget Circles i Google Maps API [18] förväntas kräva mindre för att skapa ett resultat av värde. Eftersom varje koordinat kommer att renderas separat kommer inga grupperingar behöva göras. Det finns risker att många cirklar nära varandra kan skapa otydlighet om många linjer och färger korsar varandra. Det skulle kunna skapa svårigheter att se tydligt hur väl och när ett område genomsöktes.
1.6 Avgränsningar
Arbetet kommer att använda sig utav Google maps API [18]. Google Maps API [10] har välformulerad dokumentation och är väl utbrett och använt med en miljard användare per månad [12]. Google Maps API tillhandahåller flera verktyg som är av intresse att undersöka i detta examensarbete.
Vad en person kan se från en plats beror på många faktorer, bland annat
personens längd, områdets terräng och objektets synlighet och storlek. Detta
examensarbete kommer låta synhållsradien vara en ställbar area som går runt
en koordinat med likvärdig radie i alla riktningar. Koordinaten kommer alltså
att vara precis i mitten av en cirkel. Google maps API [10] deklarerar inte i
dokumentationen att det finns möjlighet att specificera terräng eller underlag
vid en specifik plats. Att ändra synhållsradie går därför inte att göra med
hjälp av Google Maps eftersom det krävs en väldig exakthet på vart varje
träd, sten är och hur högt gräset är jämfört med storleken på objektet. Även ljusstyrka från artificiell belysning eller från ljuskällor som stjärnor, solen och vår måne spelar roll i hur långt synen kan avgöra om objektets existens.
Sökarens subjektiva säkerhet på vad denne har sett och med vilken säkerhet denne såg rätt, spelar också en roll i hur väl området är avsökt. På grund av storleken av vad synhållsradien kan innehålla, kommer därför synhållsradien i detta examensarbete att vara modifierbar och ställbar för den som ser över kartan i testmiljön. Att låta synhållsradien vara ställbar av sökledare eller testledare innebär att synhållsradien kommer att uppskattas av människans subjektiva bedömning av området och dennes egen säkerhet i sig själv. Målet med detta examensarbete är att ta reda på om det går att visualisera historisk positionsdata, därför kommer arbetet kunna genomföras med en konstruerad synhållsradie.
1.7 Målgrupp
Detta examensarbete riktas till studerande och arbetande inom
datavetenskapliga institutioner i Sverige. Frågeställningen kan användas
inom forskning i geografi och datavetenskap. Arbetet ämnar att komma till
användning för att utveckla applikationer eller system med avsikt att markera
ut genomsökta områden på en karta med hjälp av data visualisering med
koordinater. Examensarbetet riktas speciellt till att användas för forskning
och utveckling för ändamål att hitta försvunna personer.
1.8 Disposition
Resterande innehåll av examensarbetet kommer att hantera Metod, Implementation, Utvärdering, Diskussion och Sammanfattning.
Metoden förklaras tillvägagångssättet. Hur utförandet av implementationen kommer att gå till. I metoden presenteras även kravlistan.
Kravlistan kommer att vara referensen till om frågeställningens utförandet räknas som godkänt eller inte. I nästa del förklaras implementationen. Där specificeras hur genomförandet samt hur applikationen har implementerats.
Utvärderingen av implementationen förklaras därefter i del fyra. Där hittas resultatet av de tester som gjort mot kravlistan, samt figurer som visar det visualiserade resultatet från miljön. Tillsammans med varje resultat för varje iteration följer en analys av de objektiva resultaten som har uppnåtts genom vårt examensarbete och subjektiva åsikter och slutsatser om resultatet presenteras. Därefter presenteras en diskussion som innefattar observationer och problem som uppkommit under examensarbetets gång.
I det avslutande avsnittet presenteras en sammanfattning av arbetet och hur resultatet är relevanta för vetenskap eller samhälle i framtiden.
Sammanfattningen presenterar också det framtida arbete som kan göras på
grund av detta examensarbete, samt alternativa sätt att göra om detta
examensarbete.
2 Metod
Målet med detta examensarbete är att ta reda på om det genom koordinater och datavisualisering går att avgöra om ett område är avsökt.
Metoden för detta examensarbete är en utforskande process som kallas Design Science (DS). Detta examensarbete kommer tolka processen Design Science och utefter det forma tillvägagångssättet för examensarbetet.
Tolkningen av Design Science sker genom att tolka arbetet “Design Science Research Methodology for Information Systems Research” [32].
Processen Design Science syftar till att utveckla en artefakt. Artefakten är i
detta examensarbete, den utvecklade miljön som visualiserar resultatet som
kommer att testas mot kraven (Avsnitt 2.1). Utförandet av processen sker
genom sex aktiviteter. Aktivitet 1 är att identifiera och motivera problemet
som examensarbetet ämnar att lösa. Detta examensarbete utför denna
aktivitet i introduktionen (Avsnitt 1). Aktivitet 2 innefattar att definiera en
lösning för problemet som identifierades i introduktionen. Detta
examensarbete definiera en metod att lösa problemet med i avsnitt 2. I
aktivitet 3 ska utveckling av artefakten ske. Utvecklingen av artefakten
beskrivs i implementationen (Avsnitt 3) i detta examensarbete. Där visas och
förklaras metoder och andra delar som är del av den implementerade
lösningen. Aktivitet 4 innefattar en demonstration av den implementerade
artefakten. I detta examensarbete sker demonstrationen genom avsnitt 4,
Utvärdering. Utvärderingen visar figurer från den implementerade artefakten,
samt resultat för tester som visar huruvida artefakten uppfyller kraven
(avsnitt 2.1). Utvärderingen innehåller också Aktivitet 5 som utvärderar
huruvida artefakten löser kraven som är skapade mot frågeställningen, och
om vidare arbete krävs. I utvärderingen avgörs huruvida vidare utveckling av
artefakten behöver ske. Om vidare utveckling behöver ske tas den vunna
implementationen. Därifrån fortsätter arbetet och nya resultat och analyser presenteras. När aktivitet 3, 4, 5 har genomgått det antal iterationer som krävs för att skapa en slutsats om huruvida det går att uppfylla kraven eller inte, går arbetet vidare till diskussionen. Diskussionen visar observationer och problem som uppkommit under examensarbetets gång och synen på resultatets utkomst. Därefter avslutas arbetet med design science sjätte och sista aktivitet. Aktivitet 6 innefattar att kommunicera ut till läsare, hur artefakten kan användas. Aktivitet 6 beskrivs i diskussionen (Avsnitt 5) och i sammanfattningen (Avsnitt 6) av detta examensarbete. Där presenteras en sammanfattning av arbetet och hur resultatet kan vara relevant för forskning eller samhället.
2.1 Krav
Kraven är framtagna av oss och är skapade efter vår uppfattning av de artiklar, texter, webbplatser och andra projekt som vi läst och testat vid framtagningen av detta examensarbete.
Utefter detta tas krav fram på de kriterier som kan komma att spela roll till
användningsområdet. GPS är en vanlig teknik i dagens smarta mobiltelefoner
[ Kap. 1.1] och det är av vikt att använda tekniker som finns tillgängligt i
vanliga enheter. För att kunna visualisera när platsen besöktes kommer
tidsstämplar att behövas, som stämmer överens med när koordinaten
skapades.
2.1.1 Tekniska krav
1. Artefakten ska ta koordinater med tillhörande tidsstämplar som invärde.
2. Visualiseringen av en besökt plats (koordinat) ska kunna visa en markering runt koordinaten som simulerar synhållsradien.
2.1.2 Användbarhetskrav
1. Det ska gå att se på kartan om en plats är besökt eller inte
2. Visualiseringen ska informera om kronologin för de besökta koordinaterna.
2.2 Artefakten
Utveckling samt testmiljön kommer bestå av en webbapplikation utvecklat i programspråket Javascript. Valet av att utveckla en webbapplikation är baserat på att vi i denna studie kommer att testa olika visualiseringstekniker i sig och inte utveckla en slutprodukt. Vid vidare utveckling kan också en webbapplikation utvecklas för att vara responsivt anpassad och då vara kompatibel att användas genom mobiler. Studien kommer att använda Google Maps API version 3.40 för att rendera ut koordinaterna på en karta i form av en värmekarta.
Verktygen som kommer att användas från Google Maps API kommer att implementeras enligt Google Maps utvecklardokumentation [10].
Visualiseringen av besökta platser kommer att använda två färger för att visa vilka koordinater som är besökta, samt när varje koordinat besöktes.
Tvåfärgade heatmaps har visat positiva resultat i arbetet “ Effects of Color and
Threshold on User Perception of Heat Maps” som nämns i introduktionen
arbetet, där röd i deras fall, visualiserar många besökare och blå visualiserar få besökare [11]. Detta examensarbete tar efter detta och visualiserar med rött för de senaste besökta platserna och blått för besökta platser med en äldre tidsstämpel.
Valet av JavaScript som programspråk samt Google Maps API är gjort utifrån tidigare erfarenheter samt att Google Maps är den mest använda karttjänsten [12], med verktyg för att själv implementera flera typer av lager som värmekartor, polygoner och cirklar.
2.3 Visuell design
Detta examensarbete kommer att kunna testa frågeställningen med en implementation av en karta som renderas genom Google Maps API. Det kommer endast behövas en visualisering av själva kartan från Google maps.
Eftersom frågeställningen ämnar att svara på huruvida det går att visualisera positionsdata för att avgöra om ett område är avsökt eller inte, kommer inga verktyg utanför kartan att implementeras. Artefakten kommer helt att bruka tekniker som tillhandahålls och visualiseras i kartan. Fokus på visualisering ligger i verktyg som heatmaps, polygons och circles.
2.4 Automatiska enhetstester
För att utföra automatiska enhetstester kommer ramverket Jest att användas.
Jest är ett testramverk för javascript [23], Jest är valt för att det i detta projekt ej kommer kräva några konfigureringar för att få det kompatibelt med artefakten som ska utvecklas.
2.5 Validering
Miljön som utvecklas efter kravlistan kommer att testas mot tester. Dessa
tester (Bilaga A) baseras på kraven. Varje krav har minst ett test som avgör
om kravet är uppfyllt eller inte.
2.6 Tillförlitlighet och validitet
Under arbetets gång kommer synhållsradie att estimeras. Synhållsradie kommer att utgöra ett område runt om koordinatens plats, där den människa som besökt koordinaten beräknas ha kunnat avgöra statusen för målets existens. Den så kallade synhållsradie är svår att avgöra och kan skilja beroende på oförutsägbar terräng. Även objektets storlek spelar stor roll för radien för det genomsökta området. Radien kommer inte heller ta hänsyn till användarens längd eller riktning, vilka också är avgörande faktorer i den verkligt sökta radien.
2.7 Etiska överväganden
Detta examensarbete kommer inte att visa användardata för de koordinater
som används under arbetets gång. Detta examensarbete kommer inte heller
att visa kartexempel på områden som kan upplevas stötande för läsare.
3 Implementation
Nedan följer design och implementationen av artefakten som ämnar att uppfylla frågeställningen i detta examensarbete. Implementationen visar vilka verktyg och moduler som behövs samt metoder som är av stor vikt och påverkar resultatets artefakten. Artefakten är en Javascript-klient som kommunicerar med Google Maps API för att skapa visualiseringar med hjälp av koordinater. Anropen till Google Maps varierar beroende på vilken visualisering som ämnas att visas.
3.1 Samla koordinater
Koordinater är tänkta att användas som underlag för rendering av data, dessa kommer via artefakten göra det möjligt att välja en plats på en karta och därefter trycka eller dra muspekaren över kartan för att samla in koordinaterna där muspekarens position är på kartan. Resultatet blir en bank av koordinaterna. Detta bidrar till att det enkelt går att simulera ett gångmönster utan att behöva röra sig på den faktiska platsen.
För att skapa nya koordinater till systemets dataset används musklick på artefaktens renderade karta. Koordinaten skapas efter muspekarens placering på artefakten karta och får den verkliga position som den markerade platsen på artefakten karta visar. Koordinaten kommer att sparas tillsammans med en tidsstämpel av typen “ Unix Epoch Timestamp” . Koordinaten och
4tidsstämpeln sparas i ett objekt som ser ut likt Kod 3.1. Att klicka fram koordinater med musen på artefaktens karta gör det enkelt att välja och testa vägar som visar sökmönster efter det precisa mönster som önskas. Det går enkelt att simulera ett gångmönster utan att behöva röra sig på den faktiska platsen.
4Unix Epoch Timestamp är en tideräkning som räknar antalet sekunder sedan 1 Januari 1970 [14].
{
"location": {
"lat": 56.65731472997458,
"lng": 16.321155688268764 },
"weight": 1,
"timestamp": 1586506818628 }
Kod 3.1: Koden visar ett koordinat-objekt i JSON-format. Objektet location, som i sin tur innehåller de numeriska värdena för latitud(lat) och longitud(lng). Weight värdet visar tyngden av färgernas värde. Timestamp är tidpunkt enligt “UNIX Epoch Timestamp”.
3.2 Datalagring
Lagringen av serier med koordinater och tillhörande tidsstämplar sparas som objekt i en array. Arrayen med objekt skrivs om till JSON-format, vilket är ett språkoberoende textformat, som kan användas för att lagra objekten som text och sedan ladda tillbaka dem till JavaScripts typ av array och objekt [16].
Känslig data som inte ska hamna på publika platser sparas som
miljövariabler. Miljövariabler är data som är unika för enheten som koden
körs på, eller variabler som inte ska följa med om koden kopieras. I detta
examensarbete är API-Nyckeln (Avsnitt 3.3) en variabel som inte ska följa
med till andra miljöer. API-nyckeln lagras därför separat som en
miljövariabel.
3.3 Åtkomst och lagring av API-nyckel
För att kunna använda Google Maps API krävs en unik API-nyckel vars syfte är att identifiera varje förfrågning till Googles Maps API från det projekt som utvecklas. För att kunna skapa eller tillgå en API-nyckel krävs det ett registrerat Google-konto samt att det registrerade kontot har en faktureringsmetod [21].
Enligt anvisningarna från dokumentationen av Google Maps API sker all javascript i HTML-filen inom “script-taggar” . Studiens implementation
5ämnar att undvika att kombinera HTML och javascript-kod för att enklare skriva javascript-tester samt att spara API-nyckeln separat från koden i en env-fil . För göra detta möjligt används
6load-google-maps-api [20] som är ett npm-paket som gör det möjligt att skriva javascript-kod i en separat
7javascript-fil.
3.4 Kartfunktionalitet
load-google-maps-api returnerar ett google.maps-objekt som kan användas för att nå all funktionalitet som Google Maps API tillhandahåller [19].
load-google-maps-api kräver en parameter key där en API-nyckel från Google förväntas. För att få tillgång till heatmaps krävs också en parameter libraries som inkluderar en array med strängen “visualization”. Kod 3.2 visar hur load-google-maps-api används.
loadGoogleMapsApi({
5 HTML-elementet script används för att bädda in eller hänvisa körbar kod [18].
6 En env-fil är ett sätt att lagra konfiguration i miljön separat från koden [19].
7 NPM är en pakethanterare för publicering av Node.js-projekt med öppen källkod[22]
key: process.env.GOOGLE_MAPS_API_KEY, libraries: ['visualization'],
}).then((google) => { google})
Kod 3.2: Koden visar hur load-google-maps-api [20] returnerar en variabel som sedan används för att referera till Google Maps API.
För att skapa en karta tillämpas google.maps-objektets klass Map vars konstruktor kräver ett utvalt HTML-element samt en parameter zoom. Zoom anger utgångsvärdet för inzoomning vid rendering av kartan. Konstruktorn tar också emot flera parametrar som är valfria [17]. Vår konstruktor inkluderar utöver de nödvändig parametrarna också center och mapTypId.
Center används för fastställa mittpunkten av kartan med hjälp av en given koordinat bestående av en latitud och longitud. MapTypeId är vilken typ av karta som ska skapas [17]. Kod 3.3 visar hur man initierar en ny Google Maps karta .
new googleMaps.Map(mapElement, {
center: { lat: 56.657081713112085, lng: 16.321899075213206 }, zoom: 19,
mapTypeId: 'satellite', })
Kod 3.3: Koden visar tillvägagångssättet för att skapa en ny Google maps karta med tillhörande parametrar.
3.5 Färgläggning
Google Maps lager färgsätts med RGBA-skala där R är röd, G är grön, B är
blå och A är synlighet (0 = helt transparent, 1 = helt synlig). Eftersom röd
och blå finns med i skalan och inte behöver på något vis blandas, är det lätt
att ställa färgerna till de som ska användas. RGB har skalan 0-255. 0=ingen
del, 255=max färg. Färgerna kan skickas in med objektet i ett lager för att sätta den önskade färgen. Heatmaps skiljer sig i hur färgläggningen hanteras.
För att färglägga heatmaps skickas flera färger in samtidig och sedan används vikter för att styra vilken av dessa färger ett visst område får.
3.6 Iterationer
För att lyckas uppnå godkänt på alla tester (Bilaga A) som skrivits för att uppnå kraven (Avsnitt 2.1) sker arbetet i iterationer där en ny teknik testas vid varje iteration. När ett eller flera tester misslyckas, startas arbetet om.
Med resultatet från den förra iterationen som feedback, tas nya val av tekniker fram och implementeras. Iterationerna sker fram till att ett resultat kan presenteras som uppfyller kraven (Avsnitt 2.1). Under detta examensarbete krävdes tre iterationer för att uppnå ett resultat som klarade samtliga krav.
3.6.1 Iteration 1, Heatmaps
Iteration ett testar Google Maps APIs heatmaps-lager. Nedan finns information om de delar som är unika för iterationen där heatmaps implementeras.
3.6.1.1 Vikter
För att styra färgen av varje koordinat i ett heatmap lager, används vikter.
Flera färger av typen RGBA, likt kod 3.4, skickas in i heatmapen i en array.
En högre vikt kommer att resultera i att större del av koordinatens
färgmarkering har mer av de färger som är i slutet av färgskalan arrayen. Ett
lågt värde som vikt innebär att färgen visas enligt ett tidigare värde i
färgskalan i arrayen.
En utplacerad koordinat kommer att ha sin maxvikt i mitten, sedan avtar vikten gradvis i takt med avståndet från mittpunkten, därav avtar också färgen och faller stegvis mot en blåare färg för att sedan tonas ut helt, vilket resulterar i en heatmap likt heatmapen i figur 3.1.
Figur 3.1: Figuren ett heatmap-lager. Färgen på heatmapen är röd vid koordinatens mittpunkt och färgen ändras till blå när avståndet från mittpunkten ökar.
För att kunna ta hänsyn till att nya koordinater ska ha en annan färg än koordinater som har en äldre tidsstämpel används vikter. De koordinater med ny tidsstämpel har ett högre värde som vikt. För att skapa specifika vikter för varje utplacerad koordinat beräknas varje koordinat i jämförelse med de andra i en normaliseringsalgoritm, vilket ger varje koordinat ett unikt vikt-värde. I detta examensarbete skrevs en algoritm som itererar samtliga koordinater och räknar ut ett värde mellan 1 och 100. Formeln som används visas i figur 3.2.
(tidsstämpel - “lägsta tidsstämpel” / (“högsta tidsstämpel” - “lägsta tidsstämpel”) * 100)
Figur 3.2: Figuren visar den matematiska formel som räknar ut viktvärdet
för en koordinat i pseudokod.
Eftersom vikten avtar gradvis ju längre ifrån en centerpunkt man kommer, betyder det att heatmapens färglagda område alltid kommer att ha en blå yttre kant innan den helt försvinner. Även om det är den senaste besökta platsen, kommer denna endast att ha en röd kärna, men fortfarande en blå kant.
3.6.1.2 Skapa Heatmap-lager
För att visualisera en heatmap instansieras ett nytt heatmap-lager som sedan appliceras på en redan befintlig Google maps karta. Kartans ursprungliga vy visas i figur 3.3. För att skapa ett heatmap-lager används google.maps-objektet (Avsnitt 3.3) för att tillgå biblioteket visualization där klassen HeatmapLayer förekommer. HeatmapLayer kräver en parameter data som ska innehålla en Array med LatLng-objekt som beskrivs mer i 3.6.1.3.
För att applicera detta heatmap-lager tillämpas funktionen setMap som kräver en redan befintlig Google maps karta som parameter. Figur 3.4 visar kartans vy efter heatmaps-lagret instansierats.
Figur 3.3: Figuren visar visualiseringen från Google Maps API innan
instansiering av lager med heatmaps eller andra tekniker.
Figur 3.3: Figuren visar visualiseringen från Google Maps API när ett heatmaps-lager har instansierats
3.6.1.3 Konvertera koordinater
Heatmap-lagret kräver en array med en eller flera Latlng-objekt. Ett Latlng-objekt är ett objekt som representerar en geografisk punkt innehållande Latitud & Longitud [15]. För att kartan i den implementerade miljön ska kunna rendera heatmap-lagret behöver varje koordinat i det insamlade datasetet konverteras till Latlng-objekt för att göra datasetet kompatibelt med heatmaps-lagret. Kod 3.5 visar hur implementationen sker för att skapa ett Latlng-objekt.
{
location: new window.google.maps.LatLng({
lat: cord.location.lat, lng: cord.location.lng, }),
weight: cord.weight, }
Kod 3.5: Koden visar strukturen för hur ett LatLng-objekt ser ut.
3.6.2 Iteration 2, Polygons
I iteration två utforskas och testas verktyget Polygons som finns tillhandahållet i Google Maps API.
Polygonerna kommer att använda sig utav samma färgval (Avsnitt 2.2) som heatmap-lagret, vilket är blått för polygoner med koordinater som besöktes för länge sedan och rött för polygoner med nyligen besökta koordinater. Eftersom polygoner innehåller flera koordinater i en grupp, till skillnad från heatmaps, där varje koordinat renderas för sig, kommer koordinaterna behöva delas upp och grupperas och efter tid. Därefter behöver de tidsindelade grupperna, grupperas i efter avstånd och närliggande koordinater behöver sammanfogas och skapar en geometrisk form.
3.6.2.1 Gruppera koordinater 3.6.2.1.1 Tid
För att uppnå kraven (Avsnitt 2.1) i detta examensarbete ska visualiseringen klargöra den kronologiska ordningen platser är besökta i. Koordinaterna behöver först grupperas efter tid för att kunna skapa polygoner som presenterar en tidpunkt.
För att dela upp koordinaterna efter tid itereras alla koordinater i datasetet och delas upp efter den timme som medföljande tidsstämpel visar och sparas som en nyckel i ett objekt. Objektsnyckelns namn stämmer överens med timmen som tidsstämpeln visar.
3.6.2.1.2 Avstånd
För att kunna se vilka platser som är genomsökta och inte, med hänsyn till
synhållsradien behöver avståndet mellan koordinater mätas. Från två
koordinaternas longitud och latitud, räknas avståndet ut i meter, med hjälp av en algoritm från forumet Stack Overflow [26]. De koordinater som har ett avstånd som är mindre eller lika med synhållsradien grupperas till varandra och skapar en polygon. Om det finns större avstånd emellan koordinater än synhållsradien, skapas en ny polygon där nya koordinaters grannar letas upp och samlas ihop. Vilka steg som tas förklaras i figur 3.2.
Figur 3.2: Figuren visar ett flödesdiagram som förklarar hur grupperingar
av en lista med koordinater grupperas efter avståndet till andra koordinater.
Hur koden är implementerad för att lösa grupperingar av koordinater visas i Bilaga C.
3.6.2.2 Form
För att kunna skapa polygoner av stora dataset krävs att de yttre koordinaterna hittas. Eftersom polygonerna ska visa området där koordinater är besökta, behöver kurvor i polygonerna kunna anta konkava former.
8Exempel på en konkav polygon visas i figur 3.3. Paketet concaveman [25]
hjälper till att identifiera koordinaterna som är ytterst i datasetet.
Figur 3.3: Figuren visar en polygon som har konkava kurvor. Eftersom
8 En konkav kurva sträcker sig inåt medan konvex är en kurva sträcker sig utåt[27]
polygonen har kurvor som går inåt är det en konkav polygon.
3.6.2.3 Färgläggning
Till skillnad från heatmaps-larget, där vikter ( 3.6.1.1) används för att förändra färgen för ett område, färgläggs polygons genom att skicka in en färg i RGBA skala (3.4 Färgläggning). För att färglägga polygoner beroende av tid, i en skala som går från blått på de koordinater med äldst tidsstämpel till rött på de med den senaste tidsstämpeln, används en enkel algoritm.
Exempel på färgläggningar för polygonerna, baserat på tid, visas i figur 3.4.
Figur 3.4: Figuren visar polygoner med olika färger som skiftar mellan rött och blått. Ju mer röd färg polygonen har, desto senare tidsstämpel har den.
Ju mer blå färg i polygonen, desto äldre tidsstämplar i koordinaterna i
polygonen.
3.6.3 Iteration 3, Circles
I iteration tre utforskas och testas verktyget Circles som finns tillhandahållet i Google Maps API. Circles gör det möjligt att för varje koordinat skapa och applicera geometriska cirklar på Google Maps kartan. I denna iteration kommer det testas om det med hjälp av cirklar går att möta kraven i (Avsnitt 2.1). Nedan finns information om de delar som är unika för iterationen där Circles implementeras.
3.6.3.1 Gruppera koordinater
För att uppnå kraven (Avsnitt 2.1) i detta examensarbete ska visualiseringen klargöra den kronologiska ordningen platser är besökta i. Denna iteration kommer att bemöta detta krav genom att färglägga respektive cirklar med olika färger beroende på tid och därmed utifrån färgerna på cirklarna kunna klargöra den kronologiska ordningen plaster är besökta. För att färglägga cirklarna med olika färger behöver koordinaterna att grupperas efter tid. För att dela upp koordinaterna efter tid itereras alla koordinater i datasetet efter timestamp som är en av koordinatens attribut. När datasetet är sorterat i kronologisk ordning efter tiden kommer sedan datasetet bli uppdelat i valfritt nummer av delar. Varje del kommer sedan färgläggas med en färg. Kod 3.6 visar implementationen av uträkningen för att dela upp koordinater i flera delar.
// array is the dataset that will be split into part.
// parts is how many parts the array will be divided into.
let result = [];
for (let i = parts; i > 0; i--) {
result.push(array.splice(0, Math.ceil(array.length / i)));
}
return result;
Kod 3.6: Koden visar algoritmen för att dela upp koordinaterna i flera delar.
3.6.3.2 Färgläggning
Cirklarna kommer att använda sig utav samma val av färger (Avsnitt 2.2) som vid färgläggning (3.5 Färgläggning) av polygoner, där en färg i RGBA skala anges för varje instansierad cirkel. Uträkningen för att tilldela respektive cirkel en färg är densamma som i föregående iteration där polygonerna tilldelas färger men här tilldelas färger beroende på antal delar datasetet med koordinater är uppdelade i. Detta förklaras mer i 3.5.3.1 Gruppera koordinater. Det förväntade resultatet är att cirklar med tillhörande koordinater vars tidsstämpel som nyligen är besökta kommer bli röda och koordinater vars tidsstämpel är äldre blir blå. Figur 3.5 visar exempel på cirklar med olika färger för olika tidsstämplar.
Figur 3.5: Figuren visar cirklar med olika färger som skiftar mellan rött och blått. Ju mer röd färg cirkeln har, desto nyare tidsstämpel har koordinaten.
Mer blå färg betyder att tidsstämpeln för koordinaten är äldre.
3.6.3.3 Skapa cirklar
Metoden createCircles instansierar cirklar för varje koordinat i datasetet.
Cirklarna appliceras sedan på en redan befintlig Google Maps karta. De tre parametrarna som är betydelsefulla i instansieringen av nya cirklar är fillColor , center och radius. fillColor kommer bestämma vilken färg cirkeln kommer fyllas med, detta baseras på tiden en koordinat har besökts, detta beskrivs mer i 3.6.2.3 Färgläggning. Center är cirkelns mittpunkt och utgår från koordinatens longitud och latitud. Radius anger cirkelns radie i meter och är i detta examensarbete avgörande för att implementera synhållsradien som beskrivs mer i introduktionen, 1.6.1. Kod 3.7 visar implementationen för att skapa en ny cirkel.
new window.google.maps.Circle({
strokeColor: '#FF0000', strokeOpacity: 0.2, strokeWeight: 2,
fillColor: coordinates[coord].color, fillOpacity: 0.35,
map: map,
center: coordinates[coord].location, radius: searchRadius
});
Kod 3.7: Koden visar tillvägagångssättet för att skapa en ny cirkel.
4 Utvärdering
I detta avsnitt visas resultatet av arbetet och utvärderingar av iterationerna presenteras. Bilder och tester demonstrerar resultatet av varje iteration.
De visualiseringar som har implementerats är Heatmaps, Polygons och Circles. Genom dessa visualiseringar ämnas att fastställa om ett område är avsökt. För att validera respektive visualisering gentemot kraven i metoden 2.1 är Enhetstester samt Manuella tester utförda. Testerna är tillgängliga i bilaga A och utförande av tester är tillgängliga i bilaga B.
Nedan följer resultat från de tester som utförts för att testa respektive visualisering. Sammanställning av alla körda manuella tester visas i tabell 4.5.
4.1 Enhetstester
Följande resultat är från enhetstester som har exekveras på ett dataset som har samlats in med artefakten. Testerna ämnar att validera om ett dataset innehåller de attribut som krävs för att artefakten ska fungera. Resultatet för enhetstesterna presenteras i tabell 4.1
Test ID
Krav Figur Namn Resultat
1.1 T1 B.4.1 Inkluderar en koordinat attributet
“longitud”
Godkänt
1.2 T1 B.4.2 Attributet “longitud” är av typen
“Number”
Godkänt
1.3 T1 B.4.3 Inkluderar en koordinat attributet Godkänt
“latitud”
1.4 T1 B.4.4 Attributet “latitud” är av typen
“Number”
Godkänt
1.5 T1 B.4.5 Inkluderar en koordinat attributet
“timestamp”
Godkänt
1.6 T1 B.4.6 Attributet “timestamp” är av typen
“Number”
Godkänt
Tabell 4.1: Figuren visar resultatet för utförda enhetstester som testar datasetet med koordinater som använts som data för visualisering. Samtliga tester är godkända.
Test T1.1 , T1.2 , T1.3 , T1.4, T1.5 , T1.6 är godkända och validerar att attributen longitud, latitud och timestamp är inkluderade i datasetet som kommer används. Dessa tre attribut är nödvändiga för att artefakten ska kunna rendera ut koordinater på kartan. Detta betyder också att tekniker som använder koordinatsystem kan implementera tekniken för användning.
4.2 Iteration 1, Heatmaps
Nedan följer resultat och utvärdering av implementationen av heatmaps.
Visualiseringen visas i figur 4.1. Testresultatet visas i tabell 4.2.
Figur 4.1: Figuren visar en karta med ett heatmap lager. Bilden är tagen från den utvecklade miljön
4.2.1 Manuella testresultat
Tabell 4.2 Visar en överblick över resultatet från testsviten i iteration 1 där heatmaps testades mot kraven i avsnitt 2.1.
Test ID
Krav Figur Namn Resultat
A1.1 A1 B.1.1 Ett obesökt område skiljer sig ifrån ett besökt
Godkänt
A2.1 A2 B.1.2 En ny koordinat visualiseras i rött
Icke GodkändA2.2 A2 B.1.3 En gammal koordinat visualiseras i blått
IckeGodkänd
T2.1 T2 B.1.4 En koordinat visas med omkrets Godkänt T2.2 T2 B.1.5 Synhållsradien är konstant
IckeGodkänd
Tabell 4.2: Tabellen visar en sammanställning av tester för heatmaps.
Resultatet visar två godkända och tre icke godkända punkter.
A1 Det ska gå att se på om en plats är besökt eller inte
Detta kravet testas genom Test ID A1.1 testar om en koordinat som används i systemet skiljer sig från Google Maps ursprungliga karta. Testet jämför samma plats och analyserar skillnaden mellan de två kartorna. Testet visar att det finns en skillnad mellan kartorna. Artefaktsmiljön har färg som omringar den markerade platsen. Detta kravet är därför uppfyllt.
A2 Visualiseringen ska informera om kronologin för de besökta koordinaterna.
Kravet ämnar att uppfylla att artefakten visualiserar en synlig skillnad mellan koordinater beroende på vilken tidpunkt koordinaten är satt. För att testa detta utfördes testerna A2.1 och A2.2 .
Testet A2.1 testar om den koordinat med nyast tidsstämpel visas i rött.
Testets resultat visar att färgläggningen är röd i mitten men blir blå i den yttersta kanten. Detta är inte godkänt eftersom färgerna skiljer sig, vilket betyder att det inte går att avgöra att hela området är avsökt vid samma tidpunkt. Det ser istället ut som att den yttre kanten är besökt för länge sedan och den inre platsen är sökt nyligen.
Test A2.2 testar hur den koordinat som är äldst visas. Den koordinaten ska
visa en blå färg. Testet visar att det inte finns någon direkt synlig färg alls på den äldsta koordinaten. Det finns eventuellt en svag färg, men den är inte stark nog för att avgöra om platsen är besökt. Det kommer inte gå att säga med bara en karta att platsen är besökt för länge sedan. Testet blev därför inte godkänt.
Det kommer inte gå att avgöra alla platser som är sökta och i vilken ordning de är besökta, eftersom de gamla koordinaterna tunnas ut i färg och de nya alltid visar en ytterkant i en färg som skiljer sig från resten av markeringen.
T2 Visualiseringen av en besökt plats (koordinat) ska kunna visa en markering runt koordinaten som simulerar synhållsradien.
Två tester kördes för att testa om kravet uppfyllts.
Test T2.1 testar om den utmärkta koordinaten har en omkrets runt omkring. Testet visar att det finns en omkrets runt omkring som är färgad i rött i mitten och blir blåare längre ut. Detta uppfyller testets kriterier som endast testar om omkrets finns. Det finns därför ett område som kan representera en synhållsradien.
Test T2.2 testar att området som representerar synhållsradien är konstant.
Detta är av vikt eftersom synhållsradien måste hålla samma skala, relativt till skalan på kartan. Testets resultat visar att storleken på omkretsen på det färgade område inte följer skalenligt till kartan om kartan förstoras eller förminskas. Istället behåller den samma storlek skalenligt till skärmen. Vilket innebär att området relativt till kartan blir större om kartan zoomas ut. Det går därför inte att använda detta till att visa en pålitlig synhållsradien.
Det innebär att kravet inte kan räknas som uppfyllt, eftersom det inte kommer
att gå att se vart en människa har sökt av området.
4.3 Iteration 2, Polygons
Nedan följer resultat och utvärdering av implementationen av polygons. Två exempel på visualiseringar finns nedan. Figur 4.2 visar visualisering där koordinater är grupperade efter timme och med mindre än fyra meter avstånd emellan. Figur 4.3 visar polygoner som är grupperade efter timme och med mindre än 10 meter mellan varje koordinat. Testresultatet visas i tabell 4.3.
Figur 4.2: Figuren visar en karta med flera polygons där koordinater med
tidsstämpel från samma timme och med ett avstånd på 4 meter eller mindre
grupperas. Bilden är tagen från den utvecklade miljön.
Figur 4.3: Figuren visar en karta med flera polygons där koordinater med tidsstämpel från samma timme och med ett avstånd på 10 meter eller mindre grupperas. Bilden är tagen från den utvecklade miljön.
4.3.1 Manuella testresultat
Från de manuella tester som utfördes i iteration 2, där polygons testades, visas en överblick över testerna i tabell 4.3.
Test ID
Krav Figur Namn Resultat
