Hårdvaruacceleringens påverkan på interaktiva karttjänster: Ej jämförelse mellan variationer, Leaflet.js+D3.js och OpenLayers

Hårdvaruaccelereringens påverkan på interaktiva karttjänster

En jämförelse mellan variationer, Leaflet.js+D3.js och OpenLayers

The effect of hardware acceleration on interactive map services

A comparison between variations, Leaflet.js+D3.js and OpenLayers

Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng

Vårtermin 2020

Ludwig Carlsson

Handledare: Henrik Gustavsson Examinator: Marcus Brohede

Sammanfattning

Webbaserade karttjänster är ett mycket användbart verktyg som används av hela världen. En karta kan hjälpa till med navigering och geografisk datavisualisering. Att skapa en karttjänst går att göra på flertal olika sätt med flera olika verktyg som utnyttjar diverse tekniker. På grund av sin detaljerade utritning och sina animationer så klassas karttjänster som CPU-intensiva och bör därför vara ett bra användningsområde för hårdvaruaccelerering. När man interagerar med en karta så sker mycket utritningar och beräkningar som tros kunna dra nytta av möjligheten till hårdvaruaccelerering. Studien kommer att undersöka hur hårdvaruaccelerering påverkar laddningstid, utritningstid vid zoom och FPS vid interaktion och avgöra om det är värt att använda. Resultatet som erhölls påvisade negativ påverkan vid laddningstid och utritningstid men positiv påverkan på FPS vid interaktion i ett inzoomat läge men negativ påverkan på zoomnivån som är standard. En slutsats kan då dras att hårdvaruaccelerering inte är värt det i denna form av kartapplikation.

Nyckelord: hårdvaruaccelerering, WebGIS, interaktiv karta, OpenLayers, Leaflet.js, D3.js

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund ... 2

2.1 Kartor ... 2

2.2 Animation ... 2

2.3 WebGL ... 3

2.4 Node.js ... 4

2.5 OpenLayers ... 4

2.6 Leaflet.js ... 5

2.7 D3.js ... 6

2.8 Hårdvaruaccelerering ... 7

3 Problemformulering ... 8

3.1 Hypotes ... 9

4 Metod ... 10

4.1 Alternativa metoder ... 10

4.2 Experimentupplägg ... 11

4.3 Etik... 11

5 Genomförande ... 12

5.1 Litteraturstudie ... 12

5.2 Progression... 13

5.2.1 Leaflet.js + D3.js ... 13

5.2.2 OpenLayers ... 14

5.3 Applikationen ... 15

5.3.1 Leaflet.js + D3.js ... 16

5.3.2 OpenLayers ... 19

5.3.3 Mätning av laddningstider och FPS ... 21

5.3.4 Mätscript... 22

5.4 Pilotstudie ... 23

5.4.1 Resultat av pilotstudie ... 24

5.4.2 Reflektioner om pilotstudien ... 27

6 Resultat ... 29

6.1 Presentation av experiment ... 29

6.1.1 Laddningstider ... 30

6.1.2 Mätning av FPS vid interaktion... 33

6.2 Analys ... 34

6.2.1 Laddningstid vid initial rendering ... 35

6.2.2 Utritningstid vid zoom ... 35

6.2.3 FPS vid interaktion ... 35

6.3 Slutsatser ... 35

7 Avslutande diskussion ... 37

7.1 Sammanfattning ... 37

7.2 Diskussion ... 38

7.2.1 Samhällsnytta ... 38

7.2.2 Etik ... 39

7.3 Framtida arbeten... 39

Referenser ... 41

1 Introduktion

I flera generationer har människan använt kartor för att navigera både lokalt och globalt. På senare år har webbaserade versioner av dessa kartor blivit allt mer tillgängliga (Krämer &

Gutbell 2015; Wang & Wang 2009). Användningsområden hos kartor har utökats och används nu också till visualisering av data, både statisk och dynamisk (Zhao, Zhang & Cao 2006).

Webbaserade karttjänster kan kallas för GIS, Geographical Information System och är och visuellt krävande. En visuellt krävande webbapplikation kommer att vara CPU-intensiv och kräva mycket datorkraft om inte applikationen utnyttjar något som kallas för hårdvaruaccelerering. Hårdvaruaccelerering innebär att applikationen tar hjälp av GPU:n’s resurser för att rendera grafik på webben (Roth, Donohue, Sack, Wallace & Buckingham 2015).

I denna rapport har två implementationer, av tre verktyg som hanterar kartor, ställts mot varandra. Det är OpenLayers och en kombination av D3.js och Leaflet.js. D3.js och Leaflet.js har noterats fungera bra tillsammans då verktygen uppfyller olika krav och därmed kompletterar varandra(Lu, Ai, Zhang & He 2017). Därför har det valts att kombinera dessa i rapporten. OpenLayers utnyttjar hårdvaruaccelerering genom WebGL medan D3.js och Leaflet.js bygger på HTML, CSS och SVG, vilket inte utnyttjar hårdvaruaccelerering.

Hårdvaruaccelerering är dock inte alltid en lösning då det upptäckts att problem med minne, seg laddning och krascher kan uppstå vid fel användning (Zakas 2013). Därför är det bra att undersöka om hårdvaruaccelerering är lämpligt att applicera på en dynamisk karttjänst eller om just den typen av applikation går att lösa bättre utan hårdvaruaccelerering.

Målet i rapporten är att genomföra ett empiriskt experiment där två implementationer av en applikation kommer genomgå mätningar. Det som är tänkt att mätas är laddningstid, utritningstid och bilder per sekund (FPS). Applikationen som skapas kommer att har en Node.js server-sida vilket enligt Yanfeng et al. (2005) kan vara problematiskt då karttjänster är CPU-intensiva, vilket Node.js inte fungerar så bra med (Chitra & Satapathy 2017). Om applikationen behöver utvärderas på en annan server-sida kommer kunna avgöras baserat på resultatet av pilotstudien.

Samtliga bibliotek som används är open-source och får då modifieras och användas fritt till undersökningar som denna. Biblioteket ligger under BSD-licens där en forskare inte får omdistribuera kodbasen utan nedskrivet samtycke. Det är alltså viktigt att tänka på rättigheter när det kommer till användning av ramverk i undersökningar, även fast det står att kodbasen är open-source.

2 Bakgrund

2.1 Kartor

Webben är ett perfekt kommunikations-medium för att sprida geografisk data i form av kartor till en stor publik. Kartor generellt, som i figur 1, är en teknik som har funnits länge och på senare tid vuxit snabbt i webbaserad form (Krämer & Gutbell 2015; Wang & Wang 2009).

Geografisk data på webben kan kallas för GIS, Geographical Information System och dessa system kan användas för både analys och visualisering. I dagsläget presenterar många WebGIS-tjänster statisk data medan både möjligheten och efterfrågan av semi-dynamisk och dynamisk data förbises (Kulawiak, Łuba & Chybicki 2008). Att göra en karttjänst dynamisk är bra för applikationens flexibilitet och ger möjligheten att presentera mer data på ett sätt som utnyttjar flera lager (Zhao, Zhang & Cao 2006). Eftersom GIS presenterar mycket data på ett väldigt visuellt sätt så anses det, enligt Yanfeng et al. (2005) att GIS-applikationer oftast är CPU-intensiva. WebGL är ett verktyg för att utveckla bland annat WebGIS-applikationer på webben på ett bra sätt då möjligheten för användning av grafikprocessorn vid rendering finns, det vill säga hårdvaruaccelerering utan plugins är möjligt. Det innebär också att användande av WebGL blir mer och mer lämpligt eftersom grafikkort (GPU), alltså grafikprocessorer är något som konstant utvecklas, animationer kan alltså bli mer och mer avancerade med tiden (Feng, Wang, Li & Li 2011).

Figur 1

2.2 Animation

