INTERAKTIV
VISUALISERING
AV
STORA
DATASET
MED
WEBBTEKNIKER
En jämförelse mellan JavaScript-biblioteken
Leaflet och OpenLayers
INTERACTIVE VISUALIZATION OF BIG
DATA WITH WEB TECHNOLOGIES
A comparison between the JavaScript libraries
Leaflet and OpenLayers
Examensarbete inom huvudområdet Informationsteknologi
Grundnivå 30 högskolepoäng
Vårtermin 2020
Alice Anglesjö
Handledare: Mikael Berndtsson
Examinator: Henrik Gustavsson
Sammanfattning
Visualisering är ett kraftfullt sätt att ge människor en förståelse för data med hjälp av mönster. Fördelarna med att kunna visualisera data på rätt kan resultera i förbättrat
beslutsfattande, bättre inriktad dataanalys och bättre samarbete och
informationsdelning. Visualisering av stora datamängder medför en rad olika utmaningar tack vare dess storlek och struktur. I och med att dagens webbteknologier utvecklats så pass mycket att de kan mäta sig med desktop-applikationer är webbtekniker ett utmärkt hjälpmedel vid visualisering av data för att också göra det mer tillgängligt.
I arbetet skapas två applikationer med hjälp av webbteknikerna i MEAN-stacken där datapunkter kommer att skrivas ut på två olika kartor skapade med Leaflet och OpenLayers. Därefter genomförs sedan ett experiment som mäter laddningstider vid utritning av datapunkterna samt vid interaktion med kartapplikationen. Arbetet ska i sin helhet analysera laddningstider hos en interaktiv karta som visualiserar Big Data med hjälp av webbtekniker.
Innehållsförteckning
1
Introduktion ... 1
2
Bakgrund ... 2
2.1 Big Data ... 2 2.2 Datavisualisering ... 3 2.2.1 Heatmaps ...4 2.3 Visualisering på webben ... 4 2.3.1 Heatmap.js ...5 2.3.2 Leaflet .js ...5 2.3.3 OpenStreetMap ...6 2.3.4 OpenLayers...6 2.4 MEAN-stack... 7 2.4.1 MongoDB ...7 2.4.2 Express.js ...9 2.4.3 Angular.js ...9 2.4.4 Node.js ...10 2.5 Relaterad/tidigare forskning ... 113
Problemformulering ... 12
3.1 Syfte och frågeställningar ... 12
3.1.1 Frågeställningar ...13
3.2 Hypotes ... 13
3.3 Delmål ... 13
4
Metod ... 14
4.1 Etiska aspekter ... 14
4.1.1 Etik inom Big Data ...15
4.2 Alternativa metoder ... 15
5
Genomförande ... 17
5.1 Litteraturstudie ... 17 5.2 Implementation ... 18 5.2.1 Dataset ...18 5.2.2 Node.js ...19 5.2.3 Express.js ...19 5.2.4 MongoDB ...205.2.5 Heatmap med Leaflet.js ...21
5.2.6 Heatmap med OpenLayers ...22
5.2.7 Markörer med Leaflet ...24
5.2.8 Markörer med Openlayers ...24
5.2.9 Mätscript ...26 5.3 Progression ... 28 5.3.1 Databas ...28 5.3.2 OpenLayers...29 5.3.3 Leaflet ...32 5.4 Pilotstudie ... 32 5.4.1 Initial rendering...33 5.4.2 Zoom-in ...36 5.4.3 Zoom ut ...38
6
Utvärdering ... 41
6.1 Presentation av undersökning ... 426.1.1 Initial rendering efter hård inladdning ...43
6.1.2 Laddningstider efter zoom-in ...46
6.2 Analys ... 50
6.3 Slutsatser... 51
7
Avslutande diskussion ... 54
7.1 Sammanfattning ... 54
7.2 Diskussion ... 55
7.2.1 Etik och risker...56
7.2.2 Samhällsnytta och risker ...56
7.3 Framtida arbete ... 57
1
1
Introduktion
I dagens samhälle ökar mängden data som generas och lagras där endast cirka 20% är strukturerad data, vilket medför olika problem då ostrukturerade data är svår att analysera och arbeta med. Stora ostrukturerade dataset med sådan hög genomströmning att det överstiger förmågan hos traditionella datahaneringsverktyg att bearbeta och hantera informationen kallas Big Data (Caldarola & Rinaldi 2017; Barik et al. 2017).
Ett exempel på en sådan data typ är geospatial data som sett en explosion i mängden generade data från bland annat mobiltelefoner, rymdteleskop och liknande enheter. Geospatial data beskriver objekt med hjälp av longitud och latitud koordinater. Geospatial data kan integreras och användas i många olika områden som bärbara sensorer, hälsodata med fler. Geospatial data är därför i behov av att kunna analyseras bättre. En nyckel till att tolka stora mängder data är visualisering. Visualisering något som alltid varit viktigt för att ge människor en förståelse för data. Kartor har i många år använts för att visualisera information om geografi och har format sättet människor ser på världen i form av fysiska och politiska kartor.
Vid visualisering av stora dataset är en del av utmaningen att hantera dess storlek medans den andra är att skapa en interaktiv och intuitiv visualisering som gör det möjligt för folk att ta till sig information. (Barik et al. 2017; Tanyalcin et al. 2018).
Ett passande sett att visualisera data på är med hjälp av webbtekniker. Kraften hos datorer och även mobila enheter har ökat samtidigt som flerkärniga processorer och gigabyte stora RAM-minnen tillåter bearbetning som tidigare gjorts på servrar. att distribueras till klientwebbläsare. Webbläsaren är idag den mest använda applikationen och ger användare tillgång till JavaScript applikationer på några sekunder. Möjligheterna med JavaScript har också vuxit under de senaste åren och idag kan en hel webbapplikation drivas med bara JavaScript. Betydande framsteg har också gjorts inom HTML, CSS och SVG standarderna vilket möjliggör rendering av grafik som kan möta sig med Java och Flash i kvalité och hastighet (Stajcer, Stajcer & Orescanin 2016).
Problemet är att visualisering av stora dataset medför en rad utmaningar som svårigheter att urskilja meningsfull information från en stor mängd data och även svårigheter i att bearbeta den. Interaktivitet kräver att data analyseras innan den visualiseras och det finns även begränsningar på hur mycket data som kan lagras i minnet vilket kan resultera i långa svarstider (Agrawal et al. 2015).
Den vetenskapliga metoden som kommer användas för att undersöka problemet är ett tekniskt experiment. Två artefakter som båda baseras på MEAN-stacken kommer skapas där ena artefakten skriver ut datapunkter på en karta skapad med Leaflet, medans den andra skapar en karta med OpenLayers. Båda artefakterna kommer att visualisera datapunkterna på kartan i form av en heatmap eller markörer. För att undersöka hur artefakterna presterar vid interaktion och utritning kommer mätningar att göras på laddningstider vid initial rendering samt zoom-in och zoom ut.
2
2
Bakgrund
Det här kapitlet presenterar relevanta begrepp och tekniker som används i arbetet.
2.1 Big Data
I dagsläget fortsätter mängden data som genereras att växa allt mer. Det resulterar i ett stort skifte kring hur teorier och teknologier hanterar data. Enligt tidigare artikel av Caldarola och Rinaldi (2017) hade 90% av all världens data vid den tidpunkten genererats under de två senaste åren. Det kan vara data från flera olika resurser som sms, internet-aktivitet, kortköp med mer (Salerno et al. 2017). Mer fokus måste läggas på hur data hanteras för att klara av den växande mängden. Flera teknologier och termer har skapats för att hantera och förstå den ökande volymen av data, en sådan term är Big Data. Det finns flera olika sätt att definiera begreppet. Ur ett teknologiskt perspektiv kan Big Data beskrivas som ”dataset vars storlek överstiger förmågan att lagra, hantera och analysera hos vanliga databasverktyg” (Caldarola & Rinaldi 2017). Andra sätt att beskriva Big Data innefattar dess egenskaper som benämns i olika former från 3V, se figur 1 för illustration, till 7V. Definitionen av 3V innefattar egenskaperna volume, velocity och variety. Volume syftar på mängden data, velocity handlar om hastigheten på data som går in samt ut och variety syftar på variationen av typerna samt källorna på data (Agrawal et al. 2015).
Figur 1
3V definitionen av Big Data
Geospatial data är en typ av Big Data som drar stor nytta av visualisering. Det är data som beskriver objekt med hjälp av longitud och latitud koordinater. Geospatial data samlas traditionellt in med fotografier, fältmätning och fjärranalys. Under de senaste åren har mängden geospatial data ökat tillsammans med en ökad mängd enheter som mobila enheter och rymdteleskop. Då visualiseringsverktygen bör vara interaktiva med låga svarstider är traditionella sätten att visualisera geospatial data är inte längre de bästa sätten att hantera den växande mängden data (Barik et al. 2017).
3
Figur 2 Användargränssnitt i GRASS GIS
I tidigare studie (Barik et al, 2017) jämförs flera olika visualiseringsverktyg för geospatial data. Verktygen som jämfördes var GeoMesa, Whitebox Gat Hadoop Viz och GRASS GIS. Se figur 2 för användargränssnitt i GRASS GISs. Verktygen som tas upp i studien är separata desktop-applikationer och körs på klient-sidan
2.2 Datavisualisering
Datavisualisering kan i stora drag beskrivas i två steg. Data förs in i minnet och därefter tillämpas en visualiseringsalgoritm (Godfrey, Gryz & Lasek 2016). Visualiseringen presenterar data i ett systematiskt mönster för att representera viktiga attribut och värden. Några av fördelarna med att använda visualiseringsverktyg är förbättrat beslutsfattande, bättre inriktad dataanalys och bättre samarbete/informationsdelning (Wang, Wang & Alexander 2015). Traditionell visualisering sker oftast i form av diagram, tabeller, bilder eller andra interaktiva metoder. Exempel på olika typer av diagram kan ses nedan i figur 3. Interaktiva metoder kan innebära möjligheten att zooma, panorera och fokusera på visst innehåll (Wang, Wang & Alexander 2015). Interaktiva visualiseringar har genom tiderna varit instrumentella inom dataanalys. Användare får en mer intuitiv förståelse för den visuella presentationen vilket gör det möjligt att snabbare hitta meningsfull information och dra slutsatser utifrån det (Godfrey, Gryz & Lasek 2016).
Figur 3 Stapeldiagram och cirkeldiagram
Visualisering av Big Data medför fler svårigheter än traditionell visualisering på grund storleken på dataseten. För att hantera visualisering av stora dataset kan viss extra
0 5 10 15
Kategori 1 Kategori 2 Kategori 3 Kategori 4 Serie 1 Serie 2 Serie 3
58% 23%
10% 9%
4
funktionalitet tas bort och geometrisk modellering användas för att reducera datastorleken innan den ska renderas. Att välja ett passande sätt att representera data är också viktigt vid visualisering av Big Data (Wang, Wang & Alexander 2015).
2.2.1 Heatmaps
Heatmaps är bred term som beskriver visualisering av data där värdena kopplas till en färg och sedan kartläggs. Det ska göra det möjligt att enklare hitta mönster och relationer i olika delar av data. Det vanligaste användningsområdet för heatmaps är representation och kartläggning av platsdata som väderinformation eller annan geografiska data (Eichinski & Roe 2014). Det finns olika variationer av heatmaps där ett exempel är clustered heatmaps. Det är en variant där data ritas ut i en matrix som visualiserar den hierarkiska strukturen i kolumner och rader. Denna typ av heatmap mest känd inom naturvetenskapen och är en av de populäraste graferna att använda inom biologi (Wilkinson & Friendly 2008).
Figur 4 Seattle Rent Heatmap av Brandon Martin-Anderson (CC BY-SA 2.0)
Något som är viktigt vid visualisering av heatmaps är densitet. Vid komplexa heatmaps används densitetsfunktioner som gör det enklare att tyda täta regioner i resultatet. I tidigare studie (Perrot et al. 2015) nämns flers metoder som ska göra det möjligt att tillåta visualisering av densitet på Big Data dataset. Sampling är en metod som innebär att datapunkter tas bort för att reducera storleken på datasetet. Clustering är en metod som istället innebär att datapunkter slås samman istället för att tas bort. Två närliggande punkter slås samman och bildar en ny datapunkt. Densitetsfunktioner har använts vid visualisering av flera olika applikationer som analys av eye-tracking data och även vid analys av geografiska data där heatmaps visas ovan på en geografisk karta (Perrot et al. 2015). Exempel på sådan visualisering finns ovan i figur 4.2.3 Visualisering på webben
Effektiv visualisering är ett viktigt verktyg för att möjliggöra beslutsfattande. Dagens webbteknologier har utvecklats och är nu utrustade med verktyg som kan mäta sig med desktop-applikationer när det kommer till interaktivitet och kraft. Webbteknologier har dock övertaget när det kommer till tillgänglighet och anpassningsbarhet (Vito et al. 2015).
5
2.3.1 Heatmap.js
Heatmap.js är ett JavaScript-bibliotek skapat av Patrick Wied. Biblioteket tillåter utvecklare att visualisera data i form av heatmaps på ett enkelt och smidigt sätt. Enligt Patrick Wied (2020) kan 2.0 releasen hantera 40k+ datapunkter. Heatmap.js finns tillgänglig i en open source version för OSS-utvecklare och en kommersiell version för företag med kommersiella produkter. Heatmap.js finns tillgänglig som plugin för Google Maps, Leaflet och OpenLayers (Wied 2020a).
Figur 5
Heatmap.js plugins enligt dokumentation
2.3.2 Leaflet .js
Leaflet.js är ett open source JavaScript bibliotek licensierat under BSD-2-Clause som skapades av Vladimir Agafonkin. Det används för att skapa interaktiva kartor, se figur 6 för exempel, och stödjer SVG rendering i Internet Explorer 7 och 8 vilket andra liknande bibliotek inte gör (Roth et al. 2015). Verktyget är även kompatibelt med både mobil och desktop-användning (Raghav et al. 2016).
Figur 6 Karta skapad med Leaftlet.js
Leaflet.js utnyttjar grundläggande webbtekniker som HTML5 och CSS3 för att möjliggöra skapandet av kartorna. Leaflet.js biblioteket delar många likheter med andra bibliotek där det krävs att användarna har grundläggande kunskap om JavaScript-programmering (Roth et al.
6
2015). Enligt tidigare studie (Raghav et al. 2016) där olika verktyg för datavisualisering jämförs, har Leaflet.js visat en mild inlärningskurva vilket kan ses som en fördel och underlätta användandet av biblioteket. En annan fördel med Leaflet.js är dess förmåga att använda tredjeparts tillägg (Ledur et al. 2015). Leaflet.js bygger i grunden på OpenStreetMap data (Caldarola & Rinaldi 2017).
2.3.3 OpenStreetMap
OpenStreetMap (OSM) är ett icke-kommersiellt projekt skapat av Steve Coast i juli 2004. OSM siktar på att skapa en gratis och licensfri karta, se figur 7, över världen genom hjälp av användare från hela jorden (Haklay 2010). Användarna gör sina bidrag till databasen via online-redigeraren på hemsidan eller via egna GPS-spår sparade från egna GPS-enheter. Företagen Yahoo! och Bing har givit OSM och dess användare tillstånd att använda deras flygbilder i sitt arbete (Mooney & Corrigan 2012).
Figur 7
Norrköping i OpenStreetMap
Data som genereras av frivilliga användare kallas Volunteer Geographical Information (VGI), en term som myntades av Michael Goodchild (2007). Han nämner också andra liknande karttjänster som bygger på samma princip, exempelvis Wikimapia.
2.3.4 OpenLayers
OpenLayers är ett open source JavaScript-bibliotek som gör det möjligt att visualisera kartdata i webbaserade applikationer. OpenLayers har förmågan att rendera vektor och raster data från olika format som bland annat GeoJSON, OGC-KML och OGC-GML vilket gör det väldigt flexibel (Zhang et al. 2016). OpenLayers separerar kartverktygen från kartdata för att verktygen ska kunna fungera på flera olika datakällor som exempelvis OGC (Open Geospatical. Consortium). OpenLayers är enkel att använda då biblioteket tillhandahåller bra dokumentation med många exempel och kräver inga beroenden på serversidan (Kulawiak et al. 2010).
7
Figur 8 Visualisering över jordbävningar med OpenLayers
OpenLayers släpptes 2006 och är licensierad under BSD-2-Clause vilket kräver att det finns ett meddelande om upphovsrätten där skaparna befrias från allt ansvar. Utöver det är det fritt att anpassa och återanvända (Ledur et al. 2015). OpenLayers stödjer hårdvaruaccelerering genom användning av WebGL (Farkas 2017). I figur 8 ovan finns ett exempel på hur en karta med heatmaps kan se ut skapad med OpenLayers.
2.4 MEAN-stack
MEAN-stacken uppkom kring 2013 som ett alternativ till den då populära LAMP-stacken bestående av Linux, Apache, MySQL och PHP. MEAN var en av de första stackarna som skiftade utvecklingen till Single-Page-Applications (SPA) och införandet av NoSQL (Bhardwaj 2018). MEAN är en samling av open source ramverk som tillsammans tillåter fullstack-utveckling. MEAN får sitt namn från följande tekniker som utgör stacken:
1. MongoDB – NoSQL databas
2. Express – Webbserver ramverk för Node.js 3. AngularJS – Frontend MVC ramverk 4. Node.js – Serverplattform
Alla tekniker i MEAN-stacken använder JavaScript som programmeringsspråk (Stajcer, Stajcer & Orescanin 2016). Användandet av JavaScript gör det bekvämt för utvecklare att använda stacken då den utgörs av bekanta koncept som JavaScript objekt och asynkrona callbacks. En annan liknande populär stack är MERN-stacken som består av MongoDB, Express, React och Node (Aggarwal & Verma 2018).
2.4.1 MongoDB
Uppkomsten av Big Data har exponerat flera begränsningar som finns inom traditionella relationsdatabaser. Det kan vara allt från hanteringen av komplexa dataformat till skalbarhet och flexibilitet då mängden data fortsätter växa och bli allt mer oenhetlig. För att hantera icke-flexibla data har NoSQL-databaser börjat användas. NoSQL-databaser använder inte
8
fördefinierade scheman som bestämmer enligheten på data som ska lagras vilket innebär att databasen kan uppdateras och ändras med tiden (Vitolo et al. 2015).
Figur 9 Illustration av NoSQL databastyper
Det finns tre olika typer av NoSQL-databaser — nyckelvärden (key-value stores), dokument - och kolumnorienterade databaser, se figur 9 för en illustration. De olika typerna syftar på hur data lagras i databasen. I key-value stores används key-value pairs för att lagra data. I dokument databaser lagras data i mer komplexa strukturer, oftast XML dokument. Kolumnorienterade databaser lagrar tabeller i sektioner av en kolumn istället för rader (Kang et al. 2016). Tack vare sin flexibilitet kommer användandet av NoSQL-databaser att öka allt mer och i en marknadsundersökning av IT-konsultfirman Gartner från 2013 låg fem NoSQL databaser i topp på mest använda ODMS (operational database management systems), där MongoDB var den mest populära (Feinberg, Heudecker & Adrian 2013)
MongoDB är en open source NO-SQL databas skriven i C++ och skapad av 10gen år 2007. MongoDB tillhör typen dokumentorienterade databaser, vilket innebär att data lagras i dokumentform, oftast XML eller JSON. Dokumenteten identifieras av en unik nyckel som används för att komma åt data.
Figur 10 Datalagring i relationsdatabas vs MongoDB
Två viktiga egenskaper hos MongoDB är hållbarhet och samtidighet (durability och concurrency). Hållbarhet uppnås med hjälp av backuper. MongoDB använder en mekanism kallad Master-Slave replication vilket innebär att Master kan skriva och läsa filer medans Slave
9
agerar som en asynkron backup. I händelse av att en Master går ner kommer den Slave med den mest uppdaterade informationen ta över och bli en Master (Abramova & Bernardino, 2013).
Enligt en tidigare studie (Nyati, Pawar & Ingle 2013) där MongoDB och MySQL jämförts med varandra visade sig MongoDB vara markant bättre vid sökande och infogning av data. Åtkomsthastigheten vid hämtande av data har också visat sig vara bättre hos MongoDB. När datamängden överstiger 50GB är åtkomsthastigheten 10 gånger snabbare med MongoDB jämfört med MySQL (Han et al. 2011). I figur 10 illustreras skillnaden i datalagring mellan relationsdatabas och MongoDB.
2.4.2 Express.js
Express.js är ett ramverk som bygger vidare på Node.js för att ge utvecklare möjligheten att hantera routing och HTTP-operationer som GET och POST (Poulter, Johnston & Cox 2015).
Figur 11 Exempel på routing i Express.js
Det finns flera ramverk som kan hantera routing i Node.js men den mest robusta är Express.js (Schutt & Balci 2016). Schutt och Balci (2016) nämner också att Jade är ett bra exempel på en template-motor som kan användas för att hantera HTML-dokument med Express.js, men att sådan motor inte behövs när klienten använder en data-driven template-motor som Angular.js
.
2.4.3 Angular.js
Angular.js är ett open source ramverk utvecklat och upprätthållet av Google. Angular.js använder sig av MVC-strukturen, se figur 12 för illustration, vilket innebär att utvecklingen bygger på tre huvudsakliga byggstenar – model, view och controller, men andra delar som moduler, direktiv, filrer och tjänster är också fundamentala för att utgöra en Angular app (Stajcer, Stajcer & Orescanin 2016).
//--- // Routing to Leaflet Map
Router.get(‘/leaflet, function(req, res, next)){
res.render(‘leaflet’);
});
//--- // Routing to OpenLayers Map
Router.get (‘/openlayers’, function(req, res, next)){
res.render(‘ol’);
10
Figur 12 MVC struktur i Angular.js
Enligt Aggarwal och Verma (2018) är fördelarna med Angular.js många. Fördelar som exempelvis tvåvägsdatabindning vilket innebär automatisk synkronisering mellan model och view komponenterna. Aggarwal och Verma (2018) nämner också att Angular.js är enkelt att integrera med REST vilket tillåter applikationen att interagera med servern och hämta den data som behövs för att interagera med webbsidorna.
2.4.4 Node.js
Node.js är ett open source projekt skapat av Ryan Dahl 2009. Node.js är en JavaScript miljö för server-sidan som är skrivet i C och C++ samt är baserad på Googles V8-motor (Jiang, Zhou & Zhang 2015). Tillskillnad från andra moderna utvecklingsmiljöer använder Node.js inte flertrådning (
multithreading) för att hantera utförandet av flera händelser samtidigt, istället
bygger Node.js på en asynkron event-driven modell med stöd för callbacks. Det innebär att när en i/o-händelse (input/output event) som exempelvis ett knapptryck eller att browsern laddar ett dokument fullbordas så triggas en callback (Jiang, Zhou & Zhang 2015; Tilkov & Vinoski 2010). Se figur 13 nedan för illustration av callbacks i Node.js. Det tillåter annan kod att köra undertiden och förhindrar att programmet blockeras.
Figur 13 Node.js callbacks
Node.js är ett av de mer kända ramverken som stödjer JavaScript utveckling för server-sidan. Tack vare dess popularitet har ett ekosystem av andra bibliotek skapats som är kompatibla med Node.js. Flera verktyg som node-mysql och node-counchdb tillåter en asynkron
11
interaktion med olika typer av databaser. Tillsammans med ramverk som exempelvis Connect och Express erbjuds en fullständig webbstack som kan jämföras med Rack och Rails för Ruby i omfattning (Tilkov & Vinoski 2010).
2.5 Relaterad/tidigare forskning
I en italiensk teknisk rapport publicerad i Rapporti Tecnici INGV utförs ett experiment som använder liknande tekniker som kommer att användas i det här arbete. D’Auria och Giudicepietro (2013) undersöker om det går att använda Twitter data för att förutspå jordbävningar. Studien använder geospatial data i from av jordbävningar som visualiseras på en interaktiv karta skapad med Google Maps API. Kartan tillåter interaktion i from av bland annat markörer som användaren kan klicka på för att få mer information om twitter-inläggen samt jordbävningen som inträffade. D’Auria och Giudicepietro använder Google Maps API Heatmaps för att skapa olika färglager. Lagren ska göra det enklare för användaren att identifiera huruvida en jordbävning kan ha registrerats av Twitter-användare eller inte. Cyan lager indikerar att en jordbävning kan ha känts av, blå lager indikerar att det var större chans att en jordbävning kändes och röd färg betyder att en jordbävning med största sannolikhet känts av.
12
3
Problemformulering
Big Data medför många möjligheter inom olika branscher som exempelvis handel, forskning och finans. I USA har flera myndigheter uttryckt ett intresse för att arbeta med mer Big Data, då det finns nytta i att kunna analysera stora mängder data för att kunna underlätta och hjälpa företag i beslutsfattande syften (Chen & Zhang 2014). Enligt studien av Chen och Zhang (2014) ansåg 50% av 560 företag att Big Data skulle kunna hjälpa dem med bland annat ökad produktivitet i företaget.
För att informationen från Big Data ska kunna vara till nytta behöver den göras tillgänglig att företag eller andra aktörer kan förstå den. Visualisering av stora dataset medför en rad olika utmaningar. De traditionella sätten att visualisera data medför utmaningar som exempelvis perceptuell skalbarhet (perceptual scalability), skalbarhet i realtid (real-time scalability) och interaktiv skalbarhet (interactive scalability). Perceptuell skalbarhet syftar på hur data uppfattas av människan. Vid visualisering av mycket information kan människans öga ha svårigheter med att urskilja mönster samt vad som är meningsfull information. Begreppet kan även syfta på begränsningar hos skärmarna där data visualiseras. I dataset med många datapunkter kan resultatet bli för tätt för en användare att urskilja resultatet. Både skalbarhet i realtid och interaktiv skalbarhet syftar på svårigheterna att bearbeta den stora mängden data som Big Data medför. Interaktivitet kräver att data analyseras innan den visualiseras och data som ska visualiseras i realtid har begränsningar på hur mycket data som kan lagras i minnet. Denna begränsning kan resultera i långa laddningstider hos för stora dataset (Agrawal et al. 2015).
Skalbarhet i realtid och interaktiv skalbarhet kommer användas som referens vid mätningarna på applikationerna som ska byggas för att säkerställa vilken variant är mest lämpad till att visualisera stora datamängder.
3.1 Syfte och frågeställningar
Syftet med arbetet är att analysera laddningstider och utritningstider hos en interaktiv karta som visualiserar Big Data med hjälp av webbtekniker. Webbtjänster gör applikationer mer tillgängliga då användandet av etablerade internetstandarder kan tillåta sammankoppling av olika system (Vitolo et al. 2015). Då många visualiseringsverktyg som finns för Big Data, exempelvis GeoMesa, Whitebox Gat Hadoop Viz och GRASS GIS som nämnes tidigare, är applikationer som körs på klient-sidan för att sedan exportera slutresultaten är det av intresse att skapa en applikation där visualiseringsverktyget är webbaserat. I en relaterad studie av Szuba et al. (2016) visualiserades Big Data i from av information från satelliter var jobb är att observera jorden. För att skapa en applikation för att lagra, hantera och visualisera satellitdata valde Szuba et al. (2016) att använda sig av MEAN-stacken på grund av dess höga prestanda och skalbarhet.
Teknikerna som kommer mätas är Leaflet och OpenLayers. Anledningen till att JavaScript-biblioteken har valts är på grund av att OpenLayers använder datorns GPU vid visualisering och Leaflet erbjuder valet att stänga av användandet av hårdvaruaccelerering. Det möjliggör en jämförelse av hur stor inverkan hårdvaruaccelerering har på hur artefakterna presterar. Enligt tidigare studie av (Wang et al. 2018) där iClient, ett ramverk som integrerar Leaflet, OpenLayers och MapBox GL med D3.js, ECharts och DECK.GL, jämförs med Leaflet
13
respektive OpenLayers för att se vilket av verktygen som är effektivast när det gäller att rendera datapunkter. Resultaten visade att ett tillvägagångssätt med hårdvaruaccelererad GPU presterade bättre än ett CPU baserat tillvägagångssätt för att rita ut en stor mängd datapunkter. Zhao, Yao, Gao och Guan (2018) menar att det också finns nackdelar med att använda GPU:n, det kan vara exempelvis svårigheter med att fördela resurserna och försämring av prestanda.
Då det finns forskning som talar både för och emot användandet av hårdvaruaccelererade lösningar är det av intresse att jämföra en hårdvaruaccelererad applikation som använder sig av datorns GPU mot en applikation som endast använder datorns CPU. Den hårdvaruaccelererade applikationen som kommer byggas är baserad på OpenLayers och den CPU baserade applikationen kommer skapas med Leaflet.js.
3.1.1 Frågeställningar
Arbetet avser att besvara följande frågeställningar:
• Vilket JavaScript-bibliotek har snabbast laddningstid vid interaktion med applikationen?
• Vilket JavaScript-bibliotek har snabbast laddningstid vid utritning av datapunkter i applikationen?
3.2 Hypotes
H0: Baserat på resultatet i studien av (Wang et al. 2018) där det hårdvaruaccelererade
tillvägagångssättet med OpenGL presterade bäst vid utritning av många datapunkter så kommer JavaScript-biblioteket OpenLayers att prestera snabbast sett till laddningstider. Det då OpenLayers är baserat på WebGL som i sin tur baseras på OpenGL.
a) JavaScript-biblioteket OpenLayers kommer att prestera snabbare sett till laddningstid vid utritning av datapunkter än Leaflet, mätt i millisekunder.
b) JavaScript-biblioteket OpenLayers kommer att prestera snabbare sett till laddningstid vid interaktion med applikationen än Leaflet, mätt i millisekunder.
H1: JavaScript-biblioteket Leaflet.js kommer att prestera snabbast sett till laddningstider.
3.3 Delmål
För att underlätta att undersöka frågeställningarna sätts följande delmål: • Hitta ett passande dataset som inte innehåller data om människor. • Bestämma vilken av utmaningarna med Big Data som ska testas först. • Fastställa hur laddningstider i applikationen vid interaktion ska mätas. • Fastställa hur användarnas uppfattningar kring visualiseringen ska mätas.
• Utveckla en interaktiv karta som visualiserar datapunkter med vardera JavaScript-biblioteket.
• Skapa script för att kunna utföra mätningar på laddningstider. • Utföra mätningar och lagra värdena.
• Sammanställa mätningarna i grafer.
14
4
Metod
För att undersöka huruvida hypotesen är korrekt eller ej kommer ett experiment genomföras där flera datapunkter från ett stort dataset kommer att laddas in på en interaktiv karta. Två variationer av samma applikation kommer att byggas för att mäta hur Leaflet och OpenLayers hanterar visualisering av stora datamängder. Upplägget kan liknas vid vad Wohlin et al. (2012) beskriver som ett teknologi-orienterat experiment, då det mäter två olika verktyg som appliceras på samma program. Applikationen kommer att vara en interaktiv karta som renderar datapunkter i form av heatmaps. Kartan kommer vara interteraktiv vilket innebär att användare kan panorera, zooma och interagera med kartan på olika sätt. Experiment är metoden att föredra för det arbete som ska utföras i denna rapport, då det tillåter kontroll över miljön och de faktorer som kan påverka utfallet. Metoden passar bra för att exempelvis testa om olika teorier stämmer (Wohlin et al. 2012), vilket är syftet med det här experiment. Se figur 14 för en översikt över hur mätningarna vid interaktion ska genomföras.
Figur 14 Flödesschema för mätning av renderingstider vid interaktion
4.1 Etiska aspekter
Experimentet som kommer utföras involverar inte människor eller djur som försökspersoner vilket kan medföra flera etiska aspekter att ha i åtanke, men resultaten och artefakten kommer att vara tillgängliga för allmänheten att inspektera. Ett av de största problemen med benchmark-tester idag är att dataseten som ska användas oftast är kända i förväg. I och med det kan resultaten medvetet eller omedvetet påverkas genom att testobjektet optimeras specifikt för de kommande testerna (Cai, Nerurkar & Wu 1998).
Det är alltså av största vikt att vara transparent med resultaten och hur de erhölls. Både för att arbetet ska kunna replikeras i framtiden och för att visa att resultaten inte fabriceras på något sätt. Koden för artefakten kommer att finna tillgänglig på GitHub och rapporten med resultaten kommer att bli en offentlig handling.
Den data som används får inte vara sekretessbelagd, den måste vara tillgänglig för allmän användning och känsliga data som lösenord eller liknande får inte förekomma på något sätt (Wohlin et al. 2012).
Hade experimentet involverat att användare deltog i en användarstudie som exempelvis en enkät hade flera etiska aspekter behövts respekteras. Enligt Kelley, Clarke, Brown och Sitzia (2003) finns två etiska aspekter som bör följas vid användning av enkäter, konfidentialitet och informerat samtycke. Deltagarnas rätt till att vara anonyma ska alltid respekteras och deltagarna ska informeras om enkätens syfte. Samtyckte om att delta i enkäten bör erhållas i inspelat eller skriftligt format (Kelley et al. 2003).
15
4.1.1 Etik inom Big Data
När det kommer till hantering av Big Data finns det också några etiska aspekter ta i bejakande. Boyd och Crawford (2012) menar att bara för att Big Data är tillgänglig är den inte etisk. I en studie från 2006 samlade en forskningsgrupp från Harvard in data från 1600 användare för att studera hur deras intressen och relationer förändrades över tiden. All data som samlades in släpptes till världen, till synes anonym, för forskare att arbete vidare på. Forskare upptäckte snabbt att det gick att ta fram information från delar av datasetet vilket äventyrade användas integritet. Forskare ställdes inför frågeställningar som ”Hur specificeras integritetsbrott? När är skadan skedd? Vid tidpunkten data släpps eller om flera år i framtiden?” All data innehållande information om människor kommer oundvikligen att medföra problem kring integritet som är svåra att kvantifiera (Boyd & Crawford 2012). För att undvika sådana typer av problem kommer datasetet som används i arbetet inte innehålla data om människor. En annan etisk aspekt att ha i åtanke vid användande av Big Data är kontexten data används i. Data kan användas och analyseras i många olika kontexter vilket kan resultera i att innebörden ändras eller försvinner helt. Vad kan vara konsekvensen av att en användares blogginlägg tas och analyseras i en kontext som bloggaren aldrig tänkte sig? Då data i stora dataset ofta innefattar många olika deltagare uppstår svårigheter när det kommer till att be om deras samtycke till att deras information eller handlingar samlas in till dataset (Boyd & Crawford 2012). Arbetet som ska utföras i denna rapport kommer inte infatta någon datainsamling till ett dataset, men för att undvika att stöta på några av de etiska aspekterna som nämns är det viktigt att vara extra noga vid val av dataset. Det bör inte innehålla data om människor och det är viktigt att använda datasetet i den korrekta kontexten det var ämnat för.
4.2 Alternativa metoder
En alternativ metod som kunde använts i arbetet är fallstudier. Fallstudier är en observationsstudie där data samlas in genomgående genom hela studien för sedan kunna utföra statistiska analyser. En fallstudie utförs oftast på plats där objektet som undersöks befinner sig i sin rätta kontext Fallstudier är lämpade till att utvärdera metoder och verktyg inom software engineering då de kan användas till att undvika uppskalningsproblem (Wohlin et al. 2012). Wohlin et al. (2012) beskriver också att fallstudier ska användas till att utvärdera skillnader mellan två metoder för att komma fram till vilken som är mest lämpad för en specifik situation. Anledningen till att fallstudie inte använts som metod i arbetet är på grund av att metoden inte tillåter samma typ av kontroll som experiment. Då det även hade varit en fördel att testa applikationerna som ska skapas i ett verkligt sammanhang är det svårt att åstadkomma för det här arbete.
En ytterligare metod som är av intresse att använda i ett framtida arbeta är en användarstudie. För att mäta perceptuell skalbarhet skullen en användarstudie i form av en enkät kunna utföras där deltagarna får besvara frågor om hur datavisualiseringen uppfattas. En enkät används för att få en uppfattning om användares beteenden, kunskap eller attityd. Att använda enkät som en ytterligare metod för att mäta användarnas upplevelse av applikationen är passande då Wohlin et al. (2012) beskriver att enkäter används för att undersöka hur en teknik eller ett verktyg har upplevts efter det används ett tag. Frågorna i enkäten kan be deltagarna att reflektera över hur tydligt datavisualiseringen uppfattades samt hur applikationens interaktivitet upplevdes. Wohlin et al. (2012) understryker att det är viktigt att enkäten inte innehåller för många frågor då kvalitén på deltagarnas svar kan minska när enkäten blir för
16
tidskrävande. Se figur 15 för en överblick över hur mätning av perceptuell skalbarhet skulle kunna genomföras.
17
5
Genomförande
I kommande kapitel kommer en pilotstudie utföras för att undersöka om experimenten och mätningarna är möjliga att genomföra på en större skala. För att göra det möjligt att replikera experimentet kommer arbetets progression att redovisas. Källorna som använts för att hämta mer kunskap inför implementationen redovisas också i form av en litteraturstudie.
5.1 Litteraturstudie
I rapportens metod sattes kravet att data som ska användas i experimentet inte får innehålla någon information om människor för att undvika problem kring etiska aspekter som kan uppstå. Ett av delmålen som sattes i början av rapporten var också att hitta ett data set som inte innehåller någon data om människor. Ett dataset innehållande globala översvämningar från 1985 - 2019 hittades på Data World (2018). Det innehåller bland annat information om i vilket land översvämningen ägde rum, samt longitud och latitud koordinater vilket var ett krav för att datapunkterna skulle kunna ritas ut i artefakten.
För att förstå hur Node.js och Express.js fungerade användes bland annat en instruktionsfilm från YouTube (2016). Videon visade allt från installation samt hur Express.js kopplades samman med MongoDB. Express.js (2020) dokumentation användes för att förstå saker som routing och Express.js allmänna struktur.
Kunskap kring installationen av databasen hämtades främst från dokumentationen från MongoDB (2020a). För att koppla ihop databasen med artefakten användes W3Schools (2020) som kunskapskälla för att se kodexempel på hur det kan se ut. När det sedan var dags att föra in all data från datasetet till databasen användes instruktionsfilmer från YouTube (2018) för att se hur CSV-filer importerades till MongoDB.
För att skapa kartan där datapunkterna ska ritas ut användes Leaflet. Kunskap kring hur Leaflet fungerar hämtades främst från Leaflets egna dokumentation (Leaflet 2020). I dokumentationen finns information om hur olika kontroller implementeras för att göra kartan mer interaktiv samt hur datapunkter kan skrivas ut med hjälp av longitud och latitud koordinater.
Den andra version av artefakten ritar istället ut en karta med OpenLayers. För att komma igång användes OpenLayers (2020a) dokumentationen med exempel samt StackOverflow (2017) för att förstå problem som uppstod.
Vid implementeringen av Tampermonkey script för att skicka laddningstiderna till en textfil på wwwlab-servern hade kunskap erhållits från tidigare kursmoment. Detsamma gäller pyton-scriptet som sedan används för att skapa grafer baserat på textfilen. Scriptet för att samla in laddningstiderna är också baserat på kursinnehåll från föregående kurs där kursmomentet krävde mätning av laddningstider. När ikonen för OpenLayers markören skapades användes också kunskap från föregående kurser där kursmomenten täckte Illustrator verktygen till den utsträckning som behövdes för arbetet i artefakten.
Böcker är en kunskapskälla som finns tillgänglig men inte använts under arbetet. O’Reilly är en källa som erbjuder många böcker om flera av teknikerna som används i artefakten. Böcker
18
som exempelvis MEAN Web Development (Haviv 2016) och Full Stack JavaScript Development With MEAN (Ihrig & Bretz 2015) finns tillgängliga att köpa via O’Reillys webbshop. Trots att böcker som nämnts ovan är en bra källa att skaffa information från har det valts bort. Anledningen är att den kunskap som behövdes för artefakten inte var tillräckligt djupgående och fanns tillgänglig gratis på internet. Risken finns också att information från böcker refererar till gamla versioner av program och kan i vissa aspekter vara utdaterade. Information från forum eller liknande på internet är enklare att uppdatera i efterhand tillskillnad från böcker.
5.2 Implementation
För att skapa artefakten som ska mätas i experimentet behövde implementationen ske i olika steg. I kommande kapitel kommer arbetsprocessen för alla delmoment förklaras för att tydliggöra hur den slutgiltiga artefakten skapades. Samtlig källkod finns publicerad på GitHub samt sammanställd i appendix.
För att driva Leaflet och OpenLayers artefakterna kommer tre av fyra webbtekniker från MEAN-stacken att användas. Angular.js kommer inte att användas för att bygga artefakten i arbetet. Aggarwal och Verma (2018) nämner att några nackdelar med Angular.js är att det är stort och komplext vilket innebär att det kan vara svårt och tidskrävande att bemästra. Då arbetet inte kräver Angular.js för artefaktens front-end har ett avvägande gjorts gällande Angular.js och dess för och nackdelar. Beslutet blev att utesluta Angular.js då nackdelarna överväger fördelarna för arbetes omfattning.
5.2.1 Dataset
Studiens dataset inte var bestämt innan implementationen påbörjades vilket gjorde att första steget blev att hitta ett passande dataset. Ett av delmålen som sattes i början av rapporten var att datasetet inte skulle innehålla någon information om människor. För att kunna rita ut datapunkter på artefaktens karta behövde också datasetet innehålla latitud och longitud koordinater. Därför valdes tillslut ett dataset om globala översvämningar på grund av att det inte innehöll någon information om enskilda människor samt inkluderade koordinater. Nästa steg blev därefter att konvertera datasetet till en CSV-fil då nedladdningen av datasetet skedde i DBF-format. För att kunna använda MongoDBs inbyggda kommande mongoimport till att importera en CSV-fil användes en online-konverterare rebasedata.com (2020) som konvertererade DBF-filen till CSV-format. Därefter användes kommandot mongoimport för att ladda in all data i databasen. Se figur 16 för kommando.
Figur 16 Import av CSV-fil
//--- Import file Floods.CSV into database test in collection Floods
//---
mongoimport -d test -c Floods –type CSV –file Floods.CSV --headerline
19
5.2.2 Node.js
Node.js installerades från nodejs.org (2020). I samma nedladdning installerades också Node Package Manager (NPM) som används under hela arbetet för att ladda ner och hantera paket eller beroenden som behövs för att skapa artefakten.
5.2.3 Express.js
Express installerades med hjälp av npm som även användes till att generera Express strukturen, se figur 17 för kommando.
Figur 17 Installation och generering av Express med npm
Express genereringen resulterar i en grundläggande struktur (figur 18) för en startklar Express app. En template-motor inkluderas också i genereringen och kommer användas istället för Angular.js för att hantera HTML på artefaktens front-end.
Figur 18 Illustration av den genererade strukturen i express
Det första som behövde ordnas i Express var sedan routingen för OpenLayers och Leaflet. En väg skapades för Leaflet respektive OpenLayers med router.get(), se figur 19 för implementerad kod.
//--- // Express installation with npm
//---
$ npm install express –-save
//--- // Generate Express files
//---
$ npm install -g express-generator $ express
20
Figur 19 Routing i index.js
15.2.4 MongoDB
MongoDB hämtades hem från MongoDB.com (MongoDB 2020b). Därefter sköttes installationen via terminalen med pakethanteraren Homebrew enligt dokumentationen. En databas kallad test skapades genom en anslutning i terminalen med hjälp av kommandot use test. Då det inte fanns någon databas med det namnet skapades en ny. För att verifiera att en databas med namnet test skapades användes kommandot show dbs vilket resulterade i följande output i figur 20.
Figur 20 Resultat av show dbs
Efter databasen skapats behövdes en ny collection läggas in för att sedan kunna importera CSV-filen med det valda datasetet. Det gjordes på följande sätt i figur 21 nedan.
Figur 21 Skapande av Floods collection
Därefter kunde CSV-filen innehållande data om översvämningar importeras in, se föregående figur 16.
Anslutningen till databasen i artefakten görs i data.js-filen, se figur 22 för kod. En route skapas med endpointen /data där data hämtas från MongoDB och returneras som JSON med res.json() funktionen.
1https://github.com/a17alian/exjobb_2020/commit/251ecc2
//--- // Routing to Leaflet Map
Router.get(‘/leaflet, function(req, res, next)){ res.render(‘leaflet’, {Title: ‘Leaflet Map’});
});
//--- // Routing to OpenLayers Map
Router.get (‘/openlayers’, function(req, res, next)){ res.render(‘ol’, {Title: ‘OpenLayers Map’} );
}); ➢ Show dbs admin 0.000GB config 0.000GB local 0.000GB test 0.000GB ➢ >db.createCollection(“Floods”) {“ok”: 1}
21
Figur 22 Databasanslutning i data.js
5.2.5 Heatmap med Leaflet.js
För att kunna använda data som ligger i MongoDB databasen måste den hämtas till klientsidan. Med hjälp av AJAX görs en förfrågan till /data endpointen som hämtar in resultatet till Leaflet.js filen där koden för Leaflet kartan hanteras. Vid en lyckad AJAX-förfrågan kallas funktioner för att rita ut resultaten på kartan. I figur 23 kallas
generateMarkers() och generateHeatmap()som ritar ut lagren för markeringar och
heatmaps i Leaflet kartan.
Figur 23 AJAX-förfrågan i leaflet.js filen
Då Leaflet inte har en inbyggd funktion för att skapa heatmaps används en plugin kallad heatmap.js som rekommenderas av Leaflet i dokumentationen. Enligt heatmap.js dokumentationen behöver scriptet för heatmap.js filen laddas ned och även plugin scriptet till Leaflet. I figur 24 nedan länkades heatmap.js scriptet i headern medans plugin-scriptet placeras i dokumentets footer.
/* GET data listing. */
router.get('/', function(req, res, next) { var MongoClient = mongodb.MongoClient; var url = 'mongodb://localhost:27017/test';
MongoClient.connect(url,{useUnifiedTopology: true,useNewUrlParser: true,}, function(err, db) { if (err) throw err;
var dbo = db.db("test");
//Find all in the floods collection: dbo.collection("floods").find({}).toArray(function (err, result) { if(err){ res.send(err); } else { res.json(result); } //Close connection db.close(); }); }); }); $.ajax({ url: "http://localhost:3000/data", type: 'GET',
dataType: 'json', // added data type success: function(res) {
generateHeatmap(res); generateMarkers(res); }
22
Figur 24 Heatmap.js script i Leaflet.jade filen
Funktionen som ritar ut heatmaps tar resultatet från AJAX-förfrågan och går igenom det med en for loop. Värdena för latitud och longitud läggs in i objektet heatmapObj som därefter pushas in i coordsData arrayen. För varje datapunkt skapas alltså ett nytt objekt som pushas in i arrayen, se figur 25.
Figur 25 Grundkod för heatmap med Leaflet
2Lagret för heatmappen läggs sedan till i kartobjektet, se fullständig kod i Appendix E. Det slutliga resultatet av implementationen av en heatmap skapad med Leaflet kan ses i
Appendix O.
5.2.6 Heatmap med OpenLayers
OpenLayers API tillhandhåller heatmaps vilket innebär att en plug-in inte är nödvändig. OpenLayers läser in olika former av JSON som TileJSON, GeoJSON eller TopoJSON. Därför behöver den JSON-data som hämtas från MongoDB först göras om till något av dessa format. I figur 26 nedan skapas två objekt, geojsonObject och marker som tillsammans ska utgöra strukturen av ett GeoJSON -objekt.
2https://github.com/a17alian/exjobb_2020/commit/9b0f8f4
//--- // Heatmap.js script in header
//---
head
script(src='/javascripts/heatmap.js')
//--- // Heatmap.js plugin script in footer
//--- footer script(src="https://raw.githack.com/pa7/heatmap .js/develop/plugins/leaflet-heatmap/leaflet-heatmap.js") var coordsData = { max: 8, data: [] }; var heatmapObj = {};
var heatmapLayer = new HeatmapOverlay(cfg);
function generateHeatmap(floods){
for(var i = 0; i < floods.length; i ++){ heatmapObj[i] = {lat: floods[i].lat, lng: floods[i].long}
coordsData.data.push(heatmapObj[i]); }
heatmapLayer.setData(coordsData); }
23
Figur 26 Struktur för GeoJSON-objekt
Vid en lyckad AJAX-förfrågan kallas funktionen generateHeatmmap(), se figur 27, som tar det returnerade resultatet som en parameter och tilldelar latitud och longitud koordinaterna till marker objektet för att sedan pusha in det i feature arrayen i geojsonObject. Därefter returneras geojsonObject innehållande all ny GeoJSON data.
Figur 27 Koordinater till GeoJSON
Efter att objektet geojsonObject har returnerats används det vid skapandet av variabeln vectorSource som sedan används som datakälla i variabeln vector för heatmap lagret, se figur 28
Figur 28 Skapande av vectorSorce
Resultatet av implementationen av heatmap med OpenLayers kan ses i Appendix
Q.
var geojsonObject = { "type": "FeatureCollection", "features": [] }; var marker = { "type": "Feature", "properties": {}, "geometry": { "type": "Point", "coordinates": "", } }; function generateHeatmap(floods) { for(var i = 0; i < floods.length; i ++){marker[i] = {type: 'Feature', properties: {}, geometry: { type: 'Point', coordinates:
ol.proj.fromLonLat([floods[i].long, floods[i].lat])}}; geojsonObject.features.push(marker[i]);
}
return geojsonObject };
var vectorSource = new ol.source.Vector({ features: new
ol.format.GeoJSON().readFeatures(geojsonObject) });
var vector = new ol.layer.Heatmap({ source: vectorSource,
radius: 12, opacity: 0.6, });
24
5.2.7 Markörer med Leaflet
Skapandet av datapunkter i from av markörer använder liknande kod som för skapandet av heatmaps i föregående figur 27. Skillnaden är att ett Leafet marker-objekt istället används i for loopen samt en tillhörande popup som tilldelas mer data från databasen. Markör objektet läggs sedan till i markers som är en LayerGroup(), se figur 29 för kodexempel.
Figur 29 Markörer i Leaflet
Lagret med markörerna läggs sedan till i Leaflets kontroller, se fullständig k0d i Appendix E och en bild på hur artefakten med markörerna skapad i Leaflet kan ses i Appendix N.
5.2.8 Markörer med Openlayers
Implementationen av markörer i OpenLayers skedde i ett flertal steg med olika element. På grund av att OpenLayers inte har något inbyggt markör-element används istället ikon-elementet i figur 30. I ikon-elementet används markör ikonen från Leaflet i form av en png-fil för att få utseendet mellan artefakterna så likvärdigt som möjligt.
Figur 30 Kod för Ikon-element
Därefter används generateMarkers funktionen för att fylla arrayen iconFeature med objekt innehållande information från databasen. Funktionen har samma namn och liknande struktur som motsvarande funktion i Leaflet men inte samma kod, se figur 31.
var markers = L.layerGroup(); function generateMarkers(floods){
for(var i = 0; i < floods.length; i ++){
marker = L.marker([floods[i].lat, floods[i].long]).bindPopup( '<h3> ' + floods[i].country + ' </h3>' + 'Cause: ' + floods[i].maincause + '<br>' + 'Dead: ' + floods[i].dead + '<br>' + 'Began: ' + floods[i].began + '<br>' + 'Ended: ' + floods[i].ended); markers.addLayer(marker); } }
var iconStyle = new ol.style.Style({ image: new ol.style.Icon({
anchor: [0.5, 46], anchorXUnits: 'fraction', anchorYUnits: 'pixels', scale: 0.5, src: '../leaflet_icon.png' }) }); var iconFeatures = [];
25
Figur 31 generateMarker funktion i OpenLayers
För att ytterligare göra artefakterna mer likvärdiga implementeras en popup för OpenLayers. Markörerna som skapas i OpenLayers ger inte möjlighet till att inkludera en popup. Därför skapas först ett overlay-element kallat popup som använder en div med id popup som källa för att skriva ut informationen, se Appendix D.
I figur 32 nedan illustreras koden som behövs för att popup-elementet ska visas när användaren klickar på kartan. OpenLayers funktionen forEachFeatureAtPixel detekterar features som korsars i den pixel som klickas på i kartan och returnerar den. Därefter används två if-satser där den första kollar om en feature har klickats på och om så är fallet kollar den andra if-satsen om markör-lagret är det som är i klickat. Det görs för att undvika att popup-elementen dyker upp med odefinierade värden om användaren klickar på kartan när heatmap lagret är aktivt.
Figur 32 Kod för att visa popup vid klick
Om markörlagret är aktivt hämtas geometrin och koordinaterna för den feature som klickats och skriver ut all information i popup innehållet.
function generateMarkers(floods) {
for(var i = 0; i < floods.length; i ++){
var iconFeature = new ol.Feature({geometry: new
ol.geom.Point(ol.proj.fromLonLat([floods[i].long, floods[i].lat])), country: floods[i].country, cause: floods[i].maincause, dead: floods[i].dead, began: floods[i].began, ended: floods[i].ended });
iconFeature.setStyle(iconStyle); markerSource.addFeature(iconFeature); } // for loop end
}
map.on('click', function(evt) {
var feature = map.forEachFeatureAtPixel(evt.pixel, function(feature) {
return feature; });
if (feature) {
if($('input[type=radio][name=layers]:checked').attr('id') == 'markers'){ var coordinates = feature.getGeometry().getCoordinates();
popup.setPosition(coordinates); $(element).popover({
placement: 'top', html: true,
content: '<h5>' + feature.get('country') + '</h5>' + '<div> Casue: ' + feature.get('cause') + '</div>' + '<div> Dead: ' + feature.get('dead') + '</div>' + '<div> Began: ' + feature.get('began') + '</div>' + '<div> Ended: ' + feature.get('ended') + '</div>' }); $(element).popover('show'); } } else { $(element).popover('destroy'); } });
26
Artefakten för implementationen av markörer med OpenLayers kan ses i Appendix
P.
5.2.9 Mätscript
Mätningen av renderingstiderna använder Date.Now()för att samla in tiden från att data framgångsrikt hämtats från MongoDB till att funktionen som ritar ut heatmaps har körts klart. I figur 33 nedan används beforeSend tillsammans med Date.Now()för att spara tiden före AJAX-förfrågan görs. Värdet sparas sedan som en variabel i local storage.
Figur 33 beforeSend med Date.now()
När generateHeatmap() har laddat klart kallas print_time()funktionen och en ny Date.Now()kallas och skickas in i funktionen. Se figur 32 nedan för hur funktionen ser ut. Funktionen kollar om arrayen innehållande laddningstiderna är mindre än tio, ska tiderna fortsättas läggas in. När tio tider lagts in innehållet rensas local storage. Just talet tio användes under testningen av koden och pilotstudien. Den siffran kommer att varieras i det slutliga experimentet där större mängder tester kommer att genomföras. Den sparade tiden hämtas och tillsammans med sluttiden räknas variabeln measurement ut. Variablen innehåller tiden det tog för data att hämtas och skrivas ut i en heatmap. Tiden sparas i local storage och skrivs även ut i en div på sidan för att göra det möjligt för Tampermonkey scriptet att få tillgång till värdena.
Figur 34 Uträknande av laddningstid för heatmap generering
$.ajax({url: "http://localhost:3000/data", type: 'GET',
dataType: 'json', // added data type beforeSend: function(){
// get time before GET let get_time = Date.now();
localStorage.setItem("get_time", get_time); },success: function(res) { generateHeatmap(res); generateMarkers(res); } }); function print_time(end_time){ if(array_data.length < 10){
var stored_time = localStorage.getItem("get_time"); var measurement = (end_time - stored_time);
array_data.push(Math.round(measurement)); localStorage.setItem("scrapedData", JSON.stringify(array_data)); //console.log(array_data); document.getElementById('data').innerHTML = array_data.join(" <br> "); document.getElementById('fab-btn').innerHTML = array_data.length ; } else{ console.log('Data finished'); localStorage.clear(); } }
27
Mätningarna på heatmap utritningen görs på samma sätt i både Leaflet och OpenLayers med undantag för att variablerna har andra namn. Se Appendix D och E.
Koden för mätningarna på renderingstider vid zoom skiljer sig lite beroende på om det gäller OpenLayers eller Leaflet, men uppbyggnaden är liknande. I figur 35 illustreras koden som används i Leaflet artefakten.
När ett tryck görs på zoomkontrollerna används Date.now()för att ta en starttid. Därefter används Leaflets inbyggda laddningsfunktion på variabeln tile_layer som innehåller OpenStreetMap plattorna som ska hämtas och laddas in. Laddningsfunktionen kan aktiveras vid olika händelser som loading, load, tileloadstart, tileloadend med fler. Enligt Forest Katsch (2014) används händelsen load när alla plattorna på kartan laddat in. Därför används Date.now()igen för att hämta en sluttid och räkna ut hur lång tid det tog från att zoomknappen trycktes på tills att kartans plattor har renderat klart på den nya zoomnivån. Därefter pushas mätvärdet in i en array kallad scrapedTileData och sparas i local storage.
Figur 35 Mätning av laddningstider vid zoom i Leaflet
I Appendix D, finns koden för den motsvarande funktionen i OpenLayers. Strukturen på koden är väldigt likvärdig och fungerar på samma sätt. Vid klick på zoomknapparna sparas en starttid och vid OpenLayers funktion moveend kallas funktionen zoom_time. Koden inuti funktionen är snarlik den i figur 35 ovan och fyller samma funktion.
$(".leaflet-control-zoom-in").add(".leaflet-control-zoom-out").click(function() { var tile_start = Date.now();
localStorage.setItem("tile_start", tile_start); });
tile_layer.on("load",function() {
if(localStorage.getItem("tile_start") != null){ var tile_end = Date.now();
var stored_time = localStorage.getItem("tile_start"); var completed_tile = (tile_end - stored_time);
tile_data.push(Math.round(completed_tile)); localStorage.setItem("scrapedTileData", JSON.stringify(tile_data)); console.log(tile_data); localStorage.removeItem('tile_start'); document.getElementById('tile_data').innerHTML = tile_data.join(" <br> "); } else {
console.log('Tile Data finished');
localStorage.removeItem('scrapedTileData'); localStorage.removeItem('tile_start'); }
28
Figur 36 POST-förfrågan i Tampermonkey för Leaflet
Laddningstiderna från testerna sparas med hjälp av Tampermonkey. I figur 36 ovan illustreras koden som använts för att hämta laddningstiderna från artefakten. Då resultaten skrivs ut i en div på sidan används två klickfunktioner för att hämta värdena från sidan och skicka vidare till en textfil på wwwlab-servern med ett knapptryck.
5.3 Progression
Experimentet skulle från början använda D3.js för att skapa heatmaps och markörer i OpenLayers respektive Leaflet. Då det visade sig att D3.js endast kunde rendera clustered heatmaps behövdes ett annat alternativ hittas. Alternativet blev heatmap.js för Leaflet och den inbyggda heatmap modulen för OpenLayers. Heatmap.js var tänkt att användas för både Leaflet och OpenLayers, då heatmap.js ska finnas som plugin för båda JavaScript-biblioteken enligt dokumentationen, men under implementationen upptäcktes det inte vara fallet och OpenLayers tycks ha tagits bort som plugin kring år 2012. Senare versioner av OpenLayers har en inbyggd modul för heatmaps som har en liknande struktur och uppbyggnad som heatmap.js. Tillvägagångssätten ansågs vara tillräckligt likvärdiga för att användas i implementationen av artefakterna.
5.3.1 Databas
För att få resultaten från databasen att skrivas ut på klient-sidan testades först en lösning med att skriva ut latitud och longitud i en lista. Testet lyckades, och koordinaterna skrevs ut i ett list element från variablerna #{flood.lat} och #{flood.long}med databindning i Jade, se figur 37 nedan.
(function() { const scraped_url='https://wwwlab.iit.his.se/a17alian/cms/scraped_receiver.php'; function ajaxCall(data) { try { GM_xmlhttpRequest({ method: 'POST', url: scraped_url, data: 'str=' + encodeURIComponent(data), headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }); } catch (ex1) { console.log(ex1); } } $("#send_data").click(function() { ajaxCall($("#data").text()); alert('Render data sent'); });
$("#send_zoom_data").click(function() { ajaxCall($("#tile_data ").text()); alert('Zoom data sent');
}); })();
29
Figur 37 Kod för att skriva ut resultaten i en lista
Mycket tid spenderades sedan på att försöka förstår hur variablerna med resultatet kunde kopplas till html-elementen i Jade-filerna. Efter lite efterforskning blev förståelsen att svårigheterna låg i att skicka variablerna med resultatet direkt till HTML-elementen på samma sätt som för list-elementet i föregående figur 37. Nästa steg var då istället att försöka hitta ett sätt att få resultaten till scripten för OpenLayers respektive Leaflet kartorna. Problemet löstes tillslut genom att skapa en databasanslutning i data.js-filen med endpointen /data som returnerade resultaten som JSON. Sedan implementerades AJAX, se föregående figur 23, för att kunna skicka förfrågningar till /data från klient-sidan och därefter kunna använda resultatet för att skriva ut datapunkter i OpenLayers och Leaflet3.
5.3.2 OpenLayers
Vid implementeringen av OpenLayers uppstod problem med i koden från introduktionsguiden (OpenLayers 2020a). Guiden rekommenderar att installera OpenLayers via npm, men när applikationen sedan byggs kommer felmeddelandet i figur 38 upp i konsolen.
Figur 38 Error med npm installation
Trots att koden var identisk med den i introduktionsguiden kvarstod felmeddelandet.
Problemet löstes tillslut genom att använda CDN-länkarna4 till OpenLayers som fanns i
kom-igång guiden (OpenLayers 2020b).
Vid implementation av heatmaps i OpenLayers uppstod svårigheter då exemplet från dokumentationen (OpenLayers 2020c) behövde modifieras för att fungera i artefakten. I exemplet används en URL med KML-data som källa till vektor-lagret. Koden behövde modifieras till att använda ett GeoJSON objekt som källa. Det första som gjordes var att
3https://github.com/a17alian/exjobb_2020/commit/c104fa2
4https://github.com/a17alian/exjobb_2020/commit/6c4c1e1
body
block content ul
each flood, I in floods li#flood_item
#{flood.lat}, #{flood.long})
30
försöka ändra KML URL:en till att använda en GeoJSON fil5, vilket fungerade, se figur 39 för
utritade datapunkter.
Figur 39 Datapunkter med GeoJSON url
Steget därefter var att använda GeoJSON objekt som källa i heatmapLayer. Koden för det hittades i ett annat exempel i dokumentationen (OpenLayers 2020d). Problemet som uppstod då var att varken datapunkter eller felmeddelande skrevs ut. För att undersöka vad som orsakade problemet användes console.log() för att skriva ut värdet i geojsonObject både innanför och utanför toGeoJson funktionen, se figur 40.
Figur 40 Kod från console.log test
Resultatet i konsolen, se figur 41 nedan, visade att loggen som gjordes utanför funktionen returnerar värdet undefined och skrivs även ut innan den första loggen, trots att den ligger längre ned i koden. Loggen som kallas inuti funktionen innehåller det korrekta värdet och returnerar inte undefined.
5https://github.com/a17alian/exjobb_2020/commit/cf4bc33
Function toGeoJson(floods){
for(var i = 0; i < floods.length; i++;){
marker[i] = ol.proj.fromLonLat([floods.[i].long, floods[i].lat]); geojsonObject.features.push(marker[i]); } console.log(‘1’ + geojsonObject.festures[0]); return geojsonObject; } console.log(‘2 ‘ + geojsonObject.features[0]);
