RAMVERK FÖR RENDERING AV HEATMAPS, EN JÄMFÖRANDE STUDIE
Prestandajämförelse för ramverk på webben
FRAMEWORKS FOR RENDERING
HEATMAPS, A COMPARATIVE STUDY
Performance compairson for web based frameworks
Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng
Vårtermin 2020 Max Sjöstedt
Handledare: András Márki Examinator: Henrik Gustafsson
Sammanfattning
Olika typer av data används för att användare skall kunna presentera och dra beslut ifrån data, för att lättare förstå datan tillämpas visualisering som ett sätt att göra datan mer läsbar och lättförstådd. När data skall visualiseras på webben kan många olika teknologier användas för att rendera ut datan. I denna studie kommer ramverk för rendering av heatmaps jämföras sett till deras prestanda i form av renderingstid. De två applikationer som utvecklades var D3.js samt Three.js. Dessa jämfördes sedan i ett experiment där mätningar utfördes på de båda teknologierna. Resultatet blev att Three.js var mer lämpat för visualisering av heatmaps på webben.
Nyckelord: heatmap, performance, D3.js, WebGL, Three.js
Innehåll
1 Introduktion ... 1
2 Bakgrund ... 2
2.1 Visualisera data ... 2
2.1.1 Heatmaps ... 2
2.2 REST API ... 4
2.2.1 Dataset ... 4
2.3 Scalable Vector Graphics ... 4
2.4 WebGL ... 5
2.5 Responstid... 5
3 Problemformulering ... 6
3.1 Hypotes ... 7
4 Metodbeskrivning ... 8
4.1 Etik ... 9
5 Genomförande ... 10
5.1 Litteraturstudie ... 10
5.2 Identifiering av lämpliga ramverk ... 11
5.2.1 Val av ramverk ... 12
5.2.2 Implementation av Three.js ... 13
5.2.3 Implementation av D3.js ... 14
5.3 Progression ... 15
5.3.1 Sidospår angående val av karta ... 15
5.3.2 Hämtning av data från SCB ... 16
5.3.3 Skalning av cirklar på kartan ... 16
5.4 Pilotstudie ... 17
6 Utvärdering ... 19
6.1 Presentation av undersökning ... 19
6.2 Mätningar... 19
6.3 Analys ... 24
6.4 Slutsatser... 24
7 Avslutande diskussion ... 26
7.1 Sammanfattning ... 26
7.2 Diskussion ... 27
7.2.1 Diskussion kring implementation ... 28
7.3 Framtida arbete ... 29
Referenser ... 30
1
1 Introduktion
Nuförtiden samlas data in från många olika källor, detta kan variera från hälsodata, säljdata, miljödata och mängder av annan sorts data. Denna data kan sedan användas för att exempelvis mäta, tolka och registrera mönster. Men datan i sitt råa format är ofta svår att tolka och förstå utan någon form av visualisering (Haara, Pykäläinen, Tolvanen & Kurttila, 2018).
Det finns flera olika typer av visualisering som gör det lättare för användaren att tolka datan, för exempelvis hälsodata eller annan data som har multivariata datapunkter kan heatmaps användas då heatmaps stödjer det djup som denna typ av data har. Heatmaps kan användas för bland annat matriser och kartor där man med hjälp av färgkodning anger de lägsta och högsta värden samt alla datapunkter mellan dessa värden (Sopan, et al. 2012).
När den typen av visualisering skall renderas på webben finns det många olika teknologier i form av ramverk att välja mellan. Det är viktigt att utvecklaren av applikationen väljer det ramverk som är mest användarvänligt för utveckling och presterar bäst för applikationen.
Både för att utvecklingen av applikationen skall vara så effektiv som möjligt samt att användarupplevelsen måste vara god genom snabba laddningstider.
Studiens mål är att undersöka och evaluera ramverk för rendering av heatmaps på webben för att undersöka vilken eller vilka teknologier som lämpar sig bäst sett till renderingstid. För att genomföra detta togs ett antal kriterier fram som ramverken behövde klara för att väljas ut.
När ett antal ramverk hade valts ut för de olika teknikerna undersöktes de för att ta fram två kandidater, en för varje teknik. Sedan utvecklades en webbapplikation som med hjälp av ett dataset renderade ut en heatmap, två versioner av webbapplikationen utvecklades med ett ramverk vardera som stod för renderingen av heatmapen. Sedan genomfördes ett experiment för att ta reda på vilket ramverk som på kortast tid kunde rendera ut heatmapen i webbapplikationen. Ett antal mätningar med olika många datapunkter gjordes för att få med ett så brett användningsområde som möjligt, detta för att se hur ramverken hanterar olika stora datamängder. De mätresultat som togs fram användes sedan för att analysera ramverkens prestanda och hur de stod emot varandra under experimentet. Sedan presenterades ett resultat där det fastställdes hur de båda ramverken skiljde sig åt sett till renderingstid.
2
2 Bakgrund
2.1 Visualisera data
Datavisualisering gör det enklare för användaren att förstå och interagera med den data som tagits fram. Det finns flera olika typer av sätt att visualisera data som gör den användbar inom olika användningsområden. Exempelvis kan en graf vara användbart för att läsa av börsmarknaden medan en tabell kan användas för att sortera produkter i ett lager. Ett annat exempel är heatmaps kan användas till flera olika saker, bland annat för att visualisera geografiska data.
När stora mängder geografiska rådata tolkas, det vill säga data som inte alls är visualiserad kan det vara svårt att tolka och förstå innebörden av den data som presenteras. (Haara, Pykäläinen, Tolvanen & Kurttila, 2018). Detta beror bland annat på den stora variationen när det kommer till just geografiska data. Anledningen till detta är att varje datapunkt ofta har flertalet värden vilket ofta leder till svår tolkning. Det kan till exempel vara svårt att uppskatta både position och höjd på en kulle genom endast rådata.
Multivariat kan visualiseras med heatmaps effektivt. Detta då heatmaps kan hantera de djup som geografiska datapunkter ofta har, då den data som presenteras inte endast har en koordinat på kartan utan även ett värde. Detta underlättar för användare och gör det enklare för beslutsfattare som eventuellt inte har kunskapen att tyda data som inte är visualiserad att tolka och få ett gott underlag inför beslut (Sopan, Noh, Karol, Rosenfeld, Lee & Shneiderman, 2012).
2.1.1 Heatmaps
Genom att tillämpa en färgskala på de värden som skall visualiseras får användaren en bra överblick då man visuellt ser skillnad på de minsta och största värdena. Heatmaps är en typ av visualisering som används över exempelvis en matris eller en karta.
Det finns många olika typer av heatmaps som kan tillämpas beroende på användningsområde och vilken typ av data som används. En matris som Figur 1 kan exempelvis användas när man vill att användaren skall kunna tolka flera rader eller kolumner samtidigt istället för individuellt. (Metsalu & Vilo, 2015).
3
Figur 1 Heatmaps i en matris (Metsalu, Vilo, 2015)
Heatmaps kan även användas till att mäta hur en människa ser på exempelvis en skärm genom ögonspårning som visas på Figur 2. Detta kan användas för att förstå vart och hur människor ser på exempelvis ett program, en bild eller en webbsida. (Georges, Courtemanche, Senecal, Baccino, Fredette & Leger, 2016).
Figur 2 Heatmaps över en webbsida Georges et al, 2016).
Visualisering på en karta som den i Figur 3 möjliggör för användaren att enkelt få en överblick hur värdena skiljer sig över ett geografiskt område (Eichinski & Roe, 2014). Ett vardagsexempel på tillämpningen av heatmaps är den väderdata som exempelvis nyhetsredaktioner publicerar.
Heatmaps är lämpligt att använda då de tillåter användaren av applikationen att visa både den geografiska distributionen samt den multivariat som finns. Multivariat innebär att en datapunkt kan på en karta som exempel ha en longitud och en latitud för att definiera dess position men även ett djup i form av den färg som representerar ett värde. Att använda heatmaps för att visualisera data kan underlätta för beslutsfattare, journalister och akademiska personer. Detta genom att tillhandahålla djup insikt i datasetet (Sopan, et al.
2012).
Figur 3 Heatmaps över en karta (OpenStreetMaps)
4
2.2 REST API
REST eller representational state transfer är en arkitektur för att kommunicera med en webservice. Detta görs med hjälp av set av metoder som utför olika operationer, (Mark Massé 2012) nämner att ett webb baserat API är ansiktet utåt för en webbservice som lyssnar efter en förfrågan och förser webbapplikationen med ett svar i form av exempelvis
information. Detta görs med hjälp av en HTTP request. En HTTP förfrågan måste inkludera antingen GET, PUT, POST eller DELETE. Man nämner även att GET är standardmetoden för att hämta data (Wang, Keivanloo & Zou ,2014).
2.2.1 Dataset
Det dataset som användes från Statistiska centralbyrån hämtas med hjälp utav en POST förfrågan till en specifik URL. Denna består av en JSON förfrågan som specificerar de värden som skall hämtas. Ett exempel på hur denna kod kan se ut finns i Figur 4.
Figur 4 Exempel på en JSON förfrågan
Datan som hämtas kan vara multidimensionell, alltså multivariat och ha värden i flera dimensioner. Exempelvis kan en datapunkt vara antalet män som dött under ett specifikt årtal i Skaraborg. Då finns det alltså en specifik plats där värdet placeras samt ett värde som ger datapunkten dess färg på kartan form av antalet dödsfall sätt till det högsta och lägsta värdet under det årtalet.
2.3 Scalable Vector Graphics
Scalable vector graphics eller SVG är en standard för att hantera vektorgrafik. Formatet är XML baserat och innehåller information som objekt genom koordinatsystem, färger och transformationer. Det är möjligt att skala grafiken mindre eller större tack vare användningen av transformationer, detta innebär att man inte förlorar någon kvalité vektorgrafik inte är pixelbaserad (Neumann & Winter, 2001). Eftersom SVG är en standard stödjer alla moderna webbläsare språket till en viss del och kan rendera grafiken utan tillägg.
5
2.4 WebGL
WebGL är ett JavaScript API som gör det möjligt för webbläsaren att utnyttja datorns hårdvara vid rendering av scener i båda 2D och 3D (Lavouér, Chevalier & Dupont, 2013).
Utvecklare kan då skapa mer resurskrävande mjukvara på ett sätt som tidigare varigt begränsat på grund av att datorns processor inte kunnat driva applikationen och således har prestandan fått lida. Genom att använda WebGL kan man nyttja datorns grafikkort vilket möjliggör en mätbar skillnad på prestandan (Resch, Wohlfahrt & Wosniok 2014). Det krävs inga tillägg för att använda sig utav WebGL utöver en webbläsare som stödjer HTML5 vilket är en stor fördel och man kräver inte heller någon licens för att nyttja WebGL.
Three.js är ett exempel på ett ramverk som använder sig av WebGL, kodexemplet i figur 5 visar hur det exempelvis kan se ut. Det kan användas för att bland annat skapa modeller i en 3D rymd men även 2D scener är tillgängliga. Ramverket är mycket väl dokumenterat och har många aktiva användare.
var geometry = new THREE.BoxGeometry( 1, 1, 1 );
var material = new THREE.MeshBasicMaterial( {color: 0x00ff00} );
var cube = new THREE.Mesh( geometry, material );
scene.add( cube );
Figur 5 Kodexempel för att skapa en kub i three.js
2.5 Responstid
För att göra användarupplevelsen så positiv som möjligt är responstiden kritisk (Kohavi, Deng, Longbotham & Xu, 2014). Responstid beskriver hur fort en webbsida hämtas. Denna faktor är direkt kopplad till hur en webbsida upplevs ur ett användbarhetsperspektiv. Om en webbsida upplevs som seg och icke responsiv försämrar det upplevelsen för användaren vilket kan få stora konsekvenser. (Kohavi, Deng, Longbotham & Xu, 2014) nämner i sin studie att försäljningen för Amazon sjönk med en procent på grund av en 100ms fördröjning.
6
3 Problemformulering
När det kommer till visualisering stora mängder geografiska data kan det vara svårt för en användare att tolka datan i dess råa form. För att göra den enklare att tolka för användare behövs datan på något sätt visualiseras. Detta då datan kan komma att vara användbar för beslutsfattare.
Studiens mål är att finna det bäst lämpade ramverket för visualisering av geografiska data i form av heatmaps. Med lämplighet menas det ramverk som genom mätningar visar på bäst prestanda i form av den tid det tar att hämta den färdigrenderade sidan. Problemet är att det finns många olika ramverk tillgängliga och då hastigheten på renderingen är kritisk för användarens upplevelse behöver prestandan vara god. (Kohavi, Deng, Longbotham & Xu, 2014). Därför är det viktigt för utvecklare att välja rätt ramverk redan från första början.
För att kunna jämföra ramverk behövdes datapunkter, dessa behöver vara verklighetstrogna och finnas offentligt för användning då möjligheten att kunna replikera testerna är viktigt. Det dataset valdes till att användas kommer från Statistiska centralbyrån. De datapunkter som användes hämtades med hjälp av det API som Statistiska centralbyrån tillhandahåller i form av ett verktyg som liknar REST API.
Eftersom datan skall vara enkel för slutanvändaren att tillgå är det lämpligt att presentera visualisering på en webbplats (Krämer & Gutbell ,2015) nämner att WebGL är den mjukvara som håller på att bli standarden på webben. Det har således utvecklats flertalet open source tillägg och ramverk för WebGL för flera olika typer av 2D samt 3D applikationer. WebGL kan förbättra prestanda då det är hårdvaruaccelererat och kan använda sig av maskinens grafikkort vilket lämpar sig vid visualisering av stora datamängder då just den stora mängden datapunkter kan komma att kräva hög beräkningsprestanda (Resch, Wohlfahrt & Wosniok 2014). Därför har WebGL valts för som ett av ramverken som kommer jämföras.
Alternativet till att använda sig av WebGL är att använda sig av ett av de befintliga verktyg som finns tillgängligt i HTML 5. Scalable vector graphic eller SVG vilket kan användas i samband med canvas för att med eller utan några externa ramverk rendera vektorgrafik i webbläsaren. Att det är ett integrerat system i HTML 5 gör att det är integrerat i den befintliga tekniken. (Neumann & Winter, 2001). Detta gör i sig att det finns en stor andel ramverk som använder sig av tekniken för att rendera grafik. På senare tid har Document object model eller DOM möjliggjort ytterligare modifikationer genom ramverk som D3.js, ett verktyg för visualisering på webben (Bostock, Ogievetsky & Heer, 2011).
Dessa skillnader i tekniker gör det intressanta att jämföra minst ett WebGL baserat ramverk mot ett SVG/Canvas baserat.
Att kunna visualisera data är ett viktigt verktyg när det kommer till att förstå data set som behandlar hälsovård då dessa ofta är multivariata, alltså att det finns fler än en variabel.
(Sopan et al. ,2012) Att använda sig av hälsodata geografiskt med hjälp av färgsättning har visat sig vara väldigt effektivt för datadriven forskning. (Koua & Kraak ,2004). Då det dataset som skall användas i denna studie bygger på hälsodata är det motiverat att använda just heatmaps för visualisering (Resch, Wohlfahrt & Wosniok 2014).
7
När det kommer till val av ramverk finns det några kriterier som kommer undersökas vid valet.
Krämer & Gutbell (2015) nämner att det då inte direkt fanns någon forskning som jämförde de ramverk som utvecklats för WebGL. Det fanns inget bevis för vilket ramverk som passade bäst inom vilket tillämpningsområde och man menade på att programmerare valde sina verktyg baserat på kriterier som hur många användare som fanns eller hur väl dokumenterat varje ramverk var. Man nämner att X3DOM, three.js och Cesium är tre välkända ramverk med en stor och utvecklad användarbas.
(Barkerstedt, 2018) jämförde ramverk för inom rendering av heatmaps för marindata. De ramverk som Barkerstedt övervägde hade några enkla men avgörande kriterier. Ramverken skulle vara open source för att säkerställa att de gick att replikera. Andra viktiga aspekter var att ramverket hade god dokumentation samt en stor skara aktiva användare.
Frågeställningen är vilken typ av teknikerna som lämpar sig bäst för att visualisera data i form av geografiska data genom rendering av heatmaps sett till prestanda i form av renderingstid?
1. Identifiera lämpliga ramverk för WebGL och SVG/Canvas.
2. Definiera egenskaper som är viktiga för att visualisering med hjälp av heatmaps och välj ut lämpliga ramverk beroende på dessa egenskaper.
3. Utveckla en applikation för varje ramverk.
4. Jämför och mät prestandan i form av renderingstid för ramverk med hänsyn till de viktiga egenskaperna.
5. Presentera och analysera data.
3.1 Hypotes
• H0
Det kommer ej finnas en mätbar skillnad i prestanda sett till renderingstid mellan de valda ramverken för rendering av heatmaps i webbläsaren.
• H1
Det kommer finnas en mätbar skillnad i prestanda sett till renderingstid mellan de valda ramverken för rendering av heatmaps i webbläsaren.
8
4 Metodbeskrivning
De metoder som var mest lämpliga för att utvärdera denna forskning är enkätstudie, fallstudie, experiment och kvasiexperiment (Wohlin et al. 2012, pp:175–200).
Det tillvägagångssätt som valdes var experiment i samband med en litteraturstudie då målet var att mäta inladdningstid för den webb baserade applikationen. Variabeln för experimentet var då de olika ramverken som valdes och jämfördes. Anledningen till att experiment valdes som tillvägagångssätt var dels för att man med större säkerhet kan testa de olika variablerna i den kontrollerade miljö som ett experiment tillåter. Då målet var att mäta inladdningstiden för de olika ramverken passade en kontrollerad miljö i ett experiment bra för ändamålet. För att se till att den data som samlas in är korrekt och inte innehåller några felaktigheter behövdes arbetet utföras systematiskt och med stor noggrannhet. Detta medför längre tidsåtgång då så bra resultat som möjligt eftersträvas vilket kräver att alla steg tänks igenom ordentligt.
Den största nackdelen med att använda sig av ett experiment är det kan förekomma höga kostnaden både resurs och tidsmässigt. Det gör även eventuell replikerbarhet kostsam. Det krävs noggrann planering av experiment inför varje steg, annars är risken stor att resultatet blir skevt och felaktigt. Att resultatet skulle bekräfta eventuella teorier är inte heller någon försäkran på att det man fått fram är korrekt då det finns så många variabler utöver de man valt att ändra på. Dessa okända variabler kan ha en inverkan på det slutgiltiga resultatet. Ett väl genomfört experiment bör dock vara en tydlig indikation på att det framtagna resultatet faktiskt bekräftar eller avfärdar hypotesen.
En alternativ metod som hade kunnat användas är en användarenkät. Detta för att få en mätning på användarupplevelsen av hur de olika ramverken upplevs prestera. En användarenkät används dock nästan aldrig för att undersöka enstaka artefakter utan mer i syfte att ta reda på användares åsikter om artefakten. Detta hade kunnat vara intressant i ett senare stadie men då intresset låg på att undersöka prestanda i form av inladdningstid valdes användarenkät bort. Hade en användarenkät valts hade man kunnat få en bild hur användare hade upplevt de olika ramverken sett till prestanda, funktionalitet och enkelhet. Dock hade det varit väldigt tidskrävande sett till att sätta upp testmiljön, hitta testpersoner, genomföra intervjuer och evaluera resultaten. Även persondata hade behövt behandlas vilket även är tidskrävande (Wohlin et al. 2012, pp:175–200).
9
4.1 Etik
Det är viktigt att resultatet av de mätningar som genomförs är korrekta. Att det inte på något sätt finns variation i resultatet som beror på den mänskliga eller någon annan faktor. Exempel på detta problem skulle kunna vara att man utfört sina mätningar vid flera olika tillfällen.
Skulle man utföra mätningar vid olika tillfällen kan variabler som program i bakgrunden, annan hårdvara eller störningar på nätverket speglas i resultatet. Skulle detta ske tappar man all validitet då det finns yttre påverkan på resultatet.
Det kan förekomma hot mot studiens validitet listade av (Wohlin et al. 2012, pp:104) beskriver risker som bör finnas i åtanke. En av dessa är att om det inte finns en tillräckligt stor mängd insamlade data finns det en risk att eventuella mönster som uppstår i datan inte framstår då datamängden är för liten för att urskilja dessa. Missar man mönster som annars hade dykt upp i samband med en större datamängd finns risken att man drar en annorlunda slutsats på grund av ett felaktigt mönster. Skulle det finnas antaganden som görs på grund av att datamängden man har ej är korrekt kan detta leda till att felaktiga slutsatser dras på grund av den felaktiga datan.
Det andra handlar om att på något sätt manipulera data eller på annat sätt peka studiens resultat åt något håll får inte heller förekomma för att behålla studiens validitet. Skulle resultatet i efterhand modifieras för att ändra utkomsten av studien eller lyfta fram något som inte resultatet egentligen visade tappar hela studien sitt värde.
Till sist behöver det säkerställas att alla mätningar som görs är så korrekta som möjligt kommer samma hårdvara och uppkoppling nyttjas under alla mätningar för att minimera eventuell varians på grund av detta. Det dataset som används kommer användas till samtliga mätningar, det är ett offentligt dataset vilket betyder att den som replikerar studien kan använda det för att replikera mätningar.
All kod till den programvara som utvecklats kommer att finnas upplagd i sin helhet på Github för allmänheten att replikera detta för att tillåta andra personer att utföra sina egna tester och därmed påvisa studiens validitet genom transparens och uppmuntran till vidare forskning.
Under denna studie kom inga som helst djur eller människor till skada på något möjligt sätt.
All text som förekommer i denna studie är skriven av forskaren eller med en refererad källa till respektive författare.
10
5 Genomförande
De artefakter som form av olika ramverk användes sedan för rendering av datapunkter på en karta över Sverige. Datapunkterna bestod av en cirkel vars radie och färg var direkt kopplad till datapunktens värde, detta för att kunna se skillnad på de olika datapunkterna. Datan som användes tillhandahölls genom en API tjänst som Statistiska centralbyrån erbjuder. Datan kan exempelvis bestå av antal nyregistrerade dieselbilar i alla landets län under en viss månad eller antal personer som upplever sig ha astma. På så vis får datan en plats, exempelvis Kronoberg samt ett värde på antalet personer som upplever astmatiska besvär, exempelvis 152. Denna datan visualiserades sedan på webbplatsen i form av heatmaps på kartan. När ramverken var färdigställda utvecklades ett script som mätte tiden det tog för varje ramverk att rendera den färdiga kartan från den stund som startscriptet kördes. Beroende på hur stor datamängd som renderas kan man mäta på hur fort renderingen tar baserat på den datamängden. Man kan därför skala upp och ner mängden data som skall renderas för att sedan se hur ramverken presterar i olika scenarion.
5.1 Litteraturstudie
En stor inspiration till att göra just heatmaps på kartor är det covid-19 virus som skapade stora problem över hela värden under våren 2020. I och med att flera insjuknade var det intressant för både beslutsfattare och invånare världen över att se och förstå mängd insjukna på olika platser. Här fanns det ett behov av flera olika visualiseringar för att kunna tolka den data som kom ut från olika organisationer. Nästan alla tidningar och statliga informationsströmmar hade någon form av heatmap som redovisade spridning av covid-19 över olika delar av världen. Detta väckte intresset för att undersöka olika typer av ramverk för rendering av dessa heatmaps.
En inspirerande artikel tog upp hur D3 var en effektiv metod för att visualisera data på webben. Artikeln gick in mer i detalj hur data kan integreras på ett sätt som gör designen och utvecklingen enklare för utvecklaren. Man demonstrerade även hur animation och interaktion fungerar samt vilka prestandafördelar ramverket kan ha jämfört med andra tekniker (Bostock, Ogievetsky & Heer, 2011).
I en artikel som jämförde olika WebGL ramverk i en 3D miljö tog man fram flera styrkor och svagheter hos olika WebGL ramverk (Krämer & Gutbell ,2015). Denna artikel var väldigt inspirerande och väckte frågan om hur WebGL står sig mot mer traditionella metoder för rendering av grafik. I artikeln kunde man läsa om de kriterier som behövde mötas för att testa ramverken och presenterade sina resultat i en jämförelse. Man påpekade att fler undersökningar mellan olika tekniker och ramverk var nödvändiga.
Även en artikel som jämförde två WebGL ramverk inspirerade till att utforska detta område.
(Barkestedt, 2018) jämför i sin studie Comparison of WebGL technologies for rendering heatmaps based on marine environmental data två ramverk för WebGl i form av rendering av heatmaps för marina miljödata. Studien jämförde tiden det tog att rendera ut grafiken för datapunkter som hämtades från en extern källa. Här gavs stor insikt i området både sätt till hur heatmaps och rendering fungerar på webben.
11
5.2 Identifiering av lämpliga ramverk
För att identifiera vilka ramverk för vardera typ som är lämpliga för experimentet behöver vissa kriterier uppfyllas. Ramverket måste vara kostnadsfritt och open source, detta för att studien skall vara replikerbar. Ramverket bör ha ett gott antal aktiva användare som använder och utvecklar ramverket. Detta för att göra studien relevant i framtiden och minska risken för att använda deprecierad mjukvara. En god dokumentation behövs för att kunna använda sig av ramverket på ett korrekt och effektivt sätt.
Three.js är ett WebGL ramverk för JavaScript för att i första hand skapa och manipulera objekt i en 3D scen, det går dock även att skapa 2D miljöer med ramverket (Krämer, Gutbell ,2015).
Ramverket är open source och har många användare som bidrar till projektets utveckling via GitHub. Projektet har en väldigt utförlig dokumentation för nästan alla typer av funktioner inom ramverket, ofta även med exempelscener. Man har på ett enkelt förklarat funktionerna och länkar ofta till andra relaterade eller liknande funktioner inom ramverket. Likt Three.js använder även X3dom sig av WebGL för att integrera 2D och 3D objekt i webbläsaren. Till skillnad från Three.js använder sig X3dom av Document Object Model för integreringen av objekt. Ramverket använder sig av ett deklarativt paradigm (Ressler & Leber, 2013).
Ramverket är open source och finns på GitHub där användare kan hjälpa till att bygga vidare på ramverket. Dokumentationen finns där men är ganska grundläggande.
D3.js är ett open source Javascript bibliotek som använder sig av Scalable Vector Graphics eller SVG och canvas i samarbete med HTML och CSS för att skapa interaktiva visualiseringar.
Tanken med ramverket är att kunna på ett enkelt sätt kunna visualisera data på ett sätt som utnyttjar moderna webbläsare. Ramverket använder sig av Document Object Model eller DOM (Nair, Shetty, Shetty, 2016). Ramverket har en stor erkänd skara användare som speglas både i form av antal artiklar hämtade från Google scholar men även ett stort engagemang på GitHub där projektet finns öppet för användarna. Dokumentationen är god med en tillhörande wiki med utförlig information för ramverkets komponenter. Chart.js är ett likt D3.js ett ramverk som använder sig av ett canvas för att rendera grafik i form av exempelvis cirklar eller stapeldiagram. Tanken här är även att kunna rendera grafik i webbläsaren men med en större inriktning på diagram (Li, Mei, Shen, Su, Zhang, Wang, Zu, Chen, 2018). Ramverket är open source och finns på GitHub där användare vidareutvecklar ramverket. Dokumentationen är utförlig men guider för det mesta.
12
5.2.1 Val av ramverk
Sökord (2019- ) D3.js Three.js Chart.js X3DOM
Träffar på Google scholar
1250 603 319 69
Tabell 1 Resultat av sökningar på Google scholar
Inför valet av WebGL ramverk var både Three.js och X3DOM möjliga kandidater då de båda har en god mängd dokumentation, Three.js har dock en större och mer väldokumenterad manual med tillhörande exempel. Båda ramverken är open source och har i tidigare studier använts för visualisering av geografiska data. Antalet studier gjorda sedan 2019 enligt Google scholar i tabell 1 tyder dock på minskad relevans jämfört med Three.js som dyker upp nästan tio gånger så ofta. På grund av den mer utförliga dokumentationen och storlek på ramverkets förekomst i artiklar och sett till användare valdes Three.js för att representera WebGL tekniken.
Inför valet av ramverk som istället för WebGL nyttjar SVG alternativt canvas valdes D3.js.
Ramverket tillhandahåller mer funktionalitet tillsammans med en djupare och mer välutvecklad dokumentation. Båda ramverken är open source och har tidigare använts för att visualisera geografiska data. Dock förekommer D3.js oftare i artiklar vilket gör ramverket mer relevant än motsvarande förekomst av Chart.js.
13
5.2.2 Implementation av Three.js
För att Three.js skulle kunna implementeras i webbapplikationen behövde ramverket laddas in med hjälp av en länk som hämtas från utvecklarens hemsida. Sedan behövdes en kamera, renderare och en scen initieras där de objekt som skulle renderas placerades, se bilaga nedan.
I samband med att renderaren initierades sattes ett canvas som mål, genomskinlighet slogs även på för att ta bort bakgrundsfärger. När kameran initierades sattes även parametrar för kameravinkel, kameraposition samt höjd och bredd1.
var camera = new THREE.OrthographicCamera(1100 / -2, 900 / 2, 1100 / 2, 900 / -2, 0, 5);
var scene = new THREE.Scene();
var renderer = new THREE.WebGLRenderer({canvas: artifactCanvas, alpha: true, antialias: true });
renderer.setSize(1100, 900);
document.body.appendChild(renderer.domElement);
controls = new THREE.OrbitControls(camera, renderer.domElement);
controls.enablePan = false;
controls.enableRotate = false;
Figur 6 Kod för att initiera kamera och scen i Three.js
Nedan är koden som användes för att rendera de cirklar som användes i Three.js modulen.
// Function that draws the circles
function drawCircle(x, y, size, color) {
var geometry = new THREE.CircleGeometry(size, 32);
var material = new THREE.MeshBasicMaterial({ color: color, transparent: true });
var circle = new THREE.Mesh(geometry, material);
circle.position.x = x;
circle.position.y = y;
material.opacity = 0.7;
scene.add(circle);
}
Figur 7 Kod för att rendera cirklar i Three.js
Sedan behövde den SVG fil som representerade en karta över Sveriges län renderas, dessa län skulle representeras av olika stora punkter.
1 https://github.com/a17maxsj/heatmaps-rendering-using-web/commit/5e1e
14
5.2.3 Implementation av D3.js
Implementationen av D3.JS började med att en div som skulle husera SVG containern valdes ut, där sattes sedan se storlek på den SVG som skulle ritas ut. En zoomfunktion adderades för att användaren enklare skulle kunna navigera kartan.2
//Select container
var sampleSVG = d3.select("#svg-container") .append("svg")
.attr("width", 900) .attr("height", 700)
.call(d3.behavior.zoom().on("zoom", function() { sampleSVG.attr("transform", "translate(" +
d3.event.translate + ")" + " scale(" + d3.event.scale + ")") }))
.append("g")
Figur 8 Mål satt för rendering av canvas samt tillägg av variabler i D3.js.
Funktionen som användes för att rita ut kartan över Sverige var mycket simplare att implementera i D3.js än i Three.js.
var myimage = sampleSVG.append('image') .attr('xlink:href', 'img/map.svg') .attr('width', 900)
.attr('height', 600)
Figur 9 Hämtning och rendering av SVG karta i D3.js.
Nedanför är funktionen som användes för att rita ut cirklar över kartan. Värden för x,y positionering, storlek, text samt färg skickades med när funktionen blev tillkallad. En opacitet sattes på cirklarna för att man enklare skulle kunna se kartan under.
function drawCircle(x, y, size, tip, dotColor) { sampleSVG.append("circle")
.style("stroke", "gray") .style("fill", dotColor) .attr("cx", x)
.attr("cy", y) .attr("r", size)
.style("opacity", 0.7)
Figur 10 Kod för att rendera cirklar i D3.js
2 https://github.com/a17maxsj/heatmaps-rendering-using-web/commit/97f6
15 Figur 11 Rendering av en färdig D3.js heatmap
5.3 Progression
Inspirationen till den typ av heatmaps som användes för projektet kommer dels mycket från den rådande stunden som pågick under arbetets gång i form av viruset covid-19. Många olika nyhetsbyråer, forskningsartiklar och stater har gått ut med olika typer av tjänster och bilder som kartlägger covid-19s utbrott i världen. En stor inspiration var den grafik som The Guardian använde i sina artiklar om viruset3.
5.3.1 Sidospår angående val av karta
Det användes flera olika typer av kartor under projektets gång. Till en början användes kartor hämtade från andra tjänster, den första som provades var openlayers. Det visade sig dock tidigt att det inte var en effektiv väg att ta då datan som tillhandahölls från SCB ej hade några koordinater. Därför valdes någonting simplare i form av Google Geochart som kunde rendera ut enstaka länder. Dock krävdes det en API nyckel för att använda Google Geochart. I slutändan blev det en lokal SVG fil över Sverige som stod för det slutgiltiga resultatet4. Denna kunde renderas ut smidigt med hjälp av ramverken vilket syns i figur 11.
3 https://www.theguardian.com/world/2020/apr/21/coronavirus-map-which-countries-have-the- most-cases-and-deaths-covid-19
4 https://github.com/a17maxsj/heatmaps-rendering-using-web/commit/1720
16
5.3.2 Hämtning av data från SCB
För att hämta den data som senare skulle presenteras på kartan behövdes ett anrop till det API som SCB använder sig av för att skicka ut data. Figur 12 visar hur koden för detta ser ut.
En JSON förfrågan likt den som visas i figur två användes i kombination med dess webbadress som förfrågan skall skickas till. Som svar på förfrågan skickas informationen som motsvarar förfrågan ut från SCB’s API. Värden från API svaret sparas sedan ner i en array som används för att spara information som länet informationen är aktuell för, vilket datum datan gäller för och värdet. Värdena används sedan vid utritningen av heatmapen5.
$.ajax({
url:
"http://api.scb.se/OV0104/v1/doris/sv/ssd/START/TK/TK1001/TK1001A/PersBi larDrivMedel",
type: "POST",
data: JSON.stringify(jsonObj), dataType: "json",
success: function(obj) {
$.each(obj.data, function(index, data) { //Testing, display all values
document.getElementById("lanInfo").innerHTML +=
"<p>Län: " + data.key[0] + " Datum: " + data.key[2] + " Värde: " + data.values + "</p>";
// put all the values in an array
dList.push({ lan: data.key[0], ar: data.key[2], dValue:
data.values[0] });
Figur 12 Hämtning av data från SCB.
5.3.3 Skalning av cirklar på kartan
Ett problem som uppstod under utvecklingen av ramverken var hur skalningen av storleken på cirklarna skulle utföras. Då värdena på de olika datapunkterna kunde skilja sig åt stort var det viktigt att implementera en funktion som på något sätt såg till att alla datapunkters storlek var proportionerliga till varandra. Detta då tanken var att basera cirklarnas storlek direkt på datapunkternas värde.
Ett par olika lösningar på detta problem evaluerades, bland annat gjordes ett försök till att med hjälp av hårdkodade intervall bestämma storleken. Denna metod valdes dock hastigt bort då det krävde en stor mängd manuell kodning. Antingen hade intervallen behövt vara väldigt små alternativt lägga på någon form av extra varians beroende på värdets storlek. Denna
5 https://github.com/a17maxsj/heatmaps-rendering-using-web/commit/dc9f
17
metod var väldigt ineffektiv och ansågs direkt behöva bytas ut mot något mer effektivt. För att se det gamla systemet, se fotnot6.
En algoritm utvecklades för att på ett effektivt sätt skala alla värden mellan det största och minsta värdet vilket syns i figur 13. Värdena sparades ner i en separat array och med hjälp av funktionerna ”math.min” och ”math.max” sparades det minsta respektive största värdet. De storleksvärden som tillhandahölls av SCB’s API kördes sedan genom funktionen för att skala dem till ett proportionerligt värde i relation till dess storlek. För att undvika att det största värdet inte blev för stort och det minsta för litet sattes ett minsta och största värde på cirklarna.
För att se funktionens implementation i sin helhet, se fotnot7
function scalenum(unscaledNum, minAllowed, maxAllowed, min, max) { return (maxAllowed-minAllowed)*(unscaledNum-min)/(max-min)+ minAllowed;
}
Figur 13 Funktionen som skalade värden
5.4 Pilotstudie
En pilotstudie utfördes för att undersöka huruvida vidare forskning skulle vara möjlig anseende mätning av ramverket. Detta för att undersöka eventuella fel som kunnat orsaka problem och brister hos experimentet. Pilotstudien bestod av mätningar för de båda ramverken där en mätserie utfördes 300 gånger där tiden för ramverken att rendera ut den färdiga kartan mättes. Hårdvaran som mätningarna gjordes på var en stationär dator, se tabell 2 för den hårdvara som användes vit mättillfället.
Processor Intel Core i7 2600k @ 3.40GHz
RAM 14GB
Grafikkort AMD Radeon R9 390
Operativsystem Windows 10
Webbläsare Google Chrome Version 81.0.4044.113
Tabell 2 Specifikationer för datorn som utförde mätningarna
6 https://github.com/a17maxsj/heatmaps-rendering-using-webgl/commit/266d
7 https://github.com/a17maxsj/heatmaps-rendering-using-web/commit/4d19
18
Figur 13 Preliminär mätning
Den preliminära mätningen skillnad i renderingstid mellan ramverk, en liten men tydlig fördel åt D3.js påvisas av resultatet. Båda ramverken klarar av att rendera alla datapunkter utan någon större tidsåtgång. Standardavvikelsen tyder på att det finns viss varians mellan mätningarna och att resultatet kan komma att bli annorlunda beroende på antal mätningar samt datapunkter.
Då detta är en relativt smal mätserie finns det en chans att Three.js kan komma att ha ett bättre resultat om datamängden skulle vara större än i nuläget, kanske rent av presterar den bättre än D3.js under sådana förhållanden. I nuläget har mätningen genomförts på hela processen från att ta emot datan till renderingen. Alltså skulle resultatet kunna se annorlunda ut beroende på om mätningen görs på endast renderingsdelen. Men då mätningen ser lika dan ut för båda ramverken behölls detta för pilotstudien. Detta ändrades sedan under det slutgiltiga experimentet för att endast mäta delen där renderingen sker i respektive ramverk.
Pilotstudien visar på att mätning är möjligt på de båda ramverken och jämföra dess prestanda i form av renderingstid, därför är det rimligt att fortsätta studien för att se vilken hypotes som stämmer.
19
6 Utvärdering
6.1 Presentation av undersökning
De slutgiltiga mätningarna genomfördes på samma sätt som den tidigare genomförda pilotstudien. Samma hårdvara användes som syns i Tabell 2. Inför varje mätpunkt laddades websidan om för att återställa alla script och hämtning av data. Testen för varje ramverk kördes i fyra separata serier där renderingen för varje ramverk utfördes totalt 500 gånger per serie men med olika mängder datapunkter, dessa var 21, 100, 1000 samt 10000. Detta gjorde för att ta reda på hur ramverken presterar under rendering av olika stor mängd data. Då Three.js använder sig utav hårdvaruacceleration är det möjligt att en större datamängd inte påverkar prestandan lika mycket som för D3.js Hårdvaran som användes vid mätningarna är de samma som i tabell 2.
Alla tester kördes separat för de olika ramverken D3.js och Three.js.
6.2 Mätningar
Figur 14 Medelvärde för varje ramverk med 21 datapunkter
46.01733
16.85725 0
20 40 60 80 100
1
Tid (ms)
21 datapunkter
Medelvärde för rendering ramverk 21 datapunkter
Three.js D3.js
20
Figur 15 Linjediagram för varje ramverk med 21 datapunkter
Figur 16 Medelvärde för varje ramverk med 100 datapunkter
0 10 20 30 40 50 60 70 80 90 100
1 19 37 55 73 91 109 127 145 163 181 199 217 235 253 271 289 307 325 343 361 379 397 415 433 451 469 487
Tid (ms)
Axeltitel
Brusdata för ramverk med 21 datapunkter
Three.js D3.JS
61,80126 64,70006
0 20 40 60 80 100
Tid (ms)
100 datapunkter
Medelvärde för rendering ramverk 100 punkter
Three.js D3.js
21
Figur 17 Linjediagram för varje ramverk med 100 datapunkter
Figur 18 Medelvärde för varje ramverk med 1000 datapunkter
0 50 100 150 200 250
1 19 37 55 73 91 109 127 145 163 181 199 217 235 253 271 289 307 325 343 361 379 397 415 433 451 469 487
Tid (ms)
100 datapunkter
Brusdata ramverk 100 punkter
Three.js D3.js
155,65032
499,23394
0 100 200 300 400 500 600
1
Tid (ms)
1000 datapunkter
Medelvärde för rendering ramverk 1000 punkter
Three.js D3.js
22
Figur 19 Linjediagram för varje ramverk med 1000 datapunkter
Figur 20 Medelvärde för varje ramverk med 100o0 datapunkter
0 100 200 300 400 500 600 700 800
1 19 37 55 73 91 109 127 145 163 181 199 217 235 253 271 289 307 325 343 361 379 397 415 433 451 469 487
Tid (ms)
1000 datapunkter
Brusdata ramverk 1000 punkter
Three.js D3.js
188,0898
4736,95284
0 1000 2000 3000 4000 5000 6000
1
Tid (ms)
10000 datapunkter
Medelvärde för rendering ramverk 10000 punkter
Three.js D3.js
23
Figur 21 Linjediagram för varje ramverk med 10000 datapunkter
Figur 22 Linjediagram för samtliga serier
0 1000 2000 3000 4000 5000 6000
1 20 39 58 77 96 115 134 153 172 191 210 229 248 267 286 305 324 343 362 381 400 419 438 457 476 495
Tid (ms)
10000 datapunkter
Brusdata ramverk 10000 punkter
Three.js D3.js
0 1000 2000 3000 4000 5000 6000
21 100 1000 10000
Tid (ms)
Antal datapunkter
Linjediagram samtliga serier
Three.js D3.js
24
6.3 Analys
Mätningarna som utfördes tyder på att det finns skillnader i skalbarhet mellan de olika ramverken. Figur 14 och 15 visar att D3.js är runt 30 millisekunder snabbare vid rendering av 21 datapunkter än Three.js. Alltså presterar D3.js bättre i mindre skala där inte antalet datapunkter är speciellt stort. Figur 16,17 påvisar dock att redan vid 100 datapunkter är har D3.js tappat försprånget gentemot Three.js där ramverken utför renderingen på 64 respektive 61 ms. Här är det möjligt att Three.js har möjligheten att börja sträcka på benen i form av att börja utnyttja den support för hårdvaruaccelerering som Three.js har tillgång till.
Redan vid 1000 datapunkter som visas i Figur 18 och 19 har D3.js renderingstid ökat med cirka 430 ms efter en ökning på 900 datapunkter. Three.js har även fått ökade renderingstider, dock endast ca 90 ms mer än vid 100 datapunkter. Här skiljer det alltså nästan 345 ms mellan de två ramverken.
Figur 18,19,20 och 21 visar alla att i takt med att fler datapunkter läggs till ökar renderingstiden för de båda ramverken. En tydlig skillnad är dock att D3.js blir mer och mer tungstyrt desto mer datapunkter som adderas medan ökningen inte alls är lika markant för Three.js. Vid 10000 datapunkter tar det D3.js 4736 ms innan renderingen är färdig vilket är mer än 26 gånger längre än Three.js som utför renderingen på 180 ms. Vid dessa större datamängder är Three.js hårdvaruaccelerering väsentlig för att på ett snabbt sätt kunna utföra renderingen av datan inom ett användarvänligt tidsspann. Figur 22 visar att det finns en brytpunkt där Three.js har en lägre renderingstid än D3.js. Detta bryt sker någonstans mellan 21 och 100 antal datapunkter, figur 16 visar att Three.js i det scenariot är cirka 3ms snabbare än D3.js. Därför kan man anta att brytpunkten är närmare 100 än 21.
De spikar som visas på Figur 17 för ramverket D3.js börjar påvisa ett mönster som sedan i Figur 19 och 21 blir mer tydligt och upplevs återkommande. Att dessa beror på att en annan process på datorn drog ner på processorkraften är en teori men kan lika gärna ha berott på störningar i nätverket eller på webbservern.
6.4 Slutsatser
Enligt de mätningar som genomfördes på de två ramverken D3.js och Three.js kan man i alla testfall förutom ett som var på en liten skala se en tydlig skillnad mellan ramverken när det kommer till hur möjligheten för att rendera större datamängder sker. Three.js har påvisat lägre renderingstider i tre av fyra testfall där mängden gradvis har ökat mellan varje serie tester. Det enda testet där D3.js var snabbare på att rendera datapunkterna än Three.js var den minsta serien. Initialt verkade det som att D3.js var det snabbare ramverket när det kommer till rendering men då datamängden blev allt större och Three.js kunde använda sig av datorns hårdvara för att skynda på renderingen var det uppenbart att Three.js var det effektivare ramverket.
25
Som tidigare nämnt i studien ansågs implementeringen av D3.js vara enklare då ramverket inte var lika komplicerat som Three.js sett till antal steg och moduler som behövde initieras.
Vid utvecklingen av ett större projekt med fler datapunkter är det dock värt den längre och svårare implementeringsfasen som krävs för Three.js sett till den skillnaden i renderingstid jämfört med D3.js i exempelvis Figur 20.
De andra punkter som var viktiga för ramverken att tillhandahålla i form av att ramverken var open source, ha en stor andel användare samt ha god dokumentation var väldigt snarlika.
Båda ramverken hade ett aktivt community som använde och utvecklade respektive plattform både sett till programvara och den dokumentation som fanns tillgänglig. Enligt Tabell 1 förekom D3.js oftare i studier vilket kan bero på att ramverket är enklare att implementera och eventuellt ett mer inriktat användningsområde gentemot Three.js som är väldigt brett.
För renderingen av heatmaps på en karta anses därför Three.js var den mer lämpliga kandidaten av de två jämförda ramverken. Detta då den typ av data som användes ofta är av den större varianten vilket D3.js bevisligen var sämre på sett till renderingstiden med en stor marginal. De viktiga punkterna som open source, aktiva användare och en god dokumentation fanns där och underlättade under utvecklingen av webbapplikationen.
Hypotesen om att det fanns en mätbar skillnad mellan dessa olika ramverk och tekniker vid rendering av heatmaps sätt till tid bevisades alltså.
26
7 Avslutande diskussion
7.1 Sammanfattning
För att besvara delmål 1 vilket var identifieringen av lämpliga ramverk användes liknande studier inom området rendering av olika typer. Det gjordes för att identifiera många ramverk med olika egenskaper och specialiteter. Dessa sammanställdes sedan till totalt fyra kandidater där hälften var WebGL baserade medan den andra hälften använde sig av SVG/Canvas för renderingen. När dessa ramverk var identifierade började arbetet med att identifiera de viktiga egenskaper som var viktiga för visualiseringen av heatmaps vilket var delmål 2. För att besvara detta togs ett antal kriterier fram som var viktiga för att säkerställa att ramverken var aktuella, tillgängliga och väldokumenterade. För att se till att ramverken var aktuella dokumenterades antalet träffar som innehöll ramverkets namn i studier på Google Scholar, sker kontinuerlig forskning med ramverken ansågs de vara aktuella. För att ramverken skulle vara tillgängliga behövde alla kandidater vara open source, detta för att säkerställa att studien var replikerbar. Dokumentation av ramverket och dess funktioner var viktigt för att underlätta utvecklingen av webbapplikationen. Det två ramverk som valdes ut för testning var Three.js som använde sig utav WebGL för rendering och D3.js som var SVG/Canvas baserat.
Delmål tre som bestod av utvecklingen av en applikation för varje ramverk, detta delmål genomfördes och i slutändan stod två ramverk färdiga vars renderingstid för att rita ut datapunkter var mätbar. För att besvara delmål fyra gjordes flertalet mätningar på ramverken med olika antal datapunkter. Resultatet visade att Three.js utförde snabbare renderingar än D3.js i tre av fyra fall. Skillnaden i renderingstid mellan ramverken ökade desto större antal datapunkter som skulle renderas. I den sista och största mätningen där 10 000 datapunkter renderades var Three.js mer än 26 gånger snabbare, renderingstiden för D3.js var 4736 ms medan Three.js renderade samma antal datapunkter på endast 180 ms, detta tack vare användningen av hårdvaruaccelerering.
Delmål fem genomfördes genom att visualisera den insamlade datan i form av grafer som bestod av medelvärden och linjediagram. Varje serie med olika antal datapunkter fick egna grafer, Figur 14–20. Resultatet av studien visade på att Three.js var mer lämpligt för rendering av denna typ av data då den ofta är stor sett till mängden. Three.js visade sig kunna nyttja hårdvaruaccelerationen på ett sätt som gjorde ramverket väldigt effektivt vid rendering av stora datamängder. Därför ansågs Three.js vara mer lämplig än D3.js.
I och med detta bekräftades hypotesen om att det fanns en mätbar skillnad mellan dessa ramverk sett till att rendera denna typ av heatmaps.
27
7.2 Diskussion
Resultatet av studien visade på att det fanns en stor skillnad mellan de olika ramverken vilket gav Three.js en stor fördel för denna typ av data och visualisering i form av heatmaps. Redan vid 10 000 datapunkter handlade det om nästan 4 sekunders skillnad i renderingstiden vilket kan göra väldigt stor skillnad för slutanvändaren beroende på i vilket applikation ramverken används inom. Är hastigheten av största vikt vilket den ofta är bör utvecklare välja ett WebGL baserat ramverk som Three.js för att försäkra att renderingstiden inte blir för stor när datamängden ökar. Eftersom D3.js faktiskt presterade snabbare i den lägsta datamängden kan utvecklare få en falsk uppfattning av hur ramverket faktiskt presterar när skalan på datamängden växer.
Även om D3.js hade en väldigt lång renderingstid vilket gav Three.js ett väldigt stort övertag i studien kan man inte avslå ramverket helt. Implementationen av D3.js var väldigt smidig och krävde inga större kunskaper inom området jämfört med Three.js som var svårare och mer komplicerat. Är datamängden inte större än runt hundra datapunkter och prestanda ej är av största vikt är det möjligt att eventuellt implementera D3.js för en utvecklare med mindre kunskap eller om utvecklingstiden behöver vara kort.
Den data som användes i denna studie är inte explicit nödvändig för att replikera arbetet då koden som används för att ta ut värden ur JSON objektet går att anpassa till andra typer av data om detta skulle vara nödvändigt. Det viktiga är att datan har ett ID för positionering, tidpunkt samt ett värde som representerar datapunkten. Om mätningar skulle ha påverkats av att andra processer på datorn under mättillfället skulle datan kunna ha blivit felaktig, för att motverka detta kördes flertalet olika mätningar i olika serier vid olika tidpunkter för att på så sätt sprida ut eventuella felaktigheter. Då resultatet verkar följa en enda trend förutom vid den första mätningen kan det antas att inga större störningar skedde under mätningarna.
Relaterade arbeten som togs upp i litteraturstudien var användbara under arbetets gång för att ge insikt i hur ramverken och renderingsprocessen fungerade på webben. Processen som användes i de två arbeten som jämförde WebGL ramverk var snarlika de som användes i denna studie. Resultaten från dessa studier liknar de slutsatser som drogs utav denna studie.
(Barkerstedt, 2018) kom i sin studie fram till att Three.js är ett lämpligt ramverk när det kommer till rendering av heatmaps och på grund av en kort renderingstid. Eftersom låg renderingstid är viktigt för användaren går detta i linje med studiens resultat (Kohavi, Deng, Longbotham & Xu, 2014).
För att motverka de hot gentemot validiteten som nämns i etik delen har angående hotet om att datan ej skulle vara tillräcklig gjordes flertalet olika mätningar i olika serier med olika stor datamängd. Detta för att identifiera eventuella mönster vilket gjordes men även för att säkerställa att datan var tillräcklig tillförlitlig för att kunna dra en slutsats.
Resultatet eller datan har inte heller i efterhand modifierats på något sätt för att påverka resultatet eller någon annan anledning. Hanteringen av den data som utvanns var väldigt noggrann och exakt för att säkerställa att datan var den korrekta datan för respektive mätning och tillfälle. Detta genom att vara noggrann i de procedurerna för hur datan sparades efter mätningar, hur de olika dataseten namngavs och placerades för att inte på något sätt blanda ihop dem. Vid framtagningen av grafer och annat material som användes som grund för resultatet dubbelkollades alltid att datan kom från rätt källa.
28
För att säkerställa att mätningarna gjordes korrekt användes samma hårdvara och nätuppkoppling för att säkerställa att det ej skedde avvikelser mellan mätningarna på grund av dessa variabler. Endast ett dataset har använts under mätningarna för att eliminera detta som en möjlig variabel för avvikelser i resultatet.
Ingen persondata hanterades under denna studie då inga intervjuer utfördes. Inte heller datasetet innehöll några känsliga eller personliga uppgifter. Dock finns en risk som kan uppstå när man gör heatmaps är att om man använder känsliga data finns det en möjlighet att den kan kopplas till enskilda personer, företag eller myndigheter. Om heatmapen skulle visa exempelvis vart speciellt förmögna, sjuka eller andra data som anses vara speciell och eventuellt bör skyddas men röjs på grund av att heatmapen går in för mycket på detaljnivå och gör det möjligt för användare att göra kopplingar mellan informationen och specifika personer skulle detta vara ett stort hot och en risk för samhället.
Allting som i studien inte är ordentligt refererat till respektive utgivare är författarens egna antaganden, upptäckter, kommentarer och slutsatser. Ingen information har tagits utan att ordentligt referera till källan.
Samhällsnyttan med detta arbete är att utvecklare av system som nyttjar dessa teknologier inom flera olika industrier som för hälsoindustrin eller den offentliga sektorn. Genom forskningen finns möjligheten för utvecklare att utveckla robusta system som tillåter slutanvändaren att fatta beslut baserat på den data som visualiserats på ett mer precist och korrekt sätt. Eftersom heatmaps genom visualiseringen tillåter slutanvändaren att tolka och förstå datan enklare jämfört med endast rådata. Från ett hållbarhetsperspektiv finns möjligheten att spara på energi genom att välja det ramverk som för en specifik datamängd är effektivast genom att utföra renderingen på så kort tid som möjligt. I det här specifika fallet skulle alltså D3.js vara effektivast ur ett hållbarhetsperspektiv upp till precis innan 100 datapunkter medan Three.js anses var mer hållbart från 100 datapunkter och uppåt. I vissa fall finns det en möjlighet att användaren kanske inte ens behöver se en heatmap för att förstå innehållet. Exempelvis kan en tabell visas först som innehåller värdena med möjligheten att rendera ut en heatmap vid behov.
7.2.1 Diskussion kring implementation
Under implementationen av webbapplikationens gång uppstod vissa oväntade svårigheter.
Dessa gällde de båda ramverken men även för hämtningen av data från SCB’s API. Under implementeringen av Three.js var det vissa delar som upplevdes komplicerade, en av dessa var hur dem kamera, scen och rendering skulle ställas in för att i första hand rendera någonting. Även fininställningar av dessa krävde tid och kunskap, speciellt renderaren som det fanns olika versioner av beroende om scenen var 2D eller 3D baserad. Att ramverket kunde användas för bara 2D och 3D grafik gjorde eftersökningar något svårare då det inte alltid stod klart vilken av de två tekniker som syftades. För det båda ramverken var implementationen av funktionen som ritade ut cirklar inte självklar då de båda ramverken hade något annorlunda tillvägagångssätt när det kom till hur cirklarnas attribut hanterades. Detta problem löstes genom att läsa igenom de båda ramverkens dokumentation.
Även hämtningen av data från SCB var initialt något svår då det inte var klart hur informationen som mottogs skulle hanteras, detta löstes dock enkelt med hjälp av dokumentationen som SCB tillhandahåller och värdena kunde hämtas ur en array med olika nyckelvärden.
29
7.3 Framtida arbete
Framtida arbeten inom området skulle kunna inkludera testning med andra och större datamängder, hundra eller miljontals datapunkter för att se om renderingstiderna fortsätter öka på samma sätt eller eventuellt kanske planar ut efter en viss tid. Man skulle även kunna byta ut datasetet för att se om detta skulle kunna ha någon påverkan på resultaten. Ett annan utveckling skulle kunna vara att titta på andra typer av ramverk eller teknologier för att se hur dessa presterar i samma eller ett liknande scenario. Det finns alltid en möjlighet att nya eller gamla teknologier exempelvis är lättare att implementera eller kan utföra renderingar ännu mer effektivt. Även inom just området WebGL ramverk finns det flertalet olika ramverk som kan implementera och testas.
Något annat som skulle vara intressant att undersöka är en implementation av WebGL i D3.js eller ett liknande ramverk för att kombinera den smidigare implementationen av som D3.js erbjuder i kombination med att kunna nyttja hårdvaruacceleration för ökad prestanda. En annan möjlighet skulle kunna vara att i det nativa HTML miljön utveckla ett stöd inom canvas och SVG för implementera funktionalitet för heatmaps och flertalet andra grafer. Exempelvis linjediagram, matriser och stapeldiagram, detta hade kunnat strömlinjeformat utvecklingen ytterligare genom att stödet redan finns implementerat. Att direkt i HTML kunna nyttja hårdvaruaccelerering hade även varigt ett intressant område att undersöka.
30
Referenser
Barkestedt, F. (2018). Jämförelse av WebGL-teknologier vid rendering av heatmaps utifrån marin miljödata: Jämförelse mellan Three. js och X3DOM.
Behr, J., Eschler, P., Jung, Y., & Zöllner, M. (2009, June). X3DOM: a DOM-based HTML5/X3D integration model. In Proceedings of the 14th international conference on 3D web technology (pp. 127- 135).
Bostock, M., Ogievetsky, V., & Heer, J. (2011). D³ data-driven documents. IEEE transactions on visualization and computer graphics, 17(12), 2301-2309.
Eichinski, P., & Roe, P. (2014, July). Heat maps for aggregating bioacoustic annotations. In 2014 18th International Conference on Information Visualisation (pp. 88-93). IEEE.
Haara, A., Pykäläinen, J., Tolvanen, A., & Kurttila, M. (2018). Use of interactive data visualization in multi-objective forest planning. Journal of environmental management, 210, 71-86.
Georges, V., Courtemanche, F., Senecal, S., Baccino, T., Fredette, M., & Leger, P. M. (2016, May). UX heatmaps: mapping user experience on visual interfaces. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems (pp. 4850-4860).
Kohavi, R., Deng, A., Longbotham, R., & Xu, Y. (2014, August). Seven rules of thumb for web site experimenters. In Proceedings of the 20th ACM SIGKDD international conference on Knowledge discovery and data mining (pp. 1857-1866).
Koua, E. L., & Kraak, M. J. (2004). Geovisualization to support the exploration of large health and demographic survey data. International journal of health geographics, 3(1), 12.
Krämer, M., & Gutbell, R. (2015, June). A case study on 3D geospatial applications in the web using state-of-the-art WebGL frameworks. In Proceedings of the 20th International Conference on 3D Web Technology (pp. 189-197).
Lavoué, G., Chevalier, L., & Dupont, F. (2013, June). Streaming compressed 3D data on the web using JavaScript and WebGL. In Proceedings of the 18th international conference on 3D web technology (pp.
19-27).
Li, D., Mei, H., Shen, Y., Su, S., Zhang, W., Wang, J., ... & Chen, W. (2018). ECharts: A declarative framework for rapid construction of web-based visualization. Visual Informatics, 2(2), 136-146.
Lin, J. C. C., & Lu, H. (2000). Towards an understanding of the behavioural intention to use a web site.
International journal of information management, 20(3), 197-208.
Masse, M. (2011). REST API Design Rulebook: Designing Consistent RESTful Web Service Interfaces.
" O'Reilly Media, Inc.".
Metsalu, T., & Vilo, J. (2015). ClustVis: a web tool for visualizing clustering of multivariate data using Principal Component Analysis and heatmap. Nucleic acids research, 43(W1), W566-W570.
Nair, L., Shetty, S., & Shetty, S. (2016). Interactive visual analytics on Big Data: Tableau vs D3.
js. Journal of e-Learning and Knowledge Society, 12(4).
31
Neumann, A., & Winter, A. M. (2001, August). Time for SVG—towards high quality interactive web- maps. In Proceedings of the 20th International Cartographic Conference, Beijing, China (pp. 2349- 62).
Resch, B., Wohlfahrt, R., & Wosniok, C. (2014). Web-based 4D visualization of marine geo-data using WebGL. Cartography and Geographic Information Science, 41(3), 235-247.
Ressler, S., & Leber, K. (2013, November). Web Based 3D Visualization and Interaction for Whole Body Laser Scans. In Proc. of 4th Int. Conf. on 3D Body Scanning Technologies, Long Beach CA, USA (pp.
166-172).
Sopan, A., Noh, A. S. I., Karol, S., Rosenfeld, P., Lee, G., & Shneiderman, B. (2012). Community Health Map: A geospatial and multivariate data visualization tool for public health datasets. Government Information Quarterly, 29(2), 223-234.
Wang, S., Keivanloo, I., & Zou, Y. (2014, November). How do developers react to restful api evolution?.
In International Conference on Service-Oriented Computing (pp. 245-259). Springer, Berlin, Heidelberg.
Wohlin, C et al., (2012) ‘Experimentation in software engineering’. Berlin: Spring, pp 12 – 200