Att animera är i grunden att lägga ihop flera bilder av ett motiv med minimal skillnad i taget för att simulera en rörelse eller motion. Detta kan genomföras på många olika sätt med många olika verktyg och än så länge finns inget alternativ som ses som det bästa. Olika verktyg är bra för olika saker. Animation finns i tre olika delar, interaktiv, illustrerande och underhållande.

Interaktiv animation är exempelvis karaktärer, illustrerande är simuleringar och underhållande är CGI som används i filmer. Vanligtvis vid animation så är det olika typer av transformationer av statiska objekt som rotation, förflyttning alternativt förflyttning av kamera för att byta vinkel/vy. Objekten kan också uppleva/utöva andra fysiska krafter. Detta är ett exempel på illustrerande animationer (Ahire, Evans & Blat 2015). Illustrerande animationer kan jämföras med kartor och karttjänster på webben eftersom det är vanligt på

en dynamisk karta att kunna flytta runt kameran och justera skärpa och mängd detaljer vid zoom. Geografisk visualisering på webben är något som har funnits länge men med den konstanta utvecklingen av JavaScript-bibliotek så kan mer avancerade och mer krävande applikationer göras (Evangelidis et al. 2018).

2.3 WebGL

WebGL är ett JavaScript-bibliotek som innehåller många byggstenar för animation på webben och gör det möjligt att både skapa avancerade och simpla applikationer. WebGL står för Web Graphics Library och är ett API som kombinerar HTML5 och JavaScript för att med hjälp av OpenGL’s Shader Language kunna rendera krävande och interaktiv 2D/3D-grafik i Canvas- element. WebGL är inget lätt bibliotek att hantera och kräver mycket förståelse för OpenGL och 3D design. Därför har ramverk eller JavaScript-bibliotek byggts som är baserade på eller utnyttjar det bibliotek WebGL förser en med för att förenkla eller förtydliga ett visst område inom animering. Bibliotek som exempelvis Three.js, Babylon.js och OpenLayers används för massor av olika saker inom animering och kan därmed tillämpas i flera olika projekt (Cao, Hou and Feng 2018). Det skrevs en artikel på hur WebGL kan användas för att kunna visualisera en byggnad i 3D där samtliga våningar och rum visas i en applikation (Gai and Wang 2015). I artikeln berättar Gai och Wang att grafiken och animationerna gjordes med hjälp av biblioteket Three.js som i sin tur bygger på WebGL och på så vis kunde Gai och Wang försäkra sig om att applikationen skulle fungera på moderna webbläsare. Att skapa webbapplikationer med WebGL kan ofta tänkas behöva en serversida av applikationen. Sheng, Zhao, Zhang, Yin och Shu (2017) skapade ett 3D modelleringssystem för en Rubiks kub med hjälp av WebGL’s Three.js och Node.js för sin webbserver.

Figur 2 WebGL-exempel av Mozilla Contributors(CC-BY-SA 2.5)

2.4 Node.js

Node.js är ett ramverk för serversidan av JavaScript-utveckling. Tanken med Node.js är att serversidan skall stödja processer som ska vara igång under en lång tid. Olikt många andra moderna verktyg är Node.js inte beroende av multitrådsteknik för att flera processers exekvering skall ske samtidigt. Node.js utnyttjar asynkrona I/O-händelser. Node.js ger även möjligheten till uppdatering i realtid och skalbarhet vilket i sin tur har resulterat i stora förbättringar prestandamässigt för applikationer som uppdateras i realtid (Jiang, Zhou &

Zhang 2015). Szuba, Ameri, Grabowski, Meyer och Streit (2016) använde Node.js för sitt system som hämtade, lagrade och bearbetade data från satelliter som observerar Jorden.

Datan som hämtades kunde, enligt Szuba et al. klassas som Big Data och eftersom satelliterna hela tiden skickade data så behövdes ett system som fungerade i realtid. Med dessa kriterier kunde Node.js konsteras vara ett bra val eftersom det fungerar bra i realtid och är skalbart.

Enligt Chitra och Satapathy (2017) så utgör kombinationen av JavaScript, effektiv körning och arkitekturen baserad på asynkrona händelser, en mycket bra miljö för webbutveckling.

Undersökningen som gjordes av Chitra och Satapathy (2017) visade att Node.js presterar som bättre i en I/O-intensiv situation än i en CPU-intensiv situation. Trots att GIS-applikationer ofta är CPU-intensiva så är Node.js ett lämpligt val av server-sida på grund av sin arkitektur, kompatibilitet med JavaScript och faktumet att OpenLayers rekommenderar Node.js i sin dokumentation (OpenLayers 2020).

2.5 OpenLayers

OpenLayers är ett JavaScript-bibliotek till för att visa kartor i webbläsaren, kompatibelt med många moderna webbläsare och är inte beroende på servern. Det är ett gratis och open source API som används för att bygga webbaserade geografiska applikationer likt Google Maps.

OpenLayers är byggt i objekt-orienterad JavaScript och på grund av sin open source-licens kunde Kulawiak, Łuba and Chybicki (2008) modifiera, ta bort och lägga till kod fritt i kodbasen. Detta ansågs vara till stor fördel när det kom till flexibilitet, både med design av applikationen och dess interaktivitet. OpenLayers är också flexibelt i den mån att stödjer flera olika tjänster som erbjuder kartdata, exempelvis Google Maps eller ArcGIS. OpenLayers stödjer även en teknik som kan visualisera ny data på kartan utan att ladda om sidan och det innebär att kartan är dynamisk. Inte nog med det så finns möjligheten att rendera geografisk data på klient-siden, alltså direkt i browsern för att inte belasta nätverket (Sitanggang et al.

2017).

Farkas (2017) pratar om att OpenLayers är bra i skapandet av GIS-applikationer på webben eftersom det som utnyttjar WebGL och dess hårdvaruaccelerering. Han menar också att det är ett bra val eftersom det har en resonabel inlärningskurva. Farkas (2017) menar också att det finns negativa saker med OpenLayers 3 som exempelvis att det inte är kapabelt till att skapa 3D-visualiseringar utan hjälp av andra verktyg. Det finns också begränsat stöd men möjligheter till att skapa 2D-visualiseringar med hårdvaruaccelerering. Han menar att Leaflet.js anses kunna vara ett alternativ till 2D-visualiseringar trots att det inte byggt på WebGL. Att OpenLayers inte stödjer dessa aspekter är något som bör ifrågasättas då den nuvarande versionen av OpenLayers är 6.2.1 och biblioteket har alltså uppdaterats efter artikelns publicering.

Figur 3

2.6 Leaflet.js

Leaflet.js utvecklades under år 2010 och släpptes för första gången 2011 av Vladimir Agafonkin. Målet med JavaScript-biblioteket var att skapa ett open source API för dem som fann intresse för att skapa interaktiva och dynamiska kartor för webben. Leaflet.js formades med avsikten att det skulle fungera bra med en tjänst som heter OpenStreetMaps och biblioteket är även känt för att stödja mobil-användning på ett bra sätt. Leaflet.js har blivit ett mycket välkänt open sourcebibliotek genom sin okomplicerade struktur och den enkla utvecklingen till både webb och mobil (Edler and Vetter 2019). Leaflet ger tillgång till funktioner som markörer, popups, olika typer av lager, polygoner, rektanglar, cirklar, lagergrupper etc. Markörer och annan manipulation sker efter den initiala utritningen av kartan och är då som lager ovanpå kartan. Alternativet att lägga in information i markörerna finns, det resulterar i att markörerna ungefär agerar som popups. Verktygets popups gör att kartan räknas som dynamisk då det kan ge en djupare förståelse för kartan om information finns inbakad (Ledur et al. 2015).

Figur 4

