VISUALISERING AV 3D OBJEKT PÅ 2D KARTOR
En jämförelse av utritningstid mellan ThreeJS och X3DOM.
VISUALIZATION OF 3D OBJECTS ON 2D MAPS
Benchmark between ThreeJS and X3DOM.
Examensarbete inom huvudområdet Informationsvetenskap
Grundnivå 30 Högskolepoäng Vårtermin 2020
Pontus Göth
Handledare: Marcus Brohede Examinator: Henrik Gustavsson
Sammanfattning
Datavisualisering är ett hjälpsamt verktyg för beslutsfattare för att inom en kontext få en god översyn och skapa förståelse. Beslutsfattare kan enklare ta beslut utifrån datan som visualiserats och visualisera geografiskt knuten data med kartor har varit populärt under en längre tid. 3D grafik för webben har också med tiden vuxit sig mer mogen och kraftfulla bibliotek har ersatt tidigare pluginbaserade lösningar. Det har skapat möjligheter för nya licensfria former av datavisualisering. Det finns dock olika angreppssätt för att skapa och visualisera data i 3D för webben, det deklarativa och det imperativa, vilket detta arbete ämnar att jämföra.
Arbetet undersöker det deklarativa X3DOM och det imperativa ThreeJS för att se vilket som presterar bäst i utritningstid. Resultatet visade att ThreeJS presterar bättre jämfört mot X3DOM men ThreeJS har en ojämn prestanda kurva med många spikar.
Nyckelord: X3D,WebGl, X3DOM,ThreeJS,data- visualisering,kartor
Innehållsförteckning
1 Introduktion ... 1
2 Bakgrund ... 2
2.1 Datavisualisering med kartor... 2
2.1.1 Json... 3
2.2 3D för webben ... 4
2.2.1 Imperativ och Deklarativ ritning av grafik ... 5
2.3 Bibliotek... 6
2.4 WebGL och ThreeJS biblioteket ... 6
2.4.1 ThreeJS biblioteket ... 7
2.5 X3D och X3DOM biblioteket ... 9
2.5.1 X3DOM ... 9
3 Problemformulering ... 11
4 Metod ... 12
4.1.1 Alternativ metod ... 12
4.2 Etik ... 13
5 Genomförande ... 14
5.1 Litteraturstudie ... 14
5.2 Progression... 16
5.2.1 Rendering av cylindrar i Threejs och X3DOM... 16
5.2.2 ChanceJS och datagenerering ... 16
5.3 Implementation ... 17
5.3.1 Webbserver och inläsning av JSON data med Fetch API ... 17
5.3.2 Förbehandling av data ... 19
5.3.3 Visualisering med ThreeJS... 23
5.3.4 Visualisering med X3DOM ... 29
5.3.5 Mätning av utritningstid med UserScript ... 35
5.4 Pilotstudie ... 38
5.4.1 Pilotstudie diskussion ... 39
6 Utvärdering ... 40
6.1 Hård- och mjukvaruspecifikation ... 40
6.2 Presentation av experiment ... 41
6.3 Resultatet av experimenten ... 42
6.3.1 Experiment 1 ... 42
6.3.2 Experiment 2 ... 43
6.3.3 Experiment 3 ... 44
6.4 Analys ... 45
7 Slutsats ... 47
7.1 Sammanfattning ... 47
7.2 Diskussion ... 47
7.3 Etik och samhällsnytta ... 48
7.4 Framtida arbete... 49
1 Introduktion
Vid beslutsfattning och planering är det hjälpsamt att visualisera data för beslutsfattare på ett sätt som är enkelt att förstå med god översyn kopplat till en kontext. Beslutsfattare kan enklare ta beslut utifrån datan som finns visualiserad (Haara, Pykäläinen, Tolvanen &
Kurttila, 2018). Diagram är den vanligaste formen av datavisualisering för att skapa en effektiv kommunikation men utöver visualisering av data med diagram är också kartbaserad visualisering populärt. Vid planering och genomförande inom infrastruktur med 3D är kartor en naturlig aspekt. Kartor i 3D kan med den extra dimensionen underlätta för beslutsfattning tillexempel för beslut riktat mot över och under markplan (Nolde, M., Schwanebeck, M., Dethlefsen, F. et al., 2016).
3D grafik för webben har med tiden blivit allt viktigare och vanligare (Alun Et Al., 2014).
Olika licensfria alternativ började ta mark och bli allt mer populära efter att problemen med tidigare pluginbaserade lösningar blev allt tydligare. Adobe flash är ett exempel på en populär lösning för att göra det möjligt med 2D och 3D visualisering i webbläsaren. På grund av att det var en proprietär produkt som led utav långsamma nedladdningstider på grund utav Flash exekverbara filer, samt att Flash filerna kunde kringgå alla former av standarder för en webbläsare gjorde tekniken osäker. Två olika sätt att visualisera 3D grafik för webben uppstod, det deklarativa och det imperativa. Det deklarativa sättet gör sig känt hos X3D med biblioteket X3DOM varav ThreeJS är ett av mest använda imperativa biblioteken. Det deklarativa sättet strävar efter att ligga närmare fundamentala principer för webbutveckling med en stark koppling till DOM;en. Det imperativa sättet är motsatsen till det deklarativa och förbinder sig inte till DOM;en utan istället strävar efter att separera sig från den (Alun Et Al., 2014).
Problemet är att av redan existerande bibliotek kan det vara svårt att veta vilket som lämpar sig bäst. Detta arbete ämnar att specifikt undersöka biblioteken ThreeJS och X3DOM.
ThreeJS och X3DOM är två olika tillvägagångssätt där frågan ställs vilket av dessa två bibliotek kommer ha den lägsta utritningstiden. Låg utritningstid kan dra paralleller till generell laddningstid för en hemsida. Laddningstiden för en hemsida från att en slutanvändare navigerat till en applikation och förväntar sig se något får inte ske för långsamt. Om utritningstiden är för långsam finns det en stor risk att slutanvändare söker sig vidare till bättre applikationer (Hoxmeier & DiCesare, 2000).
Den valda undersökningsmetoden som genomfördes var ett tekniskt experiment. För att visualisera resultatet och göra det överskådligt skapades diagram vilket presenterar utritningstiden i millisekunder för X3DOM och ThreeJS vilket undersöktes i detta arbete.
Den insamlade datan i form utav utritningstid för cylindrar vilket visualiserar data på en karta, samlades in med UserScript hanteraren GreaseMonkey.
2 Bakgrund
2.1 Datavisualisering med kartor
Att ta rätt val och planera är två utmanande problem vilket datavisualisering kan hjälpa till att underlätta. För att kunna ta rätt beslut utifrån data behöver den visualiseras på ett sätt som är lätt att förstå. Att datan visualiseras på ett sätt som inom kontexten är lämpligt gör det lättare för beslutsfattare att sätta sig in i datan, förstå den och använda det som underlag för beslutsfattning (Haara, Pykäläinen, Tolvanen & Kurttila, 2018).
Datavisualisering är grundläggande för att få slutanvändare att förstå och skapa en effektiv kommunikation där diagram är den vanligast (Meenakshi et al. 2015). Utöver diagrambaserad visualisering är också kartbaserad en populär och välanvänd teknik för att presentera data i både 2D och 3D. Ett exempel på ett användningsområde som drar stor nytta utav visualisering med hjälp utav kartor är planering av infrastruktur. Vid visualisering av infrastruktur med kartor gör den extra dimensionen det möjligt att visualisera ett 2D plan för att bygga en god kontext och sedan kunna utnyttja Z-axeln hos ett 3D plan för att utforska datan till exempel under eller över markplan för att underlätta vid beslutsfattning (Nolde, M., Schwanebeck, M., Dethlefsen, F. et al., 2016). Utöver infrastrukturs frågor visar Figur 1 ett exempel på hur 3D teknologier kan användas tillsammans med en karta, i detta fall utan verklig data men varje cirkel skulle kunna visualisera blixtnedslag.
För att datavisualisering av den form som visas i Figur 1 ska ge nytta är ett existerande dataset ett krav. Vare sig det är realtids data eller mer tillgänglig historisk data kan ett företag med hjälp av detta växa och anpassa sig utefter den. Data idag har blivit en råvara för att skapa värde vare sig det handlar om att förstå kunder, bygga nya tjänster eller hantera kostnader och risker (Mama N M, John W A, Shadi A., 2019).
2.1.1 Json
Data kan lagras i olika format där ett populärt format är JSON, JavaScript Object Notation.
JSON baserar sina datatyper från programmeringsspråket JavaScript och är ett lättviktigt format. JSON dokument består utav nyckelvärdespar där ett par kan vara ett JSON objekt.
JSON objekt har fulla möjligheter att inkludera flera JSON dokument och skapa rimliga nivåer av nästling. Webbtjänster vilket kommunicerar över diverse API;er, Application Programming Interfaces, har valt JSON för dennes egenskaper att enkelt tolkas av både människor och maskin (Bourhis, 2017). JSON anses var ett välanvänt format för datautbyten där en orsak kan vara att det har byggts databassystem som noSQL vilket utnyttjar JSON istället för SQL för att lagra data (Bourhis, 2017). JSON specifikationen definierar sju olika datatyper: object, array, string, numbers, boolean och null (Bourhis, 2017). Figur 2 presenterar ett exempel på hur ett JSON-dokument kan bygga upp.
Figur 2 Exempel på JSON dokument
{“City”: “Botkyrka”, “Population”: 92097.0, “activities”: [
“shopping”, “spa”
] }
2.2 3D för webben
3D grafik har med tiden blivit allt viktigare när det kommer till multimedia för webben (Alun Et Al., 2014). Från deklarativa X3D med syfte att integrera 3D i HTML, till imperativa WebGL vilket ligger ännu närmare hårdvaran för högpresterande applikationer (Alun Et Al., 2014). Både X3D samt WebGL är licensfria alternativ men innan fler öppna teknologier blev tillgängliga var Adobe flash ett populärt alternativ som utvecklare var beroende utav för att skapa interaktivt multimedia innehåll (Alun Et Al., 2014). Adobe flash var plugin baserat och en proprietär produkt som kunde kringgå alla former av standarder vilket försökte ta form hos webbläsare. Adobes stängda system tillät utvecklare att bädda in ljud, video och 2D animationer i en Flash exekverbar fil. Flash plugin installerat hos en slutanvändares webbläsare exekverade filen och på så sätt kunde, nästan helt, kringgå webbläsaren vilket skapade säkerhetsproblem. Adobe Flash led av långa nedladdningstider för dessa exekverbara filer och krävde att Adobes egna Flash plugin var installerat för att kunna ta del av innehållet. Vartefter öppna standarder allt mer blev välanvänt ersattes Adobe Flash och liknande pluginbaserade lösningar (Alun Et Al., 2014). SVG (Scalable Vector Graphics) introducerades och blev ett utav flera stora standarder vilket gav möjligheten att utveckla öppen och komplex 2D ritning för webbapplikationer. Canvas kom efter SVG med samma möjlighet att utföra ritningar av 2D grafik med skillnaden att Canvas har möjligheten att styras genom programmeringsspråket JavaScript (Alun Et Al., 2014). SVG och Canvas kom att bli integrerade i den senaste HTML, Hyper Text Markup Language, standarden HTML5 och banade vägen för allt fler licensfria och öppna teknologier.
HTML5 syfte är att skapa ett standardiserat sätt att utveckla dynamiska och interaktiva webbapplikationer rika med multimedia innehåll (Alun Et Al., 2014). I dagsläget går det att se ett ökat behov och vilja att använda 3D innehåll inom olika webbapplikationer.
Webbläsare idag har med förbättrad hårdvaruacceleration skapat möjligheten att tillfredsställa behovet av webbapplikationer med 3D innehåll (Alun Et Al., 2014). Termen rendering inom 3D beskriver processen att omvandla 3D data till en 2D bild på en skärm. Det finns olika renderingstekniker med sina egna styrkor och svagheter vad gäller fotorealism, komplexitet och prestanda (Alun Et Al., 2014).
Några standardiserade termer inom grafik är viktiga att definiera som används vardagligt inom grafikprogrammering. Vanliga termer inom grafikområdet är scen, mesh och material (Alun Et Al., 2014).
• En scen visar en eller flera grafiska objekt och innehåller även en Kamera, även kallad viewpoint, samt en eller flera ljuskällor.
• Mesh representerar 3D objekt vilket byggs upp utav primitiva former så som trianglar eller fyrkanter för att med tillräckligt många former nå en fotorealistisk representation av ett föremål.
• Material är det som ger en mesh sitt utseende och kan bestå utav färger eller 2D bilder.
2.2.1 Imperativ och Deklarativ ritning av grafik
Utveckling av 3D modeller har en lång tradition av att använda ett deklarativ tillvägagångssätt, vilket ligger i linje med fundamentala principer för webbutveckling.
Jankowski et al(2013) såg därför nyttan att undersöka erfarenheterna som samlats hos webbutvecklare och utvecklare av grafik. Att skapa grafik på ett deklarativt sätt innebär att utvecklaren säger till datorn vad som ska ritas utan att explicit säga hur det ska ritas. Inom den deklarativa tillvägagången inkluderas exempelvis tekniken SVG vilket kan användas för att skapa 2D grafik i webbläsaren och X3D för 3D grafisk utritning vilket X3DOM biblioteket är välanvänt (Jankowski et al, 2013).
Imperativa tillvägagångsättet kan istället utnyttja HTML5 <canvas> elementet för att med hjälp utav programmeringsspråket JavaScript skapa grafik. Imperativa är motsatsen till det deklarativa sättet och beskriver hur grafiken ska ritas för att få fram önskat resultat. Enligt Alun Et Al(2014) går det och argumentera för att förr eller senare inom datorprogrammering går till att bli imperativ kod, för att många lågnivåspråk är imperativa i sin natur. JavaScript som är det traditionella språket för webbapplikationer att exekvera icke-deklarativ kod i webbläsaren, har inslag av det imperativa sättet. Se Figur 3 för en överskådlig och jämförande bild på deklarativa och imperativa tekniker.
Figur 3 Jämförande bild på deklarativ och imperativ tillvägagång
(Jankowski et al, 2013).2.3 Bibliotek
3D programmering i sin grundläggande form är en komplicerad uppgift vilket kräver många steg för att skapa något i 3D. För att göra processen enklare och dra fördelar av att återanvända kod utvecklades ramverk och bibliotek (O, David et al., 2013). Den ökande populariteten för programmeringsspråket JavaScript har varit en drivande faktor att skapa fler bibliotek ämnade för webbutveckling (Pano, Graziotin, Abrahamsson., 2018), men den troligtvis viktigaste faktorn att använda sig utav bibliotek är att minimera tiden det tar att utveckla en applikation. Bibliotek är ett integrerat sett funktioner vilket skapar en återanvändningsbar och utbyggningsbar arkitektur som ger utvecklaren möjligheten att inte behöva uppfinna hjulet på nytt (Okanovic, 2011). Enligt Okanic (2011) ger ett bibliotek möjlighet att, relaterat till utvecklingstiden, minska kostnaden att ta fram en applikation.
Ett bibliotek innebär inte bara lösningar på problem för ett projekt utan involverar också risker. En risk är mängden bibliotek som finns att välja på. När valet står mellan ett antal olika bibliotek vilket ämnar att lösa samma problem är det inte helt uppenbart vilket bibliotek som lämpar sig bäst. Risken är att ett mindre lämpligt bibliotek för den tänkta applikationen skapar hinder istället för att förbättra utvecklingsprocessen och applikationen (Ahamed, S.I., Pezewski, A. & Pezewski, A., 2004). Val av fel bibliotek kan leda till oönskad förändring av existerande kod i biblioteket för att få det och fungera med projektet eller dåligt skrivna funktioner vilket kan leda till fördröjningar eller en osäker applikation.
2.4 WebGL och ThreeJS biblioteket
Web Graphics Library (WebGL) är ett JavaScript API (Application Programming Interface), som möjliggör utveckling av grafik för webbapplikationer. WebGL använder sig utav OpenGl som även det är ett öppet API för att skapa vektorbaserad 2D och 3D grafik(Ha, Jin & Lee, 2015). WebGL har tagits fram tillsammans av ett flertal stora företag som till exempel Apple och Google under paraplyet WebGL group vilket också ingår under Khronos group (Georgios, B, Yiannis, K, Nikolaos, S, Athanasios, V, Nikolaos, D, 2019).
WebGL har slagit igenom och ersatt tidigare pluginbaserade lösningar som Adobe Flash eller inbäddat innehåll som Java Applets (Callieri, Leoni, Dellepiane, Scopigno, 2013). WebGL fungerar i alla kompatibla webbläsare och ger möjligheten att flytta tidigare desktop låsta applikationer till en webbaserad multi-plattformslösning. Högpresterande 3D applikationer blir då tillgängliga även på mobila enheter via en webbläsare.
Nackdelen med Adobe Flash och även Java Applets var att CPU, Central Processing Unit, enbart utnyttjades. Att enbart kunna utnyttja CPU skapade begränsningar i tillämpning av 3D grafik relaterat till prestanda av grafik för webbaserade applikationer. WebGL trädde fram med full möjlighet att via hårdvaruacceleration i webbläsaren utnyttja GPU, Graphics Processing Unit, och på så sätt skapar möjligheten att utveckla grafiskt tunga applikationer.
WebGL ligger på en högre abstraktionsnivå i jämförelse med ren OpenGl, där även inga licenskrav existerar för att använda WebGL (Zhou, X., Wang, J., Guo, M. et al, 2019). Utan krav på licenser och en abstraktionsnivå högre jämfört mot ren OpenGl kod öppnade det dörren för fler utvecklare att ta fram grafiska 2D och 3D applikationer.
2.4.1 ThreeJS biblioteket
ThreeJS är ett populärt WebGL bibliotek för webbaserad 3D utveckling. Från början utvecklat i ActionScript och nu släppt som ett open source JavaScript projekt som tillåter utveckling av webbläsarbasserade scener med högnivå programmering (Alun et al., 2014).
ThreeJS har en modulär struktur vilket gör att biblioteket kan hantera olika renderingsmotorer som SVG och Canvas. ThreeJS gör det enklare att använda funktioner för scenhantering, olika typer av kameror, navigering och förprogrammerade shaders (Alun et al., 2014). ThreeJs gör det väldigt enkelt att med lite kod komma igång.
Figur 4 visar exempelkod med utgångspunkt från ThreeJS officiella dokumentation (ThreeJS, 2020), för att skapa en kub i 3D som presenteras i Figur 5.
Figur 4 ThreeJS exempel kod för att sätta upp en scen, kamera och
renderare med en simpel kub geometrivar scene = new THREE.Scene();
var camera = new THREE.PerspectiveCamera( 75, window.innerWidth / window.innerHeight, 0.1, 1000 );
var renderer = new THREE.WebGLRenderer();
renderer.setSize( window.innerWidth, window.innerHeight );
document.body.appendChild( renderer.domElement );
var geometry = new THREE.BoxGeometry();
var material = new THREE.MeshBasicMaterial( { color: 0x00ff00 } );
var cube = new THREE.Mesh( geometry, material ); scene.add( cube );
camera.position.z = 5;
function animate() {
requestAnimationFrame( animate );
renderer.render( scene, camera );
}
animate();
Figur 5 Resultatet av exempel koden i Figur 4
2.5 X3D och X3DOM biblioteket
David Raggett, Mark Pesce och Tony Parisi utvecklade filformatet Virtual Reality Modeling Language, VRML, med syfte att beskriva 3D objekt. Under formatets andra version blev VRML en ISO standard året 1997 och kallades VRML97. VRML97 utnyttjar text för att specificera en mesh och associera en mesh med ett tillhörande material. VRML97 hade inte stöd för komplexa animationer. Ett flertal applikationer och webbläsartillägg togs fram för att kunna använda och visa VRML97-grafik vilket kan ses som början på ansträngningarna att utveckla 3D-grafik för internet(Alun Et Al., 2014).
Trotts ansträngningar och engagemang ersattes VRML97 av X3D. X3D utvecklades med VRML97 i åtanke och stödjer därför VRML97 samt mer avancerade API;er, data format, komponentbaserad arkitektur och striktare överensstämmelse. VRML97 använder en syntax likt programmeringsspråket C och stödet behölls i X3D. X3D inkluderade stöd för binär och XML formatet vilket utnyttjas brett i webbteknologier och tar X3D närmare webben (Alun Et Al., 2014).
2.5.1 X3DOM
I ett försök att utöka webb stödet för X3D introducerades 2008 X3DOM. X3DOM ger 3D möjligheter till webben utan krav på plugin och designat för att integreras nära standardiserade webb teknologier som AJAX. X3DOM behåller det deklarativa sättet från X3D i ett försök att utveckla X3D direkt i webbläsaren. X3DOM ger <x3d> taggen som kan användas i alla standard HTML och XHTML sidor för att utveckla grafik med X3DOM biblioteket (Alun Et Al., 2014). X3DOM är framtaget för att ge full integrering med DOM;en och kan därför manipuleras som vilket annat DOM objekt som helst. Med JavaScript kan DOM;en manipuleras direkt under applikationens körtid vilket får objektet att uppdateras direkt. Se Figur 6 för ett exempel på en X3DOM scen vilket en kub i 3D ritas ut samt se Figur 7 för slutresultatet av exemplet.
Figur 6 Exempel kod för att sätta upp en scen, kamera och rendera
ut en kub.Figur 7 Resultatet från kodexemplet i Figur 6
<X3D>
<scene>
<shape>
<appearance>
<material diffuseColor=’1 0 0’></material>
<box></box>
</appearance>
</shape>
</scene>
</X3D>
3 Problemformulering
3D visualisering av kartor har ökat i popularitet och blir allt mer ett viktigt problem för internet. Nya tekniker som HTML5 och WebGL med mobila enheter vilket allt mer blir kraftfullare skapas möjligheten att bygga 3D kartapplikationer för webbläsaren(Gutbell R., Pandikow L., Kuijper A., 2018). Existerande kartapplikationer existerar redan idag utav bland annat tjänster som Google Maps (Google Maps, 2020). Existerande lösningar som Google Maps (Google Maps, 2020) är begränsade, antingen i flexibilitet att anpassa sin lösning eller begränsade möjligheter i hur världen eller datan visualiseras på önskat sätt. Med hjälp utav öppna och licensfria teknologier som det imperativa WebGL och deklarativa X3D är det möjligt att utveckla applikationer fria från möjliga begränsningar hos redan existerande tjänster och bibliotek.
Användning av bibliotek för applikationsutveckling är enligt Okanovic(2011) värdefullt för utvecklare av anledningar som ökad produktivitet och förbättrad kvalitet. Frågan som då ställs är om ett imperativt 3D bibliotek har en signifikant påverkan på utritningstid jämfört mot ett deklarativt bibliotek. Utav tillvägagångsätten WebGL och X3D, vilken är mest lämplig att använda vid visualisering av data i 3D för kartor. Att ha låg utritningstid kan dra paralleller till generell laddningstid för en hemsida. Där tiden från att en slutanvändare navigerat till en applikation och förväntar sig se något inte får ske för långsamt.
Slutanvändaren kan annars anse applikationen vara oanvändbar och leta sig till andra konkurrerande applikationer (Hoxmeier & DiCesare, 2000). Problemet är att bland alla dessa bibliotek kan det vara svårt och veta vilket som lämpar sig bäst för visualisering av data i 3D med frågeställningen som utgångspunkt.
Mätning av utritningstiden kan ge en intressant insyn hur ett imperativt tillvägagångssätt kan prestera jämfört mot en deklarativ, med tanke på den stora skillnaden i angreppssätt att bygga en 3D applikation. För att kunna utvärdera och jämföra det imperativa respektive det deklarativa kommer biblioteken ThreeJS samt X3DOM användas vilket anses vara välanvända bibliotek för detta ändamål (Alun Et Al., 2014). Utritningstiden i detta arbete syftar till utritning av cylindrar i en scen där en scen består utav ett 2D plan med en karta vilket cylindrarna kommer ritas ut på. Scenen som kommer användas är likvärdig i ThreeJS och X3DOM inom vilket möjligheten att rendera cylindrar kopplade till data kommer undersökas. För detta arbete syftar cylindrarna till att representera data i ett dataset där positionen av en cylinder ska representera en geografisk plats kopplad till verkligheten.
Höjden på den utritade cylindern representerar den data som finns kopplad till den geografiska punkten.
Hypotesen är att utritningshastigheten av cylindrar vilket representerar geografiskt kopplad data i en 3D scen kommer vara snabbare hos en applikation utvecklad i det imperativa biblioteket ThreeJS. Mothypotesen är att utritningshastigeten av cylindrar vilket representerar geografiskt kopplad data i en 3D scen kommer vara snabbare hos en applikation utvecklad i det deklarativa biblioteket X3DOM.
4 Metod
Av de fyra vetenskapliga metoderna undersökning, fallstudie, experiment och quasi- experiment valdes metoden experiment. Enligt Wohlin et al (2012) bör den här metoden användas när behovet att manipulera, på ett systematiskt sätt, beteenden och ha kontroll över parametrarna runt mätningen finns. Metoden lämpar sig väl att använda vid testning av hypoteser vilket kan ske exempelvis i ett laboratorium för att simulera verkliga förhållanden.
Experiment medför dock risker, främst vid förberedelser av experimenten. Risker inom experiment kan exempelvis vara förberedelser av experimentet som måste vara korrekt. Vad som ska mätas är viktigt att definiera och hitta för att minska risken av felaktiga mätningar som kan leda till missledande slutsatser (Wohlin et la., 2012).
För detta arbete kommer ett experiment med teknisk inriktning att användas då enligt Wohlin et al (2012) är detta möjligt vid jämförelse av bibliotek eller verktyg. För att kunna utföra ett experiment krävs ett testobjekt eller en testmiljö. Arbetet ämnar att jämföra två olika bibliotek med olika egenskaper och förutsättningar. Två funktions ekvivalenta artefakter kommer användas, en artefakt för respektive valt bibliotek till studien, vilket exekveras i en gemensam testmiljö i from utav en webbserver. En gemensam webbserver kommer ge fulla möjligheter att styra variabler som tillgång till internet, eventuell packethanterare och övriga parametrar som kan ha en påverkan på experimenten. Arbetet kommer förtydligat bestå av en artefakt för varje bibliotek som tänkts jämföras, i detta fall en artefakt för ThreeJS respektive X3DOM vilket delar på samma testmiljö i form av en webbserver.
I detta arbete kommer utritningstiden av 3D cylindrar mätas och för att visa på en skillnad i utritningstid mellan artefakterna ska ett tekniskt inriktat experiment genomföras i form utav en prestandamätning. Metoden lämpar sig väl då parametrar och miljön kan styras tillfullo.
Enligt Wohlin et al (2012) försäkrar en prestandamätning bra mätvärden kopplat till problemformuleringen och mer exakta resultat jämfört med andra undersökningsmetoder.
Med den insamlade datan från prestandamätningen kommer en jämförelse vara möjlig vilket kommer visa på om det finns en signifikant skillnad i utritningstid mellan biblioteken ThreeJS och X3DOM. Koden för att rita ut 3D cylindrar i en scen kommer automatiseras hos respektive bibliotek i en funktion för att möjliggöra enkel mätning av tid från att funktionen startar tills att den har ritat ut alla cylindrar. Funktionen för att rita ut cylindrar i respektive bibliotek kommer exekveras via ett externt script där även utritningstiden i millisekunder kommer samlas in och lagras inför jämförelsen. Utritningstiden för cylindrarna som insamlad data i millisekunder analyseras för att skapa förståelse i bibliotekens skillnader, vilket kommer göra det möjligt att besvara frågeställningen.
4.1.1 Alternativ metod
Fallstudie är ett alternativ som skulle kunna fungera för detta arbete med fördelar såsom lättare att planera och är mer realistiska (Wohlin et al., 2012). Fallstudie innebär att ta en använd teknologi i ett redan existerande system och byta ut den mot en annan. En intressent utför observationer som kan avgöra hur upplevelsen av prestanda har förändrats innan och efter förändringen. Data från observationerna mäts och samlas in och kan då jämföras samt
En fallstudie har kravet att kunna utföra den i en verklighetstrogen kontext enligt Wohlin et al (2012). Med en verklighetstrogen kontext innebär det i detta fall att en tillräckligt lik applikation redan existerar och används. Den exekverade applikationen skall i så fall bytas ut med den artefakt som detta arbete kommer ta fram. När detta arbete skrivs har inte en sådan applikation påträffats som uppfyller kraven som ställs för en fallstudie och kan då inte genomföras. Möjligheten för att styra parametrarna i en fallstudie är lägre än för ett experiment men för detta arbete har varje parameter en chans att påverka slutgiltiga mätningen. Ett tekniskt riktat experiment uppfyller behovet att styra parametrar lämpligt för detta arbete. En fallstudie skulle vara bättre lämpat än ett experiment ifall mätvärden på en typisk situation istället för manipulerade variabler över tid vore intressant (Wohlin et al., 2012). Till exempel lämpar sig fallstudier väl för att jämföra metoder i olika situationer enligt Wohlin et al (2012).
4.2 Etik
Den viktigaste aspekten att ta hänsyn till från ett etiskt perspektiv är att göra arbetet replikerbarhet. Det ska vara enkelt för vem som helst att återskapa arbetet av skäl såsom öka tillförlitligheten till resultatet samt finna nytta för framtida arbete (Wohlin et al. 2012).
Därför kommer plattformen Github användas till dokumentering och lagring av arbetets kod för artefakten. För ytterligare möjlighet att kunna återskapa arbetet kommer även samma kod att existera som ett appendix i detta arbete.
Två artefakter kommer användas för att utföra mätningarna. För att försäkra trovärdigheten i mätningarna kommer samma dataset att användas. Miljön artefakterna kommer köras i, hårdvara och mjukvara, samt övriga utomstående parametrar såsom uppkoppling till ett nätverk kommer också vara densamma. Genom att säkerställa att mätningarna på artefakterna genomförs i samma miljö kan resultatet från mätningarna undvika en påverkan.
Då miljöerna vilket artefakterna kan exekveras i är för många för att ta med alla i detta arbete finns det en risk att en bättre lämpad miljö skapar stora skillnader i den insamlade datan från genomförda experiment. Därför kommer den använda miljön som användes för experimenten i detta arbete att noggrant dokumenteras och presenteras. Med ändamålet att skapa bättre möjligheter för replikering av den använda miljön för detta arbete så nära som möjligt.
Det är också viktigt att ta hänsyn till känslig information i datasetet. En karta kommer användas för att visualisera ett dataset. Om kartan innehåller olämplig data i form av skyddsobjekt eller liknande kan det skapa etiska problem. Den granskning som går att utföra av dataset samt kartor för detta arbete kommer genomföras. För att undvika problem vad gäller licenser som begränsad användning och liknande kommer enbart dataset vilket är öppen och fri att användas enligt till exempel licenser som CC04.
Vid händelse av eventuella spikar i datan kommer dessa undersökas samt dokumenteras noggrant. Det är viktigt att datan har hög kvalitet för att kunna analysera den samt besvara arbetets frågeställning (Wohlin et al. 2012).
5 Genomförande
Under denna del av arbetet kommer en pilotstudie samt litteraturstudie att genomföras och beskrivas. Pilotstudien ämnar att undersöka möjligheterna vid genomförandet och om en jämförelse kan utföras eller inte. Litteraturstudien ämnar att beskriva kunskapen inom studien vilket också kommer presenteras i kommande kapitel. Implementationen av miljön och artefakterna tillsammans med hur förbehandlingen av datan hanterades kommer presenteras i kapitlet implementation.
5.1 Litteraturstudie
De två artefakterna kommer utvecklas i ThreeJS respektive X3DOM biblioteket där koden som används vid skapandet av artefakterna vilket experiment kommer utföras på användes främst källor som webbsidor och forskningsartiklar. Ett dataset som har en så stark koppling till verkliga scenarion kommer användas för att göra experimenten så nära en verklig användning som det går. Därför kommer ett existerande dataset att användas hämtat från öppna källor. Datan som valts och verkar mest lämplig för tänkt applicering är normalvärden på nederbördsmängd i Sverige mellan åren 1961 och 1991. Datasetet har hämtats ifrån SMHI och gäller under CC-E4 licensen. Anledningen till varför detta dataset lämpar sig väl är att nederbördsdata från SMHI har en tydlig kontext kopplat till geografiskt fasta punkter i datasetet för varje mätstation som mätt nederbörd. Att ha en fast geografisk punkt underlättar för den önskade renderingen av staplar då longitud och latitud kan användas till placering av dessa staplar. I detta arbete är alltså inte storleken på datan som ska renderas i tillexempel Megabyte viktigt. För detta arbete med fokus på grafisk rendering av 3D grafik är det viktigare att ha många datapunkter att rendera på kartan.
SMHI;s statistiska data med nederbörd hämtas i form av .CSV och .TXT filer hos SMHI officiella hemsida vilket behöver formateras om till det mer lämpliga formatet JSON samt datan behöver sammanfogas till en fil. JSON gör det möjligt att kunna hantera och använda datan på ett mer lämpligt sätt passande till den tänkta applikationen. För att formatera om den hämtade datan till JSON format användes programmeringsspråket Python då språket har använts i tidigare kurser och har det kraftfulla biblioteket Pandas för att hantera datamängder som dataframes utifrån olika filformat. Icke nödvändig data från dataseten kunde med hjälp av Pandas exkluderas och sedan slå samman till en gemensam JSON fil. En förbehandling av all data var alltså nödvändig för att förenkla arbetet och skapa rätt format att läsa av datan ifrån. All information om hur pandas fungerar har hämtats från den officiella dokumentationen (Pandas, 2020) samt hos tidigare kursers uppgifter.
För att kunna visualisera datan på ett önskat sätt tydligt kopplat till domänen och kontexten måste koordinater samt ett lämpligt värde passande att visualisera som cylindrar finnas i datasetet. Varje koordinat skall ha tillhörande data och det skal existera många datapunkter.
För att läsa ut denna data från datasetet kommer JavaScript språkets egna inbyggda funktioner för att läsa in och hantera JSON strukturerad data att användas där möjlighet att kunna läsa ut specifik och önskat data är speciellt viktigt. Information om hur JSON- strukturerad data kan hanteras av JavaScript har hämtats ur dokumentation från Mozilla Developer Network förkortat MDN(2020) samt hos W3schools(2020).
Inför implementationen av ThreeJS och X3DOM med önskad visualisering användes den officiella dokumentationen och diskussionsforum för att hämta kunskap.
ThreeJs är ett välanvänt bibliotek vid utveckling av WebGL och 3D applikationer för webben och ett fullständigt bibliotek med olika färdiga funktioner för kameror, geometriska former.
ThreeJs drar även nytta av existerande terminologi kring 3D arbete och försöker inte uppfinna hjulet på nytt, istället är biblioteket menat till att ta bort svåra moment och göra arbetet lättare.
Three.js officiella dokumentation listar alla tillgängliga objekt och tillhörande funktioner (ThreeJS, 2020). Ett stort antal exempel med länk till kodexempel på bibliotekets officiella Github repository finns också för inspiration eller för att skapa en utgångspunkt (Threejs, 2020). Det populära forumet Stack overflow(2020) har även använts vid mer specifika frågor gällande biblioteket ThreeJS användning. Stack Overflow är ett populärt forum för mjukvaruutveckling där det är fritt att skapa ett konto och ställa programmeringsrelaterade frågor. StackOverflow har funnits som ett extra stöd när mer specifika frågor behövt sökas upp kring ThreeJS och WebGL.
Tillskillnad från ThreeJS använder X3DOM ett annat sätt för att rendera 3D grafik i webbläsaren. Nämligen genom att enligt X3D standarden (X3DOM, 2020) rendera 3D grafik i en hemsidans Dokument Object Model, förkortat DOM. Det ger X3DOM möjligheten att i en livescen skapa och påverka alla 3D object direkt i DOM. Det innebär också att redan existerande webbteknologier som kan påverka DOM;en går att utnyttja även här, tillexempel CSS men även DOM manipulation i JavaScript. X3DOM utnyttjar fortfarande WebGL för att stötta grafikrenderingen med lika, om än annorlunda implementerade, funktioner jämfört mot ThreeJS för att skapa en scen, kamera vilket i X3DOM heter viewpoints och lägga till 3D object. X3DOM;s dokumentation listar alla tillgängliga klasser och noder på ett utförligt sätt och har främst använts för att bygga artefakten(X3DOM, 2020). X3DOM ska vara ett enklare verktyg att jobba med 3D grafik då allt som egentligen krävs är HTML/XML syntax och inkluderandet av biblioteket. Men möjligheten finns ändå att göra mer avancerade applikationer med JavaScript. X3DOM;s officiella dokumentation innehåller likt ThreeJS en fullständig beskrivning över alla aspekter runt biblioteket. Former, viewpoint och övriga taggar som går att använda med tillhörande attribut finns tydligt beskrivna.
Mätskriptet som skall implementeras utnyttjar Greasemonkey vilket är ett tillägg för webbläsaren FireFox skapad av Aaron Boodman (2020) gjort för att hantera och skapa Userscript. Mätskriptet gör det möjligt att bygga script med JavaScript för att på egenhand utöka möjligheterna i hur en webbrelaterad applikation används. Kunskap om Greasemonkey samt userscripting har inhämtats från tidigare kurstillfällen.
5.2 Progression
Till en början var syftet att använda existerande kart API;er så som LeaftletJS eller mapbox.
Detta var dock inte möjligt då LeafletJS inte hade stöd för 3D samt mapbox visade sig vara kommersiellt och kunde inte heller användas. Ett försök gjordes att applicera leafletJS på ett 2D plan och ändå kunna utnyttja API;ets önskade funktioner som koordinater och tileset.
Efter att ha misslyckats att applicera leafletJS på detta sätt gjordes valet istället att applicera en öppet tillgänglig bild på världens karta från shadedrelief(2020) som en textur vilket fick representera en tile likt tidigare nämnda kart API;er. På så sätt skapades en lösning nära nog kopplad till verkligheten. Hela världskartan användes dock inte utan begränsades, som nämnt i problem formuleringen, till norden och Sveriges gränser. Eftersom koordinaterna från äkta kartdata gick förlorad går det därför inte att garantera att varje cylinder placerades garanterat inom den önskade avgränsningen som nämnts i problemformuleringen.
5.2.1 Rendering av cylindrar i Threejs och X3DOM
Biblioteken ThreeJS och X3DOM visade sig ha betydligt olika angreppssätt vad gäller koordinatsystemen. Att sätta samma höjd hos cylindrarna i båda artefakterna skapade en missvisande och för olik rendering. ThreeJS renderade cylindrarna som tänkt med 2D planet som bas medan hos X3DOM växte cylindrarna i både X och Y led samt blev mycket större i höjd jämfört mot Threejs. Det här problemet med skalor som visade sig svårt att få så likt som möjligt fick lösningen att i X3DOM användes original datan men decimaler lades till för att få följande struktur ”0,456” istället för ”456”. Cylindrarna fick då tillsynes samma höjd och blev rätt placerade utefter 2D planet.
5.2.2 ChanceJS och datagenerering
Under genomförandet och testning innan pilotstudien utfördes upptäcktes brister i den tänkta använda data. Dels var datasettet alldeles för litet och behövdes utökas inför utvärderingen. När leafletJS och mapbox inte gick att implementera i den tänkte lösningen försvann också meningen och möjligheten med koordinaterna i datasettet. För att ändå kunna försäkra god validitet på datan och att värdena är oföränderliga under varje iteration av experimentet implementerades det externa biblioteket ChanceJS (ChanceJS, 2020).
ChanceJS är ett JavaScript bibliotek med många funktioner för att på ett enkelt sätt generera slumptal jämfört mot inbyggda slump funktioner i JavaScript där en färdig seed funktioner inte heller existerar. Med hjälp utav ChanceJS möjligheter att använda seed kunde extra data med det använda datasettet som mall genereras effektivt inför varje iteration av experimentet.
5.3 Implementation
Följande kapitel presenterar hur byggstenar så som webbserver miljön, förbehandling av datan som användes för experimenten, artefakternas uppbyggnad och tillhörande valda Javascript bibliotek.
5.3.1 Webbserver och inläsning av JSON data med Fetch API
På grund av webbläsarnas Cross Origin Resource Sharing, förkortat CORS (MDNS, 2020) regler behövdes en webbserver sättas upp. Artefakterna är beroende av att använda sig utav lokala JSON filer vilket innehåller den data som ska visualiseras. Men CORS gör att det inte går och dela lokala resurser på detta sätt om inte en webbserver av någon form sätter CORS regler som gör det ok att hantera lokala resurser på ett önskvärt och säkert sätt. Önskvärt menas i detta fall att läsa in en lokal JSON fil med hjälp utav JavaScript API;et Fetch (MDNS- fetch, 2020). Webbservern som används är en Apache server under en lokal server installation med hjälp utav Xampp. Xampp är gratis och levereras under GPL- General Public Licence (Xampp, 2020).
JavaScript API;et Fetch() gör ett interface tillgängligt för att hämta resurser både lokalt och utanför ett nätverk. Fetch() har många likheter med XMLHttpRequest vilket men ger nya kraftfulla och flexibla verktyg att arbeta med. Fetch är promise basserat och inte asynkront men för detta arbete är ett mer kontrollerat och synkront flöde mer eftertraktat.
Fetch tillhandahåller .then() där utvecklaren har möjlighet att styra med callbacks vad som ska hända med svaret från tidigare steg. För detta arbete användes .then() för att enkelt styra och generera data innan den faktiska renderingen av datan som cylindrar kan ske.
JavaScripts inbyggda .forEach() funktion kan likt övriga for-each funktioner i språk som exempelvis PHP iterera över den hämtade datan. .forEach() används för att kunna använda den data som redan existerar i datasettet med hjälp av en lokal array. Datasettet har inte den önskade mängden data, men kan enkelt med hjälp utav seed och en loop slumpa fram data så fort inläsningen av det redan existerande datasettet är färdigt. Efter inläsning och all hantering av datan är färdig kallas funktionen addCylinders() och utritning av cylindrar basserat på den inlästa datan kan genomföras. Implementationen av Fetch() är ekvivalent i båda artefakterna och koden för funktionen presenteras i Figur 8. Implementationen av Fetch()1 kommer inte presenteras i kommande kapitel för artefakterna, för fullständig översyn se Appendix.
Figur 8 Implementation av Fetch() funktionen för artefakterna
1 https://github.com/redines/A17PONGO-EXJOBB2020/commit/54dfbd5
//function for retrieving data from json file with fetch API function fetchData() {
fetch('../data/SMHI_merged_simplified_data.json') .then((response) => {
return response.json();
})
.then((data) => { data.forEach(item => { heightARR.push(item.year) });
}).then(function () {
//adds wanted amount of values to heightArr
//representing the same data value year in dataset from SMHI //seed is used to get the same random numbers
for (var i = 0; i < 15460; i++) {
heightARR.push(seed.floating({ min: 1, max: 1500 })) }
}).then(function () { addCylinders();
});
}
5.3.2 Förbehandling av data
Datan vilket användes som grund bestod utav en .CSV fil vilket inkluderade alla mätstationer SMHI har i hela Sverige, både aktiva och inaktiva samt koordinaterna för dessa mätstationer.
Samt en .TXT fil vilket innehåller normaliserade värden på den uppmätta nederbörden hos SMHI;s mätstationer. Totalt innehåller datan från båda filerna mätvärden ifrån 1454 mätpunkter, där en mätpunkt är likvärdigt en mätstation vilket mätte nederbörden.
Inläsning och formatering av dessa två filer med data skedde med hjälp av ett eget utvecklat verktyg. Verktyget skapades för att ge full kontroll över slutresultatet och kunna anpassa datan för behovet. Verktyget byggdes i Python med biblioteket Pandas(Pandas, 2020) som är ett datahanteringsbibliotek. Med hjälp utav Pandas blev det enklare att skapa ett verktyg med få rader som gav det önskade resultatet där inbyggda funktioner i Pandas var tillräckliga. En styrka Pandas tillför är att automatiskt indexera alla värden i ett dataset. Med denna indexering är det väldigt enkelt att slå samman flera dataset likt hur data i en MySQL databas skulle gå tillväga genom att matcha index. Verktyget läser först in de två filerna vilket Pandas skapar en dataframe för2, vilket i Pandas är en representation av 2D tabulär data, se Figur 9.
Figur 9 Importerar biblioteket Pandas och läser in de två externa
filerna med data. En dataframe skapas för respektive fil.2 https://github.com/redines/A17PONGO-EXJOBB2020/commit/fb7122d import pandas as pd
dataFile =
'data/SMHI_month_year_normal_61_90_precipitation_mm_ORIGINALDATA.txt' stations =
'data/SMHI_metobs_precipitationType24Hours_all_sites_ORIGINALDATA.csv'
#Read CSV file content and store in dataFrame, also converts City column in data to a new string with no whitespace
df = pd.read_csv(stations, encoding='utf-8', sep=';') dft = pd.read_fwf(dataFile, encoding='utf-8')
Dataframes kan hanteras separat i förberedelse för att förenas med rätt struktur och data men använder sig utav samma funktioner. I verktyget hanteras först .CSV filen med data om alla SMHI;s mätstationer. Dataset kan i många fall innehålla oönskade data kolumner eller rader. Med Pandas kan denna data enkelt exkluderas vilket i detta fall fanns icke-nödvändiga kolumner med data som inte skulle användas. Dessa exkluderas med den inbyggda funktionen drop()3. drop() kan ta en Array av kolumner som ska exkluderas och tillvalet axis=1 måste användas för att specificera orienteringen då Pandas kan exkludera data i både X och Y led. Inplace=true gör att exkluderingen genomförs, se Figur 10.
Figur 10 Exkludering av kolumner med icke-nödvändig data
Vid exkludering och all form utav större förändring av data är det viktigt och se till så datan är korrekt strukturerad och index värden återställs för att behålla kopplingen mellan datasetten4. Återställning av index värden i detta skede gör det enklare att slå samman båda dataseten. Funktionen sort() gör det enkelt att välja en kolumn vilket automatiskt sorteras stigande om, inget annat anges till funktionen. Efter datan har sorterats används funktionen reset_index() för att återställa indexvärdena. Återställning av indexvärdena innebär att även efter en sortering så behåller varje rad sitt indexvärde. För att säkerställa så varje rad efter sortering får ett nytt index värde i rätt ordning lämpligt till sorteringen behövs reset_index() funktionen. Tillvalet drop=true ser till att alla gamla index värden släpps helt, annars kommer en ny kolumn skapas för dessa värden i den slutgiltiga JSON-filen som inte är önskvärt att behålla. Till sist kan slutresultatet skrivas ut till konsolen för att verifiera att önskad struktur och innehåll finns, Se Figur 11.
Figur 11 Sorterar datan i Id kolumnen och återställer index för den
sorterade datan.3 https://github.com/redines/A17PONGO-EXJOBB2020/commit/dfd8657
print("---DF---")
#Remove unwanted height and active column, only keeping wanted columns id, namn, Latitud and Longitude
df.drop(['Höjd (m)', 'Aktiv'], axis=1, inplace=True)
#Sort values in column Id ascending from .CSV file dfsort = df.sort_values(by=['Id'])
#Resets index to make dataframes match by index dfsort = dfsort.reset_index(drop=True)
print(dfsort.columns) print(dfsort)
Stegen beskrivna och kod visad i Figur 10 samt Figur 11 är ekvivalent för hantering av innehållet i båda dataseten och kommer därför inte beskrivas igen. För fullständig kod med kommentering av funktionalitet, se appendix för komplett lösning samt Figur 12 för exempel på en slutgiltig dataframe efter ovanstående kod har exekverats.
Figur 12 Resulterande dataframe utskriven i terminalen.
Efter att dataseten har formaterats korrekt kan Pandas utföra en operation likt hur databaser kan slå samman olika tabeller med join. Funktionen merge() gör det möjligt att utföra databas liknande joins på kolumner5. I tidigare steg genomfördes sortering och återindexering av datan för att skapa en gemensam kolumn där varje rad också kan matchas mot ett gemensamt index, vilket går att utföra en inner join på. Inner join vilket är en vanlig operation i SQL databaser vilket går att utföra även i Pandas. Funktionen merge() matas med valda dataframes att slåsamman med alternativ för hur sammanslagningen ska ske. I detta fall, eftersom en existerande kolumn av index värden finns i båda dataseten som är lika, används valen right_index=True och left_index=True. Resultatet av detta blir en sammanslagen dataframe där vänstra och högra datasetet ska använda index kolumnen för att utföra en inner join, se Figur 13.
Figur 13 Exempel på användning av Pandas merge funktion för att
slå samman två dataframes.Tillsist kan den slutgiltiga dataframen med båda datasetens innehåll skrivas till fil med Pandas to_json() funktionen. En sista kolumn tas dock bort vilket inte behövs längre samt en sista verifiering att datan har den önskade strukturen och innehållet innan skrivning till fil.
Ingen bra kontroll av innehållet innan skrivning togs fram för att automatisera processen ytligare med tanke på de simpla krav som ställs på verktyget för tillfället. Istället används kommentarer för att kommentera bort raden vilket utför skriv operationen, för att sedan ta bort kommentaren när skrivning önskas ske.
print("---RESULT---") mergedData =
pd.merge(dfsort,dftsort, right_index=True, left_index=True)
Med Pandas to_json()6 funktion går det alltså att skriva till en fil med ändelsen .JSON. Om filen inte existerar kommer funktionen att skapa en alternativt skriva över en redan existerande fil. Tillvalen force_ascii=True säkerställer att specialtecken som åäö skrivs i ascii kod, vilket är önskvärt för hantering av dessa tecken. Tillvalet orient=”records” är ett praktiskt tillval om en array av Json-objekt är önskat vilket detta tillval ser till att organisera varje rad efter, se Figur 14 för kodexempel samt se Figur 15 för den resulterande JSON filen.
Figur 14 Exempel kod på hur en dataframe i pandas kan skrivas till
en Json-fil med funktionen to_json().Figur 15 Utdrag ur resulterande .Json filens innehåll.
#Removing last not needed column after sorting and mergind with index mergedData.drop('klimnr', axis=1, inplace=True)
print(mergedData)
#write restructured data to json format
mergedData.to_json("data/SMHI_merged_simplified_data.json", force_ascii=True, orient="records")
[ {
"index":247,
"Id":52230,
"Namn":"Falsterbo",
"Latitud":55.3836,
"Longitud":12.8203,
"year":490.6 } …..
]
5.3.3 Visualisering med ThreeJS
ThreeJS utnyttjar HTML5 elementet canvas för att kunna visualisera grafik och en html fil krävs även för att kunna läsa in biblioteket med <script> taggen. All egenutvecklad ThreeJS kod exekveras i en extern fil vilket också behöver refereras till i HTML-filen. HTML-filen och den externa JavaScript filen presenteras i Appendix A och Appendix B. ThreeJS biblioteket kan användas på olika sätt tillexempel en lokal fil vilket importeras in med en
<script> tagg eller importeras in som en JavaScript modul via en packethanterare. För detta arbete valdes att ladda ner den senaste versionen vid tidpunkten då artefakten skapades och importera den lokala filen manuellt med <script> taggen. Detta skapar en bättre möjlighet att kunna återskapa arbetet i framtiden. Att importera bibliotek på detta sätt gör att varje individuell funktionalitet också behöver importeras på samma sätt, i detta fall filen för att kunna använda OrbitControls samt biblioteket ChanceJS för seedad slumptals generering.
Ett canvas-element krävs för att kunna rendera grafik, detta element kan skapas direkt med JavaScript men för att få en tydligare separeringar skapas canvas-elementet manuellt7 i den redan existerande HTML-filen och ett id ges för att kunna referera till elementet, se Figur 16 och för den kompletta HTML-filen se appendix A.
Figur 16 Exempel på HTML-fil för att komma igång med ThreeJS.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>THREEJS ARTEFAKT</title>
</head>
<body>
<canvas id="map"></canvas>
<!--External Javascript-->
<script src="../lib/threejs/three.js"></script>
<script src="../lib/threejs/OrbitControls.js"></script>
<script src="../lib/chance.min.js"></script>
<script src="threejs.js"></script>
</body>
</html>
Med canvas-elementet som referens för att kunna visa något behövs utöver det tre saker: en scen, kamera och en renderare. Scenen8 skapar en miljö kameran kan leva inom och objekt kan visualiseras, det är sedan renderarens jobb att rendera scenen och kameran. Kameran gör det möjligt att se den renderade scenen med innehållande objekt. Det första som måste skapas är en scen och kräver inga tillhörande variabler, se figur 17.
Figur 17 Kod för att skapa en 3D scen
En kamera måste skapas för att ge möjlighet att kunna röra sig i den renderade scenen och se scenens innehåll. I detta fall användes ThreeJS kameran PerspectiveCamera9 vilket är byggd för att försöka härma det mänskliga ögat. Till kameran följer ett antal obligatoriska variabler vilket avgöra Aspekt ration(bildformat), Field of view(Synfält), near och far variabler för hur långt bort samt hur nära kameran är påverkar vad som renderas i scenen. Det innebär att objekt vilket är längre bort än far variabeln eller närmare än near variabeln inte kommer renderas.
Aspekt ratio bestämmer förhållandet mellan bildens bredd och höjd. Denna variabel bör oftast bestå utav resultatet från formeln bredd/höjd för att undvika att skapa en missanpassad rendering av skärmen. Field of View är ett givet ögonblick som kan observeras av synen eller i detta fall kameran. Relaterat till dator renderad 3D är det hur mycket av en scen som kan visas vid ett givet tillfälle. Se Figur 18 för exempel kod på en uppsättning av kameran med tillhörande variabler9.
Figur 18 Konfigurering av en kamera till ThreeJS scenen.
8 https://github.com/redines/A17PONGO-EXJOBB2020/commit/f09310a
9 https://github.com/redines/A17PONGO-EXJOBB2020/commit/f09310a
//Setting up threejs
const FOV = 45;
const WIDTH = window.innerWidth;
const HEIGHT = window.innerHeight;
const ASPECT = WIDTH / HEIGHT;
const NEAR = 0.1;
const FAR = 10000;
const camera = new THREE.PerspectiveCamera(FOV, ASPECT, NEAR, FAR);
var scene = new THREE.Scene();
Till sist skapas en renderare1 0 som kopplas till det tidigare skapade HTML canvas- elementet.
Här behövs även storleken sättas för den renderade applikationen, även här används höjden och bredden. Eftersom applikationen är tänkt att användas i helskärm sätts då höjd och bredd lika med den fulla tillgängliga ytan med hjälp av window.innerWidth respektive windows.innerHeight, se Figur 19.
Figur 19 Konfigurering av en ThreeJS renderare.
När kamera, scen och renderaren är uppsatt korrekt är det nu möjligt att börja lägga till 3D objekt. ThreeJS ger många färdiga objekt att rendera vilket med funktionen scene.add() enkelt kan lägga till objekt i scenen för rendering. Tanken var från början att utnyttja existerande kartbibliotek som Leaflet. Problemet var dock att Leaflet inte stödjer WebGL eller den form av 3D som önskades nativt och de bibliotek som hade nativt stöd var antingen experimentella öppna projekt eller kommerciella. Istället skapas ett platt 2D plan vilket kan med en bild av jorden tagen från rymden användas som en textur på det skapade planet och då fungera, i viss mån, som en karta. Önskad funktionalitet som att kunna använda GPS koordinater för att placera ut data kopplad till koordinaten gick förlorad.
För att skapa ett 2D plan kan ThreeJS existerande geometriska objekt PlaneBufferGeometry()1 1 användas. PlaneBufferGeometry() skapar en platt figur kvadrat där höjd, bredd och tjocklek går att styra med tillhörande variabler. Tjocklek i detta fall använder default värdet 1 men sätter en stor yta att rendera.
För att lägga på världskartan som en textur används funktionen TextureLoader() och MeshBasicMaterial(). Functionen TextureLoader() används för att peka på och ladda in en extern bild att använda som en textur med hjälp av den tillhörande .load() funktionen.
.load() behöver en sökväg där resursen ligger vilket sedan sparar den till en användbar variabel. Variabeln med den inladdade texturen kan du användas i MeshBasicMaterial() funktionens map objekt vilket mappar texturen till den 3D objekt vilket texturen ska
appliceras på.
MeshBasicMaterial() och PlaneBufferGeometry() appliceras sedan till en mesh där även rätt X och Y positioner sätts för att placera planet på rätt axlar och skapa då något som kommer se ut som en platt yta horisontellt. Till sist kan det slutgiltigt skapade planet läggas till i scenen med .add() funktionen, se figur 20 för kod exempel.
1 0 https://github.com/redines/A17PONGO-EXJOBB2020/commit/a746c44
var canvas = document.getElementById('map');
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
const renderer = new THREE.WebGLRenderer({ alpha: true,
canvas: canvas });
Figur 20 Skapar ett platt plan med en bild på norden som textur.
Tillsist för att utnyttja renderaren och faktiskt visualisera något på sidan skapas en animate()1 2 funktion. Den egna animate() funktionen kallar på den underliggande funktionen render() i renderer som tar två variabler, scenen och kameran, se Figur 21 och appendix B för den slutgiltiga filen.
Figur 21 Funktion vilket renderar scen och kamera med alla
cylinder objekt.Efter att en scen existerar är andra objekt nu redo att kunna ritas ut i den skapade scenen.
ThreeJS erbjuder alla grund geometriska former men för denna artefakt är CylinderBufferGeometry objektet intressant. Med en FOR-loop går det att effektivt skapa och rita ut valfri mängd cylindrar. ThreeJS objekt MeshBasicMaterial kan applicera en färg på varje cylinder, vilket används här för att enklare särskilja på alla cylindrar och skapa en ännu mer intressant visualisering. Beroende på den visualiserade datans värde bestäms höjden på cylindern. Datasettet innehåller värden med decimaler vilket gör att JavaScript funktionen Math.random() gör det möjligt att avrunda till närmaste heltal och på så sätt säkerställa korrekt hantering av värdet. Det är även här värt och nämna att höjden på
//Adding plane for showing the map as a texture var texture = new
THREE.TextureLoader().load('../img/3_no_ice_clouds_16k_modified.jpg');
var pm = new THREE.MeshBasicMaterial({ map: texture });
var pg = new THREE.PlaneBufferGeometry(10000, 10000);
var mesh = new THREE.Mesh(pg, pm);
mesh.position.y = -250;
mesh.rotation.x = -Math.PI / 2;
scene.add(mesh);
//Animate funktion to draw 3D object to scene function animate() {
requestAnimationFrame(animate);
controls.update();
renderer.render(scene, camera);
}
animate();
Efter att en cylinder skapats samt ett tillhörande material kan dessa gemensamt lagras under ThreeJS Mesh objekt vilket tar materialet och 3D objektet som parametrar1 3. Resultatet blir ett 3D objekt med färg i form av en cylinder vilket kan användas för ytterligare modifiering men för detta arbete räcker detta och cylindern kan nu renderas till scenen. För att säkerställa god validitet samt efterlikna ett verkligt scenario slumpas cylinderns utritade position med ett seedat slumptal. Till sist för att rita ut den färdiga cylindern till scenen kan scen objektets funktion .add() tillkallas med cylindern som parameter, se Figur 22 för kod exempel och Appendix A samt B för den kompletta ThreeJS artefaktens kod. Figur 23 presenterar den slutgiltiga applikationen.
Figur 22 Kod exempel på rendering av cylinder objekt i ThreeJS
med färgsättning baserat på cylinderns höjd.1 2https://github.com/redines/A17PONGO-EXJOBB2020/commit/eb7731c var material;
for (var i = 0; i < 1000; i++) { if (heightARR[i] > 700) {
material = new THREE.MeshBasicMaterial({ color: red });
} else if (heightARR[i] > 500) {
material = new THREE.MeshBasicMaterial({ color: yellow });
} else {
material = new THREE.MeshBasicMaterial({ color: green });
}
var geometry = new THREE.CylinderBufferGeometry(5, 5, Math.round(heightARR[i]), 32);
var cylinder = new THREE.Mesh(geometry, material);
cylinder.position.x = seed.floating({ min: -1800, max: -800 });
cylinder.position.z = seed.floating({ min: -600, max: 2500 });
scene.add(cylinder);
}
Figur 23 Slutgiltiga resultatet av presenterad ThreeJS kod.
5.3.4 Visualisering med X3DOM
För att utveckla en X3DOM applikation krävs en HTML fil1 4 och i de flesta fall är det tillräckligt med en referens till X3DOM biblioteket. Men för denna applikation då objekt måste skapas mer dynamiskt används även en extern JavaScript fil, HTML och JavaScript filen presenteras komplett i appendix C och appendix D. Figur 24 visar ett första stadie av HTML filen för att komma igång med X3DOM utveckling.
Figur 24 Början på en X3DOM applikation
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script src="../lib/x3dom-1.8.1/x3dom-full.js"></script>
<link rel="stylesheet" href="../lib/x3dom-1.8.1/x3dom.css">
<title>X3DOM ARTEFAKT</title>
</head>
<body>
<x3d>
<scene width="100%" height ="100%">
</scene>
</x3d>
<script src="../lib/chance.min.js"></script>
<script src="x3dom.js"></script>
</body>
</html>
Större delen av applikationen utgår ifrån HTML filen men med hjälp av JavaScript går det att skapa dynamik. I X3DOM är det enklare och mindre steg för att skapa en kamera och scen för att visa 3D objekt. Taggarna <x3d> och <scene> är allt som krävs för att skapa en färdig scen med en kamera. Inom <scene> taggen går det nu att lägga till 3D objekt med <shapes>
taggen och till en början skapas ett 2D plan vilket karttexturen skall appliceras på. <shapes>
taggen tar en under tagg, i detta fall <plane>, men kan även vara <cylinder> som kommer användas senare. Se Figur 25 för exempel kod på att skapa ett 2D plan i X3DOM.
Figur 25 Exempel på hur ett 2D plan kan skapas i X3DOM
När ett 3D objekt existerar går det att fritt lägga till texturer på objektet vilket kräver taggen
<appearance> och undertaggen <ImageTexture>. <appearance> applicerar
<ImageTexture> på ett objekt och det enda som krävs är att applicera en bild som textur är att sätta en referens till bilden som skall användas1 5, se Figur 26.
Figur 26 Exempel på applicering av en bild som textur på skapade
2D planet i Figur 25<shape>
<plane solid="true" size="32 32"></plane>
</shape>
<shape>
<appearance>
<ImageTexture
url="../img/3_no_ice_clouds_16k_modified.jpg"><ImageTexture/>
</appearance>
<plane solid="true" size="32 32"></plane>
</shape>
En kamera behöver inte programmeras in likt ThreeJS men med <Viewpoint> taggen går det att bestämma en start vy applikationen ska placera kameran på som standard1 6. <Viewpoint>
taggen tar ett antal egenskaper vilket avgöra hur stort synfältet ska vara, orientering, hur långt respektive hur nära objekt relativt från kamerans placering ska renderas samt
mittpunkten kameran skall rotera runt. Alla dessa egenskaper behöver sättas om en standard punkt för kameran skall användas men denna tagg behöver inte skrivas manuellt då X3DOM har ett inbyggt debugging verktyg. När applikationen exekveras i webbläsaren går det att med tangenten D öppna detta verktyg och sedan trycka på V för att hämta alla inställningar till
<Viewpoint> taggen beroende på hur kameran är ställd när V tangenten trycks ner. Detta sparade mycket tid då istället för att ändra värden tills rätt värden hittades kunde hela taggen kopieras från debugging verktyget när kameran vinklats på önskat sätt. Se Figur 27 för exempel på hur <Viewpoint> taggen kan se ut.