Möjligheten till hårdvaruaccelerering med Leaflet finns trots att det inte bygger på WebGL och det är genom attribut (translate3d, transform:translateX) som kom till i CSS3.

Figur 5

Attributen bör användas varsamt då det kan medföra konsekvenser som minnesproblem och krascher (Zakas 2013). Kartverktyget Leaflet.js kan kombineras med datavisualiersingsverktyget D3.js för att skapa en effektiv och interaktiv karta. Lu, Ai, Zhang och He (2017) använder dessa i kombination med web.py för att skapa en air mapping application där Leaflet.js kopplar karttjänst med data. D3.js användes för att rendera kartan.

2.7 D3.js

D3.js är ett JavaScript-bibliotek som kan användas för att skapa datavisualiseringar på webben. D3.js är inte byggt på WebGL utan det utnyttjar HTML, CSS och SVG genom JavaScript.

Figur 6

D3.js är ett ramverk ofta använt för att visualisera data i form av grafer och diagram men också för hantering och manipulering av DOM i webbläsaren. Trots att webbläsare ofta har funktionaliteten att hantera DOM inbyggt så är gränssnittet i dessa krångligt och inte alls intuitivt vilket har resulterat i att JavaScript-bibliotek för att hantera detta har blivit väldigt populära. Ett exempel på detta är jQuery, genom det kan flera element väljas och samtliga element kan ändras på samtidigt. Problemet med jQuery är att det är svårt att skapa samt ta bort element. Där kommer D3.js till användning då detta bibliotek löst problemet på ett bra sätt (Bostock, Ogievetsky and Heer 2011). D3.js var ursprungligen designat för att stödja rendering av interaktiv visualisering där kartor är ett alternativ. D3.js är byggt för att använda HTML, CSS och SVG vilket kan vara problematiskt. Just SVG har tidigare noterats att ha haft problem med laddning, rendering och manipulering på grund av bandbredds- och hårdvaru- begränsningar. Vid problem med hårdvaru-begränsning i webben kan det lösas med hårdvaruaccelerering som tar hjälp av GPU för laddning och rendering (Roth, Donohue, Sack, Wallace & Buckingham 2015).

/* warp speed ahead */

.animClass {

-webkit-transform: translate3d(0, 0, 0);

/* more specific animation properties here */

}

map = {

const svg = d3.create(”svg”)

.attr(”viewBox”, [0, 0, width, height]);

Figur 7

2.8 Hårdvaruaccelerering

Hårdvaruaccelerering var något som togs fram när det upptäcktes att GPUn kunde genomföra vissa processer eller uträkningar som CPUn vanligtvis hanterade. Det upptäcktes att GPUn var snabbare än CPUn och en mer effektiv applikation kunde då utvecklas. CSS-animationer hårdvaru-accelereras vanligtvis på alla ställen det är möjligt, speciellt av mobila enheter som använder iOS och Android 3+. Det skapar en bättre upplevelse i applikationen men kräver mer minne. Utvecklare upptäckte tidigt att animationer presterade bättre när hårdvaruaccelerering utnyttjades och Zakas (2013) berättar att hårdvaruaccelerering på applikationer som egentligen inte krävde animationer började utforskas. CSS använder sig vanligtvis inte av hårdvaruaccelerering men det finns olika sätt att tvinga applikationen till att använda det (Zakas 2013). Zakas (2013) menar också att utvecklare bör använda detta med varsamhet då den kan ha konsekvenser som minnesproblem och ibland krascher. Enligt Qiu och Chen (2018) så har uppkomsten av HTML5 och WebGL gjort det möjligt att skapa WebGIS-applikationer med möjligheten till hårdvaruaccelerering genom WebGL.

Elektroniska dynamiska kartor blir alltså mer och mer kraftfulla med hjälp av hårdvaruaccelerering.

3 Problemformulering

Det kan finnas problem med hårdvaruaccelerering enligt Zakas (2013) som tar upp att det kan orsaka minnesproblem i applikationen, långsam laddning och även krascher. Därför bör utvecklare vara varsamma vid användning av hårdvaruaccelerering och det är också därför en undersökning genomförs om just hårdvaruaccelerering är värt att använda i en dynamisk karttjänst. Studien kommer att gå ut på att mäta laddningstid, utritningstid och bilder per sekund (FPS) i en applikation och resultatet kommer sedan analyseras. I studien har tre JavaScript-bibliotek valts. En kombination av två verktyg, D3.js och Leaflet.js som funnits sedan 2010 respektive 2011 (Edler and Vetter 2019) och ett något äldre verktyg OpenLayers som hade sin initiala release redan 2006 (Roth et al. 2015). Alla kodbibliotek som ingår i studien har varit delaktiga i forskning. Det leder till att samtliga bibliotek kan ses som bra kandidater till just detta arbete. Nguyen, Devaux, Bredif och Paparoditis (2015) har utvecklat en mycket avancerad kartapplikation som presenterar en tredimensionell streetview-liknande vy på en stad med hjälp av WebGL och dess hårdvaruacceleration. Enligt Nguyen et al. (2015) är WebGL ett bra alternativ vid utveckling av tredimensionella GIS-applikationer för navigering och bör då vara ett legitimt val för en mindre avancerad dynamisk kartapplikation.

I en artikel av Wang et al. (2018) presenteras ett resultat där hårdvaruaccelerering framstår som en stor fördel vid rendering av en dynamisk 2D karta. Artefakten i Wangs studie liknar den applikation som skall tas fram i denna studie. Detta innebär att en slutsats kan dras, att OpenLayers då kommer prestera bra eftersom det utnyttjar WebGL som i sin tur utnyttjar hårdvaruaccelerering.

Enligt Alten, Gadre, Kulkarni och Wu (2019) är D3.js ett bra val för applikationer med kartor baserat några aspekter som ansågs vara viktiga. Dessa aspekter var att eftersom D3.js är ett JavaScript-bibliotek så är det portabelt och kompatibelt med majoriteten av moderna enheter men också att det finns många simpla byggstenar så ingen speciell struktur blir påtvingad. Det ger hög flexibilitet. D3.js är också bra på att presentera och hantera interaktiva visualiseringar med data i olika format och från olika källor. Nair, Shetty och Shetty (2016) menar dock att D3.js har problem med att presentera visualiseringar av Big Data. Enligt Ki (2019) så delar GIS flertal aspekter med Big Data medan Szuba et al. (2016) menar att data från satelliter som observerar Jorden faktiskt kan klassas som Big Data. Det leder till intrycket av att D3.js möjligtvis också har problem med stora GIS-visualiseringar. D3.js kommer dock inte utsättas för Big Data i denna studie och det kommer även att kombineras med Leaflet.js och enligt Lu et al. (2017), kompletterar dessa ramverk varandra väl vilket ger intrycket av att det kan resultera i ett acceptabelt resultat.

Den här studien går ut på att se om OpenLayers, som utnyttjar hårdvaruaccelerering, presterar bättre eller sämre i mån av laddningstid, utritningstid och bilder per sekund jämfört med en kombination av biblioteken D3.js och Leaflet.js, som inte utnyttjar hårdvaruaccelerering.

3.1 Hypotes

Nollhypotes: Hårdvaruaccelereringen i OpenLayers påverkar inte laddningstid, utritningstid eller bilder per sekund i en interaktiv dynamisk karttjänst.

Mothypotes: Hårdvaruaccelereringen i OpenLayers påverkar laddningstid, utritningstid eller bilder per sekund i en interaktiv dynamisk karttjänst.

Delhypotes 1: Hårdvaruaccelerering har positiv påverkan på laddningstid, utritningstid eller bilder per sekund

Delhypotes 2: Hårdvaruaccelerering har negativ påverkan på laddningstid, utritningstid eller bilder per sekund

Enligt en undersökning av Roth et al. (2015) så uppfyller både D3.js och Leaflet.js fler kriterier än OpenLayers vilket ger intrycket av att kombinationen mellan D3.js och Leaflet.js resulterar i ett större användningsområde än OpenLayers. Eftersom Roth et al. (2015) undersöker biblioteken som ingår i denna studie på ett utförligt sätt, där många av deras attribut och brister tas upp, framgår det att biblioteken inte uppfyller samma kriterier och risken för skillnad i prestanda på grund av något annat än just hårdvaruaccelereringen finns.

Båda implementationer bygger på en server-sida byggd med Node.js vilket för detta ändamål kan påverka laddningstider. Anledningen till påverkan ligger i grunden för hur Node.js är byggt och till vilken typ av applikation Node.js fungerar bäst. Enligt Chitra och Satapathy (2017) fungerar Node.js bättre för I/O-intensiva applikationer och som tidigare nämnt så är GIS-applikationer ofta CPU-intensiva. Problemet som uppstår här är att man vill genom hårdvaruaccelerering förbättra laddningstider, utritningstid och FPS. Hårdvaruaccelerering är till för att avlasta CPU:n och utnyttja GPU:n som oftast är snabbare på uträkningar och animationer. Hur Node.js hanterar hårdvaruaccelerering är något som kommer upptäckas och noteras i studien. Risken för att Node.js eliminerar fördelen med hårdvaruaccelerering på grund av sin bristfälliga kompatibilitet med CPU-intensiva applikationer innebär att behovet av att utvärdera applikationen med en annan server-sida än Node.js kan uppstå om resultatet från pilotstudien är otillräckligt.

4 Metod

Studien i denna rapport baseras på två olika implementationer av en applikation. Poängen med studien är att ta reda på om hårdvaruaccelerering påverkar laddningstid, utritningstid och bilder per sekund (FPS) vid animering av en dynamisk karta. Applikationens två implementationer är består av kodbibliotek där en implementation använder hårdvaruaccelerering och den andra implementationen utnyttjar inte hårdvaruaccelerering.

Implementationerna som studien innefattar är en kombination av D3.js och Leaflet.js, som inte utnyttjar hårdvaruaccelerering och den andra implementationen är OpenLayers som utnyttjar hårdvaruaccelerering genom WebGL. Undersökningen som kommer att genomföras i denna studie går ut på att avgöra om hårdvaruaccelerering påverkar laddningstid, utritningstid och bilder per sekund vid animation av 2D-grafik. I detta fall skall grafiken ta form av en applikation som visar en dynamisk karta på webben. Eftersom två olika implementationer av en applikation ingår i studien, innebär det att applikationen skall byggas med olika verktyg och studien är då teknologi-orienterad (Wohlin et al. 2012).

4.1 Alternativa metoder

Wohlin et al. (2012) tar upp tre olika grundmetoder att genomföra empiriska studier. Dessa grundmetoder är enkät, fallstudie och experiment. Wohlin pratar också om vad forskare bör tänka på vid val av metod till en studie. En enkät är ett system för att ta reda på information om människor eller vad testpersoner tycker och tänker kring ett visst område. Denna typ av metod kan också kallas användarstudie, genomförs ofta i efterhand och samlar in både kvalitativ och kvantitativ data. Roth et al. (2015) genomförde en användarstudie där människor fick använda sig av biblioteken som ingår i denna studie, D3.js, Leaflet.js och OpenLayers. Ett resultat presenterades sedan av den data som samlats in. Baserat på det resultatet kunde en slutsats dras, enkät/användarstudie är inte en metod som passar in för att få ett bra resultat på det som undersöks i denna studie.

Fallstudier inom software engineering är en metod som överser en process under tiden den är aktiv, alltså en observationsstudie. Fallstudier bör oftast genomföras på verktyg i sin naturliga befintlighet för att få ett så verkligt och trovärdigt resultat som möjligt. Metoden skulle kunna tillämpats på denna studie eftersom genom en fallstudie skulle kunna avgöra vilken av implementationerna som är mest lämpad för applikationen. Anledningen till att fallstudie inte valdes är att en brist på kontroll över faktorer uppstår. Enligt Wohlin et al. (2012) är det viktigt att uppnå maximal kontroll över faktorer när variabler som laddningstid, utritningstid och FPS ska mätas. Detta är för att säkerställa ett tillförlitligt resultat och därför är experiment i detta fall, ett bättre val än fallstudie.

Wang et al. (2018) genomförde undersökningar där olika lösningar på deras problem jämfördes på deras prestanda(laddningstid) och resultaten presenterades tydligt i form av grafer och diagram. Resultatet Wang et al. (2018) fick kan liknas med det resultat som söks i denna studie och det talar för att den vetenskapliga metoden experiment är det som bör användas. Som tidigare nämnts genomförde Roth et al. (2015) en användarstudie men också ett experiment på D3.js, Leaflet.js och OpenLayers. I användarstudien fick man resultatet av vad användare av biblioteken tycker och tänker om det. I experimentet tog man fram vad som

var möjligt med biblioteken rent tekniskt och vad som skiljer dem åt. Den undersökningens resultat faller inte inom ramen av vad som är lämpligt och söks i denna studie.

4.2 Experimentupplägg

Eftersom studien innefattar att två implementationer av en applikation där prestanda mäts och sedan jämförs så vill kontroll över faktorer uppnås och då är empiriskt experiment ett relevant val (Wang et al. 2018). Det empiriska experimentet i denna studie är på prestanda och kommer notera laddningstid, utritningstid samt bilder per sekund (FPS). Ett problem med experiment kan vara att samla in tillräckligt med mätpunkter men på grund av den kontroll som experiment medför så ses det ändå som den mest relevanta metoden (Wohlin et al. 2012). Wang et al. (2018) menar att resultatet av experimentet som genomfördes tillät dem att dra slutsatser om vilka lösningar som är bäst i områdena som utvärderades. Detta är ett mål som denna studie också har och empiriskt experiment kommer därmed att genomföras.

4.3 Etik

Studien genomförs med hjälp av två JavaScript-bibliotek som är open-source vilket innebär att vem som helst har öppen tillgång till innehållet i biblioteket och får använda det med väldigt få strikta regler. Biblioteken som används ligger under BSD-licenser. Leaflet.js och OpenLayers under en 2-klausullicens och D3.js under en 3-klausullicens. 2-klausul innebär att en copyright-notis måste ges vid omdistribuering av kod men annars får biblioteket modifieras och användas fritt. 3-klausul innebär att skaparen av bibliotekets namn inte får inte får användas i kommersiellt bruk utan skriftligt samtycke, annars är det samma regler som 2-klausul (Roth et al. 2015). Licenser är något som kan vara viktigt att tänka på när verktyg som bibliotek väljs till sin utveckling och forskning.

Trovärdigheten hos studien kommer stärkas genom att samla tillräckligt många mätpunkter.

Om inte har tillräckligt många mätpunkter samlas in kan det bli svårt att urskilja eventuella mönster i datan. Därför bör forskare vara noga med att samla tillräckligt med data för att förbättra trovärdighet och den framtida analys som ska ske på resultatet (Wohlin et al. 2012).

Experimentet kommer att utföras i sluten miljö där endast personen som gör experimentet kan påverka resultatet. Koden till artefakten och mätverktyget kommer att läggas upp på Github för möjligheten att replikera experimentet.

5 Genomförande

I denna studie skall två olika implementationer av en applikation skapas där prestanda i form av laddningstid, utritningstid och FPS skall mätas. Implementationerna som mäts är OpenLayers som utnyttjar hårdvaruaccelerering och en kombination av Leaflet.js och D3.js som inte utnyttjar hårdvaruaccelerering. Applikationen ska visa världskartan med ett lager ovanpå som utger var landsgränserna är. Kartan ska vara interaktiv och dynamisk som ger användaren möjlighet att påverka sin vy men även att få ut mer information om kartan än vad som initialt presenteras. Interaktiviteten skall vara i form av ett lager som kan klickas på för att markera och få ut mer information men också ge användaren respons i form av en hover- funktion. Användaren ska också kunna panorera, zooma och hämta information om land vid klick. Den dynamiska aspekten skall vara att lagret förändras beroende på vad användaren gör, exempelvis dubbelklicka på ett land för att får ett lager som representerade stadsdelar för just det landet.

5.1 Litteraturstudie

För att hitta kunskap och inspiration om artefakten studerades webben väl efter möjliga hjälpmedel. Lösningar till problem som uppstod under arbetets gång letades efter på ställen som StackOverflow, dokumentation för ramverket som problemet uppstod i men också på YouTube och diverse blogg-poster. Vid en färdig artefakt så hade huvudsakligen dokumentationen använts men även en YouTube-tutorial som hjälpte till med applikationens grund. StackOverflow hade många bra inlägg som hjälpte till för förståelse av dessa ramverk men just i denna studie då svaren kunde många av svaren hittas i dokumentationen.

För att skapa grunden till webbapplikationen användes Node.js egna dokumentation, exempel (Node.js 2020) och YouTube (YouTube 2016). Dokumentationen gav en bra start och förståelse för applikationens struktur medan YouTube verkligen hjälpte att se poängen med alla steg och i vilken ordning man skulle ta dem. Den grunden som Node.js utgjorde är server- sidan av applikationen. Det var viktigt att båda varianter av applikationen kunde gå genom samma server och Node.js hade bra stöd för just det.

Eftersom D3.js och Leaflet.js skulle kombineras i studien så var sökningar på exempel som innefattade båda ramverken mycket viktiga. Detta för att förstå hur ramverken kompletterar varandra och hur man kan kombinera dem på bästa sätt. Bostock (2015) har en specifik guide (D3 + Leaflet) som var väldigt hjälpsam under utveckling av artefakten men också många andra exempel som visade sig vara användbara för att få bredare förståelse för D3.js. I kombination med ett inlägg på StackOverflow (StackOverflow 2013) så kunde applikationens lager, skrivet i D3.js, göras klart. Leaflet.js hade en bra dokumentation med många exempel som kunde tillämpas till applikationen vilket resulterade i en bra inlärningskurva.

För att komma igång med OpenLayers så var exempel-tillämpningar (OpenLayers 2020) i deras dokumentation mycket hjälpfulla medan deras API-dokumentation inte hjälpte speciellt mycket. API-n var någorlunda svår att förstå och information som var sällan lätt att implementera. API-n hjälpte dock till att förstå saker som var otydliga i exempel som OpenLayers erbjöd.

Att läsa böcker för information angående webbtekniker eller ramverk för olika utvecklingsspråk kan vara problematiskt då risken att boken är utdaterade är relativt hög jämfört med en hemsida. En hemsida kan givetvis också vara utdaterad men möjligheten att uppdatera hemsidan finns, det går inte med en bok. En ytterligare anledning till att man bör vara uppmärksam är för att det ofta kommer nya versioner av dessa tekniker och ramverk eftersom utveckling oftast sker kontinuerligt. Ett exempel på detta är ”kokboken” för OpenLayers av Perez och Langley (2016). Den innehåller flertal exempel på hur kartapplikationer kan skapas i OpenLayers 3.x och när denna studie skrivs så är OpenLayers på version 6.3.1. En utvecklare kan då inte utgå ifrån att exempel som finns i boken fortfarande fungerar eftersom funktionalitet och struktur i ramverket kan ha ändrats. Samtidigt som utvecklare bör vara försiktiga till användandet av böcker i sina projekt, just på grund av risken att exempel och dokumentation kan vara utdaterade, så finns det böcker som är såpass generella att informationen fortfarande är aktuell.

5.2 Progression

Progressionen kommer innehålla saker som gått fel eller problem som stötts på under utvecklingen av artefakten. Artefakten i denna studie skulle vara en dynamisk karta med ett interaktivt lager. Den dynamiska aspekten lyckades inte att genomföra då data som innefattande information om ett lands stadsdelar inte kunde hittas. Därför innehåller progression och implementation endast kartan och dess initiala interaktiva lager.

5.2.1 Leaflet.js + D3.js

Ursprungligen vid design av lagret i Leaflet+D3-applikationen upptäcktes det att hover- effekten inte fungerade som tänkt och det upptäcktes då att Leaflet.js lägger en css-attribut på samtliga ”path”s. Pointer-events: none låg som ett attribut på ”path” i Leaflet’s css fil och den gör så att lagret inte ska förhindra användaren från att interagera med kartan som hamnar bakom. I figur 8 och commit 7990d83¹ visas det att attributet tvingas på elementen genom !important då hover-effekt skulle uppnås.

En utmaning som uppstod vid zoom var att få SVG-lagret att skala ordentligt. Om detta inte görs rätt så blir lagret helt fel storlek vid utzoomning och inzoomning. Exempel på detta kan ses i figur 8.

1 https://github.com/a17ludca/xjobb-a17ludca-OL/commit/7990d83

Figur 8 Exempel på felhantering vid zoom

För att lösa detta problem så kallades en ”reset”-funktion som skalade lagret enligt kartan.

Funktionen kallades på vid zoom för att försäkra om att lagret skulle skala ordentligt när användaren zoomade. Koden för denna funktion kan ses i figur 18 men också i commit 3735b14² där problemet löstes genom att lägga koden som skalar lagret till kartan i en ”reset”- funktionen som körs initialt vid laddning och sedan via zoom.

Ursprungligen så skulle kartan visa landets namn vid muspekaren när användaren höll muspekaren på landet. Tidigt i utvecklingen så upptäcktes det att detta var svårt och ingen stabil version med fungerande funktionalitet nåddes. I commit e888fd0³ togs detta bort och istället lades ett textfält till som uppdateras vid klick på ett land.

5.2.2 OpenLayers

Vid utvecklingen med OpenLayers upptäcktes problem med inkludering av inbyggd funktionalitet, exempelvis ol.Map, i guider och dokumentation står det går att ”installera”

ramverket och sedan inkludera delarna av ramverket som behövs i toppen av dokumentet. Det skulle resultera i att koden istället skulle säga new Map. Det visade sig inte fungera utan det hade istället sönder applikationen. Detta löstes genom att inkludera bibliotekets länk i html- filen och sedan använda filstrukturen för att utnyttja kodbasen, exempelvis new ol.layer.Tile istället för det som skulle varit new Tilelayer. Hur strukturen ser ut går att hitta i OpenLayer’s dokumentation.

När användaren klickar någonstans på kartan så kallas funktionen i figur 26. Om hen sedan faktiskt klickar på ett element/land eller som i funktionen, feature, så kommer värdet på textfältet att sättas till värdet av ”ADMIN” hos det elementet. ADMIN i geojson-filen är landets namn och kommer då visas i textfältet. Hur information hämtades från geojson i OpenLayers var inte helt tydligt utan det tog ett tag att få rätt information. Guiden som användes till feedback av muspekarens position var till stor hjälp. Utifrån den och lite egen kunskap så kunde problemet lösas ganska fort och på ett bra sätt. Att klicka på ett land ska också göra det landet till fokus och fylla färgen till helt blå. Problemet som stöttes på då vara

2 https://github.com/a17ludca/xjobb-a17ludca-OL/commit/3735b14

3 https://github.com/a17ludca/xjobb-a17ludca-OL/commit/e888fd0

att hela kartan uppdaterade när användaren rörde muspekaren. Alltså var landet blått under tiden användaren inte rörde muspekaren efter klicket, men direkt efter rörelse även inom det klickade landet så uppdaterades landets färg. När en användare klickat på ett land så

förstördes även funktionen att ”hovra”. I figur 27 visas det hur applikationen kunde se ut efter användaren hade klickat en gång på ett land.

Figur 9 Problem vid klick i OpenLayers

I commit 9fd59e3 ⁴ löstes problemet i figur 9 men fokusfunktionen kvarstod. Att fokusfunktionen inte fungerade innebar att landet inte bibehöll det klickade tillståndet efter att användaren flyttat på muspekaren.

5.3 Applikationen

Arbetet började med implementationen som byggde på kombinationen mellan Leaflet.js och D3.js. Det fanns en tydlig guide på hur ramverken kompletterade varandra och därför kunde en grundapplikation skapas mycket fort. Ett problem uppstod senare när grunden skulle sättas för applikationen med OpenLayers, det upptäcktes snabbt att applikationen fungerade som bäst när strukturen sattes upp med hjälp av Node.js och dess server-sida. Det beslutades då att göra om Leaflet.js + D3.js-applikationen och i den nya versionen utnyttja Node.js även där.

Detta för att utsätta implementationerna för så lika förutsättningar som möjligt. Server-sidan skapades då i Node.js och i utvecklingen så utnyttjades Node.js-ramverket Express för att på ett smidigt sätt kunna skilja på applikationerna bara genom URL. Figur 10 visar ett exempel på hur Express förenklade server-sidan.

Figur 10 Grund för server-sida

4 https://github.com/a17ludca/xjobb-a17ludca-OL/commit/9fd59e3 var express = require('express');

var router = express.Router();

/* OL home page. */

router.get('/OL', function(req, res, next) {

res.render('indexOL', { title: 'Map with OpenLayers' });

});

I router.get() så ligger en del ’/OL’ som berättar att när URL:en visar /OL på slutet så hämtar den filen ”indexOL”. Detta gjordes på samma sätt för Leaflet.js och D3.js där ”OL”

byttes ut mot något som representerade Leaflet och D3. Detta upplägg ger en och samma server-sida för båda implementationer men samtidigt så delas dem upp helt.

5.3.1 Leaflet.js + D3.js

När en grund fanns för båda applikationer så lades ett lager till där ett lands yta blir upplyst till en blå färg när användaren drar muspekaren över det landet. Detta var en okomplicerad lösning i L3-applikationen där Leaflet.js användes för kartan D3.js för lagret över kartan. I figur 11 visas det hur D3.js utnyttjas för att lägga till ett SVG-element i Leaflet.js’s ”overlay pane”. Detta är för att kunna gruppera alla element med ”g”-taggen. Samtliga element i gruppen får klassen ”leaflet-zoom-hide” och det är för att gömma lagret vid zoom. Utan det så skalar inte kartan bakom parallellt med lagret över.

Figur 11 SVG- och g-element för L3-applikation

Eftersom D3.js och Leaflet.js använder olika API’s för att rendera figurer och koordinater. Om lagret skapat med D3.js ska passa och skala korrekt på Leaflet.js-kartan så måste punkterna göras om till D3.js version. I figur 12 kan man se hur funktionen ”projectPoint” tar in Leaflets x och y och sedan speglar det så D3-lagret ska passa.

Figur 12 Justerar projektion så att D3 matchar Leaflet

Att översätta punkterna till rätt system är mycket viktigt för att lagret som läggs ovanpå kartan ska matcha med kartan bakom. Om detta inte görs korrekt eller alls så kan resultatet bli som i figur 13.

Figur 13 Fel projektion

var svg = d3.select(l3map.getPanes().overlayPane).append("svg"), g = svg.append("g").attr("class", "leaflet-zoom-hide");

function projectPoint(x, y) {

var point = l3map.latLngToLayerPoint(new L.LatLng(y, x));

this.stream.point(point.x, point.y);

}

I figur 14 kallar D3.js på projectPoint för att får korrekt projektion. Först gör man om punkterna till D3’s system och sedan applicerar man det på det som ska bli ”path”-objekten.

Figur 14 Verkställer projektion på D3

När en geojson-fil ska hämtas så användes D3.js för att lägga i filens innehåll i ett objekt som kan kallas collection (se figur 15). Från variabeln collection så kan information som landsnamn och koordinater hämtas. För att följa struktur så gjordes URL:en om till en variabel.

Figur 15 Hämtar geojson

För att sedan skapa lagret som ska matcha kartan och för att kunna skilja på alla länders gränser så hämtas koordinaterna i collection.features och läggs sedan till på varje

”path”-objekt som i sin tur då kommer representera länderna (se figur 16).

Figur 16 Lägger till en ”path” på varje land

Detta resulterar i att alla länder på kartan har en unik ”path” över sig. Då kan ”path” designas i sin CSS-fil som bestämmer hur lagret ska se ut. I CSS-filen som visas i figur 17, läggs en hover- effekt till vilket ger feedback på vart användaren har muspekaren.

Figur 17 Exempel på design av ”path”

I figur 18 visas koden som körs för att lagret skapat i D3 ska skala korrekt vid zoom. Om detta inte görs korrekt så ser det ut som i figur 8.

path {

fill: #000;

fill-opacity: .2;

stroke: #fff;

stroke-width: 1px;

pointer-events: auto !important;

}

path:hover { fill: blue;

fill-opacity: .6;

}

var transform = d3.geo.transform({point: projectPoint}), path = d3.geo.path().projection(transform);

var overlay = "data/countries.geojson”;

d3.json(overlay, function(collection) {

var feature = g.selectAll("path") .data(collection.features) .enter().append("path")

.on("click", function(b){clicked.call(this); findCountry(b);});

Figur 18 Skala SVG med zoom

Koden ovan resulterar i att SVG-elementets höjd och bredd uppdateras när just denna koden körs. För att koden skulle köras varje gång användaren zoomade så var det nödvändigt att lägga den i en funktion. I figur 19 visas det hur applikationen kallar på funktionen, som gavs namnet reset, för att försäkra sig om att SVG-elementet har skalats rätt. Ett funktionsanrop till reset gjordes vid zoom i ”l3map”-elementet vilket är kartan som är skapad med Leaflet.

Figur 19 Funktionsanrop som skalar SVG vid zoom

För att ge lite interaktivitet till applikationen så lades en funktion till som körs vid klick på land. När användaren klickar på ett land så fylls landet i med en blå färg och namnet på landet hämtas och visas i botten av skärmen. I figur 16 visas koden som lägger till ett klick-event på varje ”path”.

Figur 20 Funktion för klick på land

När en användare klickar på ett land så anropas funktionen clicked. Figur 20 visar att koden utnyttjar D3’s select och väljer elementet med klassen clicked, om det finns något, och tar sedan bort klassen från elementet. D3’s select väljer sedan ”this” vilket är elementet som användaren har klickat på, vad ”this” är passeras från funktionsanropet i figur 16. Vid klicket anropas även funktionen findCountry vilket är ett anrop som skickar med landets namn.

var bounds = path.bounds(collection), topLeft = bounds[0], bottomRight = bounds[1];

svg .attr("width", bottomRight[0] - topLeft[0]) .attr("height", bottomRight[1] - topLeft[1]) .style("left", topLeft[0] + "px")

.style("top", topLeft[1] + "px");

svg.selectAll("g")

attr("transform", "translate(" + -topLeft[0] + "," + - topLeft[1] + ")")

feature.attr("d", path);

l3map.on("zoom", reset);

reset();

function clicked(){

d3.select('.clicked').classed('clicked', false);

d3.select(this).classed('clicked', true);

}

När användaren klickar så kommer fältet i botten fyllas med namnet på landet som klickats på. Hur detta fungerar kan ses i figur 21.

Figur 21 Sätter fältets värde till landsnamn 5.3.2 OpenLayers

För att skapa en jämförbar implementation i OpenLayers så börjades det med att skapa kartan och välja elementet som kartan ska ligga i. Kartan hämtas från OpenStreetMap vilket finns som en fuunktion inbyggt i OpenLayers. För att sedan välja vyn som kartan ska starta på så anges en ny vy med koordinater och zoom-nivå.

Figur 22 Karta i OpenLayers

För att skapa lagret som hämtades i figur 22 vid namn vectorLayer så gjordes en variabel som skulle hålla informationen om lagret och stilen på lagret.

Figur 23 Vektorlager på karta

Lagret som läggs på kartan och som hämtar datan från en ”source” och stilen från en ”style”, hur källan och stilen skapas visas i figur 24 och 25.

const olmap = new ol.Map({

target: 'olMap', layers: [

new ol.layer.Tile({

source: new ol.source.OSM() }),

vectorLayer ],

view: new ol.View({

center: [37.8, -96.9], zoom: 4

}) });

var vectorLayer = new ol.layer.Vector({

source: vectorSource, style: styles

});

var vectorSource = new ol.source.Vector({

url: 'data/countries.geojson', format: new ol.format.GeoJSON() });

function findCountry(b){

term = b.properties.ADMIN;

var search = document.getElementById("search");

search.value = term;

}

Figur 24 Källan till lagret över kartan

I figur 24 visas det hur det går till för att hämta datan som i sin tur ska bli lagret över alla länder. I denna studie hämtas datan från en geojson-fil och formateras sedan för att kunna tolkas av vektorlagret.

Figur 25 Stilen på varje del i lagret

Att skapa en stil i OpenLayers var mycket enkelt och ger möjligheten till många olika designval. För just detta lager så var stroke och fill det som behövdes för att efterlikna den andra variationen av applikationen, vilket kan ses i figur 25. En utmaning som stöttes på var när hover-effekten skulle efterliknas. Effekten var inte alls lika okomplicerad som i D3 och Leaflet. För att lösa problemet så utnyttjades en guide i OpenLayers dokumentation som visade hur biblioteket hanterade muspekarens position. I figur 26 visas det hur muspekarens position kopplas till kartan och hur applikationen anropar en funktion vid varje rörelse på elementet som valts, i detta fall kartan.

Figur 26 Hover-effekt i OpenLayers

Koden i figur 17 resulterar i den vanliga stilen på ett element när muspekaren inte är över det men byter till ”highlightStyles” när muspekaren nuddar elementet. ”HighlightStyles” är ett ekvivalent stil-objekt som visas i figur 25 men eftersom applikationen byter till den stilen när muspekaren är över ett element så bör stilen ändras lite. Detta är för att ge användaren feedback om vart muspekaren är i applikationen. Applikationen skulle också ge användaren information om vilket land hen klickat på genom att fylla ett textfält i botten av skärmen

var styles = new ol.style.Style({

stroke: new ol.style.Stroke({

color: 'white', width: 1 }),

fill: new ol.style.Fill({

color: 'rgba(0,0,0,0.2)' })

});

olmap.on('pointermove', function(e){

if (selected !== null) { selected.setStyle(styles);

selected = null;

}

olmap.forEachFeatureAtPixel(e.pixel, function(f){

selected = f;

f.setStyle(highlightStyles);

return true;

});

});

med landets namn. I figur 27 visas det hur funktionen som hämtade namnet och som angav det i textfältet såg ut.

Figur 27 Hämta landsnamn vid klick

Koden som exekveras vid klick ses i figur 28. Koden resulterar i att ett land som klickas på blir ifyllt med en blå färg tills användaren rör på muspekaren. Tanken är att landet ska vara ifyllt tills användaren klickar på samma land igen eller på ett annat land.

Figur 28 Klick på land i OpenLayers 5.3.3 Mätning av laddningstider och FPS

För att påbörja en pilotstudie så krävdes det att applikationen skulle att kunna mätas på. Det fanns sätt att mäta FPS på genom ramverket stats.js(länk) men att implementera det och mäta kunde inte göras utan att äventyra strukturen i applikationen. Därför valdes FPS-mätning bort i pilotstudien då ingen bra lösning upptäcktes utan att lägga till signifikant mängd kod. Vid mätning av laddningstider så stöttes flertal problem på, som att inte starta mätningen på rätt ställe till att mätningen skedde oavbrutet vilket båda resulterar i opålitlig data. För att mäta laddningstid i OpenLayers så skapades funktioner som mätte efter en omladdning och efter en in/ut-zoomning. Att starta mätningen vid rätt tillfälle i OpenLayers var inte självklart när det kom till att zooma. I commit 6993838⁵ och figur 29 visas ett exempel på mätning som inte fungerade. Detta var för att OpenLayers kallar på rendercomplete varje gång en tile laddar klart om man använder sig av ”on”.

5 https://github.com/a17ludca/xjobb-a17ludca-OL/commit/6993838 var getCountryname = function(pixel){

var feature = olmap.forEachFeatureAtPixel(pixel, function(feature){

return feature;

});

var search = document.getElementById("search");

if(feature){

search.value = feature.values_.ADMIN;

} };

olmap.on('click', function(e){

getCountryname(e.pixel);

if (featureClicked !== null) {

featureClicked.setStyle(undefined);

featureClicked = null;

}

olmap.forEachFeatureAtPixel(e.pixel, function(f){

featureClicked = f;

f.setStyle(clickedStyles);

return true;

});

});

Figur 29 Exempel på mätning av laddningstid

En lösning på detta var att kalla på rendercomplete ”once” som istället kör när hela kartan laddat klart. Lösningen som visas i figur 30 fungerar på det sätt att mätningen startas när kartan på något sätt rör på sig och sedan när rörelsen är klar så kallas funktionen som

”stoppar” timern. Funktionen som stoppar timern har en extra kontroll i sig som exekverar efter att kartan har renderat färdigt.

Figur 30 Fungerande mätning av utritningstid vid zoom 5.3.4 Mätscript

Att genomföra mätningarna var inte problemfritt då ett försök att automatisera dem gjordes.

Med hård reload av sidan var det svårt att få mätscriptet att fortsätta köra efter att sidan hade uppdaterats. I pilotstudien valdes detta då att göras för hand och det är också därför antalet mätningar inte är så högt. För att simulera ett klick på zoom-knapparna så användes en start- knapp för att sätta igång scriptet och sedan användes document.querySelector för att markera knappens klass. Klicket på zoom-knapparna var en funktion som skulle kallas på tills kartan hade zoomat ut helt eller zoomat in helt. För att repetera funktionsanropet så användes setInterval, en inbyggd funktion i JavaScript som kallar på funktionen med ett angivet antal millisekunder i mellan. I figur 28 visas det hur den delen av scriptet såg ut.

olmap.on("rendercomplete", function(){

var newTime = performance.now();

var loadTime = newTime-startTime;

console.log("Loadtime: " + loadTime + " ms");

startTime = performance.now();

})

olmap.on('movestart', function(){

startTimeZoom = performance.now();

});

olmap.on('moveend', function(){

measureZoom();

});

function measureZoom() {

olmap.once('rendercomplete', function(){

newTime = performance.now();

var zoomLoad = newTime - startTimeZoom;

var temp = zoomLoad.toFixed(2);

loadtimeArr.push(temp);

localStorage.setItem('Refresh Loadtimes', JSON.stringify(loadtimeArr));

console.log("Refresh loadtime: " + JSON.stringify(loadtimeArr));

});

}

Figur 31 Script för att simulera klick

För att sedan skicka den data som mätningen resulterat i så användes koden i figur 29.

Resultatet hämtas ifrån localstorage och skickas sedan vidare med funktions-anropet

”ajaxCall”. Efter det så ska localstorage tömmas och för att detta inte ska ske innan funktions- anropet är färdigt så har en timeout lagts till.

Figur 32 Skicka resultat av mätning

Funktionen ”ajaxCall” skickar resultatet till en php-fil som i sin tur skriver in det i en textfil.

Det gör att resultatet blir lätt att hantera och visualisera. När resultatet sedan skrivits in i textfilen överfördes det manuellt till Excel där grafer skapades. Detta för att bättre kunna tolka och förstå resultatet.

Som tidigare nämnt så lades det till funktioner som kontrollerade tillståndet i applikationen.

Exempel på detta i OpenLayers visas i figur 30 där en tidsmarkering sätts efter att kartan har renderat klart helt. Tidsmarkeringen jämförs sedan med en tidigare markering och laddningstiden blir då resultatet.

5.4 Pilotstudie

Pilotstudien bestod av tre olika typer av mätningar på båda implementationerna. Mätningarna var:

• Hård uppdatering av sidan 10 gånger, 5 mätserier x2 – OpenLayers vs Leaflet+D3

• Zoom in helt nivå 0-18 5 gånger – OpenLayers vs Leaflet+D3

• Zoom ut helt nivå 18-0 5 gånger – OpenLayers vs Leaflet+D3

Detta resulterade i att båda implementationer av applikationen genererade 100 datapunkter för hård uppdatering av sidan och 90 datapunkter för zoom in/ut. Hård uppdatering innebar att användaren gick in på sidan med tömt cacheminne och att sidan laddas om med hård inläsnings-alternativet i Google Chrome. För mätning av utritningstid vid zoom så laddades

document.getElementById("start").onclick = function(){

setInterval(zoomClick, 10000);

}

function zoomClick(){

document.querySelector(".ol-zoom-out").click();

}

document.getElementById("send").onclick = function(){

var tempVariable = localStorage.getItem('Refresh Loadtimes');

ajaxCall(tempVariable);

setTimeout(function(){

localStorage.clear();

},500);

}

sidan in helt ut-zoomad eller helt in-zoomad beroende på vad som skulle utvärderas. När sidan sedan hade zoomat in helt eller ut helt så gjordes en hård uppdatering och scriptet började på nytt. I pilotstudien förekom några oförväntade spikar. Anledningen till dessa tros vara internetrelaterade vilket medför ett behov av att ladda ner ramverken lokalt och genomföra experimentet utan internet. Vid uträkning av standardavvikelse upptäcktes det att spikarna förstörde resultatet.

Pilotstudien genomfördes under dessa förhållanden:

• Leaflet.js, version 1.6

• D3.js, version 3.5.17

• OpenLayers, version 6.2.1

• Node.js, version 12.16.1

• Google Chrome, version 83.0.4103.97 (64 bitar)

CPU Intel(R) Core(TM) i7-6700k @ 4.00GHz

GPU NVIDIA GeForce GTX 1080 Ti

RAM 16,0 GB

Internet 95 Mbit/s [2020-04-20]

Operativsystem Windows 10 Pro 64-bitars

Tabell 1 Hårdvaruspecifikation

5.4.1 Resultat av pilotstudie

Som tidigare nämnt så förekom ett fåtal spikar under studien. Det första experimentet som gjordes var det som innefattade laddningstid vid hård inläsning. Grafen i figur 33 visar tydligt att Leaflet+D3 presterar bättre i mån av laddningstid, trots att det saknande hårdvaruaccelerering.

Figur 33 Laddningstid vid hård inläsning (Linjediagram)

Resultatet visar att Leaflet+D3 är snabbare och mer stabilt än OpenLayers vid mätning av laddningstid. Vad detta faktiskt beror på är förhoppningsvis något som upptäcks under det riktiga experimentet.

Figur 34 Laddningstid vid hård inläsning (Stapeldiagram)

Utritningstiden vid zoom var också något som ansågs vara intressant då det är mycket vanligt att användare både zoomar ut och in på en karta. Experimentet är dock inte helt verklighetstroget då det exempelvis är ovanligt för en användare att zooma in helt på en karta, speciellt från ett helt utzoomat tillstånd. Resultatet man får ut från experimentet med zoom är hur lång tid generellt det tar för kartan att ladda in, oavsett nivå. I figur 35 och 36 kan resultatet av undersökningen av zoom in ses. Återigen är OpenLayers långsammare och mer instabilt. Trots detta så är båda variationerna av applikationen mycket ostabila med standardavvikelser på över 300 ms.

0 500 1000 1500 2000 2500 3000 3500 4000 4500

1 10 19 28 37 46 55 64 73 82 91 100

Loadtime(ms)

Leaflet+D3 vs OpenLayers (Laddningstid, hård inläsning + rensning av cache)

Leaflet+D3 OpenLayers

919,82 1936,027 0

500 1000 1500 2000 2500 3000 3500 4000

4500

Medel laddningstid (med standardavvikelse)

Leaflet+D3 OpenLayers

Figur 35 Utritningstid vid zoom in (Linjediagram)

Figur 36 Utritningstid vid zoom in (Stapeldiagram)

Experimentet på utritningstid vid zoom ut gav ett resultat som liknade experimentet för zoom in i stapeldiagrammen eftersom värdena förhåller sig till varandra i samma skala, fast ca 400 ms långsammare i experimentet för zoom ut. Leaflet+D3 hade en mer ostabil utritningstid på att zooma ut medan OpenLayers var mer stabilt. Bortsett från värdet av standardavvikelse hos applikationens olika implementationer så kan OpenLayers konstateras vara mycket ostabilt då det förekom minst en liten spik i varje mätserie.

0 500 1000 1500 2000 2500 3000 3500 4000 4500

1 5 9 1317212529333741454953576165697377818589

Loadtime after zoom(ms)

Leaflet+D3 vs OpenLayers (Utritningstid, Zoom in)

Leaflet+D3(zoomin) OpenLayers(zoomin)

638,39 1160,70 0

500 1000 1500 2000 2500 3000 3500 4000 4500

Medel utritningstid Zoom in (med standardavvikelse)

Leaflet+D3(zoomin) OpenLayers(zoomin)

Figur 37 Utritningstid vid zoom ut (Linjediagram)

Figur 38 Utritningstid vid zoom ut (Stapeldiagram) 5.4.2 Reflektioner om pilotstudien

Eftersom internetrelaterade spikar förekom mer än en gång så kan ett beslut göras om att alla experiment ska göras lokalt. Experimenten ska innehålla en signifikant mängd fler datapunkter för att få ett mer pålitligt resultat. Som tidigare nämnt så gjordes experimentet med hård inläsning manuellt och eftersom ett experiment med fler datapunkter ska genomföras bör detta automatiseras. Resultaten är något motsägelsefulla då hårdvaruaccelerering bör vara snabbare för en kartapplikation. En misstänkt anledning till att detta inte stämmer är server-sidan i Node.js som inte är menad för CPU-intensiva applikationer. Applikationen kan då utsättas för en bottle-neck. Därför kan det vara värt att genomföra experimentet med en annan server-sida för att se om Node.js förhindrar möjligheten för hårdvaruaccelereringen att ha påverkan.

0 500 1000 1500 2000 2500 3000 3500 4000 4500

1 5 9 1317212529333741454953576165697377818589

Loadtime after zoom(ms)

Leaflet+D3 vs OpenLayers (Utritningstid, Zoom ut)

Leaflet+D3(zoomout) OpenLayers(zoomout)

1327,78 1415,70 0

500 1000 1500 2000 2500 3000 3500 4000 4500

Medel utritningstid Zoom ut (med standardavvikelse)

Leaflet+D3(zoomout) OpenLayers(zoomout)

Experimentet som gjordes på zoomningen i applikationen är inte helt korrekt då laddningstiden troddes bero till stor del på mängden detaljer som behöver renderas vid zoom- nivån. Alltså är det mycket sannolikt att laddningstiden är påverkad av kartans projektion, vart användaren zoomar in/ut ifrån. I denna studie kan zoomning göras på ett detaljrikt område och ett område med få detaljer för att se om detta har en signifikant påverkan.