Oklart. Applikation för visualisering av osäkerhet i väderdata. Matthias Berg Daniel Böök Johanna Elmesiöö Emil Juopperi Jens Kaske Adam Söderström

Transkript

1 Linköpings universitet Insitutionen för teknik och naturvetenskap Kandidatarbete Medieteknik Vårterminen 2016 LiU-ITN-TEK-G--16/017--SE Oklart Applikation för visualisering av osäkerhet i väderdata Matthias Berg Daniel Böök Johanna Elmesiöö Emil Juopperi Jens Kaske Adam Söderström Examinator: Karljohan Lundin Palmerius Linköpings universitet SE Linköping ,

2 Sammanfattning Oklart är en applikation som visualiserar (utöver traditionell väderdata) osäkerheter i prognoserna. Tekniker för viusalisering av osäkerhet utforskas med ambitionen att osäkerheten ska ge användaren upplevelsen av att applikationen tillhandahåller utförligare information än andra källor för väderprognoser. En skalbar systemarkitektur har använts och både server- och klientsidan av applikationen har byggts med moderna verktyg för webbaserad utveckling. Möjligheterna är stora för vidare utveckling och nya tekniker för visualisering av väderdata presenteras tillsammans med resultat av användarstudier. Arbetet har skett enligt en etablerad agil utvecklingsmetodik med syftet att ge studenterna erfarenhet av detta samt för att få utvecklingen att komma så långt som möjligt. Programmering har skett både i par och individuellt och versionshantering har genomsyrat rutinerna för utvecklingen. Flera verktyg med olika funktioner (dokumentation, versionshantering, bibliotektshantering) inom utvecklingsmetodik har använts och beskrivs ytterligare i rapporten. Resultatet är ett webbaserat gränssnitt med visualiering av spatial osäkerhet. Visualisering i form av en graf med ett markerat intervall samt visualisering i form av dynamiska ikoner som med hänsyn till flera parametrar i väderprognosen genereras genom att lägga bilder med alpha-kanal över varandra. i

3 Innehåll Typografiska konventioner och termer iv 1 Inledning Syfte Frågeställning Avgränsningar Bakgrund Relaterat arbete Framtagning av väderprognos Osäkerhetsberäkning Osäkerhetsvisualisering Verktyg, språk och API:er HTML och CSS JavaScript och RequireJS Node och osäkerhetsberäkningar ExpressJS Osäkerhetsvisualisering Dynamiska ikoner Intervall i grafen Bower Bootstrap Google visualization API och Highcharts Karta Arbetssätt Utvecklingsmetodik Dokumentation JSDoc Mötesrutiner ii

4 INNEHÅLL iii 4.4 Testning Kravhantering Kommunikation Versionshantering Användartest Resultat Karta Tabell Graf Analys och diskussion Utvecklingsmetod Språk och APIer JavaScript och TypeScript Googles API:er och Highcharts Bootstrap RequireJS, varför inte AngularJS? Implementation av karta MEAN-stack Testning Kravhantering Design Arbetet i ett vidare sammanhang Slutsatser Frågeställningar Framtida utveckling Litteraturförteckning 25 APPENDICES 27 A Individuellt bidrag 28

5 Typografiska konventioner och termer Kursiv text anger en engelsk term. Kursiv och fetstil anger en programvara eller ett verktyg. SMHI är en förkortning för Sveriges Meteorologiska och Hydrologiska Institut. YR är en norsk hemsida för information om väder. Ordet agil används som en svensk översättning av det engelska ordet agile. API står för applikationsprogrammeringsgränssnitt (från engelskans application programming interface). Open-source innebär att källkoden inte ägs av någon och är fri att använda, läsa och modifiera. UML är en förkortning för Unified Modeling Language Temporal osäkerhetsberäkning innebär att förändringar i tiden tas med i algoritmen. iv

6 Kapitel 1 Inledning Att veta hur vädret förändras under en snar framtid är viktigt för många människor. Dels finns det de som har yrken där vädret har en stor inverkan, såsom lantbrukare och sjöfartsarbetare, men det finns även de som bara vill veta om de ska ta cykeln till jobbet eller inte. Vädret är ofta väldigt opålitligt, vilket ofta resulterar i att lantbrukaren kanske skördar en vecka för sent eller att man får cykla hem i regnet. För att undvika detta kan en osäkerhet av vädret visualiseras. Med hjälp av beräkningar av hur vädret är i närliggande område samt hur vädret förändras i framtiden ger data som kan visa hur säker själva prognosen faktiskt är. 1.1 Syfte Syftet med projektet är att gruppen ska utveckla en webbaserad applikation som visualiserar (utöver traditionell väderdata) osäkerheter i väderprognoser. Huvudsakligen ämnar projektet att utforska möjligheter i hur osäkerheter kan visualiseras så att det för en användare blir intuitivt. Projektet har även syftet att gruppen ska använda en agil utvecklingsmetodik för att som en utvecklingsgrupp skapa en webbaserad applikation. En agil utvecklingsmetodik används dels med syftet att projektet ska få ett så bra resultat som möjligt och dels i pedagogiskt syfte för att förbereda studenterna på liknande arbete i arbetslivet. 1.2 Frågeställning Gruppens frågeställningar fokuserar främst på den tekniska delen av utvecklingen. Anledningen till att gruppen valde följande frågeställningar var för att de valen skulle påverka utvecklingen av projektet genom hela arbetets gång. Hur ska det valda programmeringsspråket, JavaScript, hanteras på ett sådant sätt att gruppen kan arbeta på projektet tillsammans? Hur ska gruppen gå till väga för att se till att visualiseringen av osäkerhet i väderdata framgår på ett så begripligt sätt som möjligt? Vilka typer av osäkerhet kan beräknas utifrån SMHI:s data? Vilka alternativ finns för visualisering av väderprognos-data och hur kan dessa komplettera varandra? 1

7 KAPITEL 1. INLEDNING Avgränsningar I projektet har gruppen enbart tagit fram spatiala osäkerheter. Gruppen valde att inte lägga mer fokus på andra typer av osäkerhetsberäkningar utan fokuserade istället på visualisering av osäkerheterna. Till exempel så beräknades inte temporala osäkerheter eller ensembleprognoser. Gruppen jämförde inte heller olika datakällor så som SMHI och Yr. Gruppen valde att inte lägga stor vikt vid att göra hemsidan mobilanpassad. Detta för att visualiseringarna på hemsidan syns bäst på en datorskärm. Det är ett symptom av att projektet har haft syftet att visa ett koncept och inte att distribuera en offentlig version. 1.4 Bakgrund Gruppen har som uppgift att ta fram en webbaserad väderapplikation. Applikationen använder SM- HI:s API för väderdata för att visa, utöver traditionella data, även spatiala och temporala osäkerheter. Till exempel om väderleksrapporter visar på solsken i Norrköping men regn nära inpå så ska applikationen visualisera att det finns risk för regn i Norrköping. Kunden föreslår att använda andra potentiella källor för osäkerhet så som att jämföra YR och SMHI tillsammans med beräkningar i närliggande data. På projektet arbetar sex stycken erfarna utvecklare. Gruppen arbetar enligt en agil utvecklingsmetod. Eftersom applikationen är webbaserad och responsiv fungerar den oavsett om den används på en dator eller på en mobil.

8 Kapitel 2 Relaterat arbete Under inledningen av arbetet utfördes en förstudie. Under förstudien studerades arbete relaterat till projektet, som beskrivs nedan. Under förstudien jämfördes även olika tekniska lösningar, och föroch nackdelar med olika tekniska lösningar viktades emot varandra. Förstudien genomfördes för att gruppen skulle få en bättre insikt i hur en väderprognos tas fram men även hur data visualiseras på ett tydligt sätt. 2.1 Framtagning av väderprognos SMHI tar fram sina väderprognoser i tre steg. Det första steget är att samla in väderdata, datan bearbetas sedan i en superdator och till sist bestämmer meteorologerna vilken modell som är lämpligast att använda till nästa prognos. [33] Första steget, som är att samla in data, går ut på att få en så heltäckande bild som möjligt av tillståndet i lufthavet. De parametrar som ingår i insamlandet är till exempel lufttryck, vind, temperatur, fuktighet och moln som observeras. Datan samlas in från ett flertal olika källor så som fartyg, flygplan, väderballonger, väderradar, satelliter och från automatiska samt manuella väderobservationer. [33] Steg två är bearbetning av datan. Den insamlade datan sammanställs i superdatorer. Matematiska beräkningar görs sedan med hjälp av globala fysikaliska prognosmodeller. Värden för olika parametrar beräknas upp till tio dygn framåt. Meteorologer har möjlighet att gå in i databasen och ändra enstaka parametrar för att bättre fånga specifika välkända avvikelser i ett mindre område. [33] I steg tre finns rådata för prognoser, denna behöver nu bearbetas för att det ska bli en begriplig väderprognos som exempelvis kan presenteras på internet, i TV eller i radion. Datan förfinas i ett samarbete mellan meteorologer och datorer.[33] 2.2 Osäkerhetsberäkning Det är omöjligt att göra en exakt förutsägelse för hur vädret kommer att bli, detta beror på att atmosfären är ett kaotiskt system. Väderprognoser är baserade på numeriska väderprognosmodeller. Felet ökar med prognoslängd och efter en viss tid påminner prognosen inte om det verkliga vädret. Feltillväxten kan beskrivas genom den icke-linjära ekvationen 2.1. Ekvationen visar hur variabeln Y vid en tidpunkt n+1 beror på värdet på Y i tidpunken n och på en parameter a. Y kan till exempel vara temperaturen i en viss punkt. Ekvationen är förenklad och inte en modell av den verkliga atmosfären [31]. 3

9 KAPITEL 2. RELATERAT ARBETE 4 Y (n + 1) = a Y (n) Y (n) 2 (2.1) För att uppskatta hur vädret kommer att bli kan också ensmebleprognoser beräknas. Ensembleprognoser innebär att man har flera lika rimliga uppskattningar om hur initialtillståndet ser ut, och/eller flera olika modell-designer som är lika rimliga vilket kommer att ge olika prognoser. Detta innebär att ett kluster av prognoser kan tas fram som är baserade på olika men lika rimliga uppskattningar av hur initialtillståndet ser ut och/eller lika rimliga modell-designer. Sannolikheten för att den verkliga prognosen finns i klustret bygger på tre saker. Dessa är antal medlemmar ett sådant kluster innehåller, hur modell-designerna liknar den verkliga atmosfären och hur de olika initialtillstånden reflekterar det sanna initiala atmosfärstillståndet [31]. 2.3 Osäkerhetsvisualisering Eftersom osäkerhetsvisualisering för väderprognoser är ett relativt nytt och smalt område upplevde gruppen att det var svårt att hitta information och tidigare forskning i området. Den information gruppen hittade om ämnet behandlade mest hur osäkerhetsvisualiseringen kunde visas i kartan med hjälp av färger, genomskinlighet och storlek på ikoner [29]. Dessa visualiseringar upplevde gruppen dock var svårförståeliga för den större målgruppen och därför förkastades dessa metoder. Gruppen läste även en sammanfattning av en rapport skriven av Anders Ynnerman [36]. Rapporten behandlar osäkerhetsvisualisering för stora datamängder genom direkt volymsrendering, vilket inte är direkt relevant till projektet. Däremot berör rapporten hur osäkerhet kan visualiseras via färgegenskaper, genomskinlighet och animering vilket gav gruppen inspiration.

10 Kapitel 3 Verktyg, språk och API:er Verktyg, språk och API:er för projektet valdes under förstudien. Det här kapitlet redogör för vad som har använts och varför vi valt att använda just de språken och API:erna. Kapitlet går även in mer i detalj om hur de olika tekniska verktygen, och hjälpmedlen fungerar samt hur de varit till nytta i projektets utveckling. 3.1 HTML och CSS Den grundläggande standarden för webbsidor är kodning i HTML [11], CSS [6] och JavaScript [14] (JavaScript beskrivs nedan i 3.2). Gruppen lade grunden för webbapplikationen i dessa kodspråk. 3.2 JavaScript och RequireJS För att göra JavaScript objektorienterat och kunna hantera klasser används RequireJS [26]. Det blir objektorienterat i det avseendet att RequireJS läser in JavaScript-filer som moduler och att en modul kan hanteras som ett objekt. I en modulfil finns möjligheten att skapa privata och publika objekt/funktioner, något som inte är möjligt i JavaScript utan en modulläsare såsom RequireJS. I ett storskaligt projekt skulle RequireJS inte vara tillräckligt för att strukturera JavaScript koden utan då skulle ett mer sofistikerat ramverk med exempelvis ett fullt MVC (Model View Controller)-mönster [21], såsom AngularJS [1], vara att föredra. 3.3 Node och osäkerhetsberäkningar En server kan utvecklas i många olika programspråk. Node [22] tillåter utvecklare att skriva Java- Script på serversidan. Eftersom JavaScript är det språk som används på klientsidan skapar det möjligheter för att göra tröskeln mellan klient och server lägre för utvecklare. Med det menas att någon som tidigare endast jobbat på klientsidan även kan skriva kod till servern utan att behöva lära sig ett nytt språk [14]. SMHI:s API innehåller mer högupplöst data än vad som är relevant för applikationen. Datan har filtrerats genom att endast hämta information från 135 platser i Sverige. Varje plats motsvarar 9 GETrequests [12], 1 mitt på platsen och 8 runt om som används vid osäkerhetsberäkningarna. Informationen om vilka platser som data hämtas från sparas i en JSON-fil [16] med longitud- och latitudvärden som används då en url skapas. Ett problem som uppstår här är att svaret från hämtningen är från den 5

11 KAPITEL 3. VERKTYG, SPRÅK OCH API:ER 6 plats som ligger närmast i SMHI:s data och därför behöver servern vänta på svar för att sedan kunna hämta information kring den platsen. Då information har hämtats från den plats som ligger närmast den som står listad i JSON-filen skickas ytterligare 8 GET-requests inom 70 km omkring den platsen. Det högsta respektive lägsta värdet för alla 15 parametrar i de 72 tidpunkter som det finns prognoser för sparas och skickas tillsammans med datan för den angivna punkten till databasen. Detta resulterar i ett JavaScript-objekt (sparad i vår MongoDB databas) [20] med 135 fält (1 för varje plats) som var och en innehåller 3 listor med prognoser, 1 för minsta värden, 1 för största värden och 1 för värden som hämtats från den givna platsen. Att uppdatera databasen med data behöver ske då SMHI har uppdaterat sina prognoser, detta sker minst 6 gånger per dag. Trots att det sker dagligen är det såpass sällan att uppdateringen bör ske oberoende av användare, det vill säga att serverskriptet körs självständigt och att användare får den senaste datan från databasen. Informationen i databasen kan uppdateras en gång per dag utan att datan över det kommande dygnet blir mindre högupplöst eftersom det finns data för varje timme under de första 48 timmarna. Under utvecklingsperioden har datan uppdaterats genom att manuellt köra skriptet, innan en färdig version av applikationen släpps, som exekverar skriptet automatiskt. 3.4 ExpressJS För att snabbt komma igång med Node och skapa en fungerande server används ramverket ExpressJS [7]. ExpressJS skapar en filstruktur för projektet och innehåller funktioner som används på serversidan. 3.5 Osäkerhetsvisualisering Väderprognoserna innehåller inget mått på osäkerhet men en uppskattning av dess säkerhet görs genom att se på förändringar spatialt. Oberoende av hur osäkerheten beräknas är det en utmaning att visualisera osäkerheten så en användare kan ta till sig informationen. Under projektet har gruppen experimenterat med olika metoder för att göra osäkerhetetsinformation lättillgänglig. Det har resulterat i två typer av visualiseringar; dynamiska ikoner och intervall i grafen Dynamiska ikoner Genom att låta varje parameter påverka en del av ikonen kan ett stort antal unika ikoner genereras. I applikationen avgör parametern nederbördsintensitet antalet regndroppar i ikonen och molnmängd påverkar vilket moln som visas, se figur 3.2 och 3.1. Rymden som spänns upp av parametrarna är två dimensioner och antalet ikoner som kan skapas blir produkten av antalet nivåer i varje dimension. Med det menas att exempelvis resulterar 4 regndroppar och 4 moln i 16 olika ikoner. Lägger man till en färgskala för temperatur med 4 olika nivåer kan en prognos representeras av 54 olika ikoner. Ikonerna sparas som bilder med alpha-kanal och läggs över varandra för att generera en ikon, se figur 3.3. Genom att generera ikoner enligt den här metoden undviker man att bortse från en parameter på grund av en annan. Alla de parametrar som visualiseras i ikonerna behandlas lika med avsikten att ikonerna ska innehålla så mycket information som möjligt. Med färdiga ikoner ställs högre krav på att antalet ikoner ska vara stort nog för att täcka alla fall, genom att generera ikonerna får man med färre ikoner mer flexibilitet. Det är ett koncept med möjligheter för påbyggnad, de två parametrarna kan med enkelhet utökas till fler.

12 KAPITEL 3. VERKTYG, SPRÅK OCH API:ER 7 Figur 3.1: Lite molnighet Figur 3.2: Medelmycket regn Figur 3.3: Genererad ikon med lite molnighet och medelmycket regn Figur 3.4: Graf med osäkerhetsvisualisering De dynamiska ikoner som används i applikationen är ingen visualisering av osäkerheten i sig men tar hänsyn till varje parameter för sig och kan därmed fånga upp fall som annars hade förbisetts. Att lägga till en parametrar som beror på den beräknade osäkerheten (t.ex. risk för regn ) är möjligt och ger en direkt visualisering av osäkerhet i ikonerna Intervall i grafen Osäkerhetsberäkningarna resulterar i tre tidsserier med väderprognoser; två med minsta/största värden i ett område omkring den givna punkten och en med en prognos för den givna punkten. Grafen visualiserar detta genom att markera ett intervall mellan prognoserna för minsta och största värden samt en linje för prognosen för den givna punkten, se figur Bower För att hantera paket, ramverk och bibliotek har Bower [4] använts. Bower är en pakethanterare som förenklar installationen av korrekt version av exempelvis Bootstrap [3], Highcharts [10] och RequireJS [26] till projektet. Med Bower exkluderas paketen ifrån GitHub, och laddas ner separat till utvecklarens dator. Gruppen valde att använda Bower på grund av enkelheten i att varje utvecklare håller sig till samma version av de externa paketen [26].

13 KAPITEL 3. VERKTYG, SPRÅK OCH API:ER Bootstrap Bootstrap är ett HTML-, CSS- och JavaScript-ramverk för att skapa responsiva webbsidor, alltså sidor som skalar om innehållet beroende på fönsterstorlek. Bootstrap skriver över webbläsarens standarder och genom att inkludera detta ramverk kommer applikationen se likadan ut i till exempel Google Chrome och Mozilla Firefox[3]. 3.8 Google visualization API och Highcharts Då den data från SMHI innehåller många parametrar att redogöra för användaren ansågs att en tabell samt en graf skulle användas. De två olika verktyg som använts till detta är Google Visualization API och Highcharts. Två verktyg vars ändamål är att på ett interaktivt sätt åskådliggöra information [13][10]. 3.9 Karta Gruppen ansåg att en nödvändig komponent i applikationen var en interaktiv karta där en användare lätt ska kunna navigera och få en visuell väderprognos. En karta skulle inte bara göra det enklare för användaren att se vädret på en viss plats, utan även enklare kunna se vädret för platser i närheten. I JavaScript är det svårt och tidskrävande att skapa en karta från grunden. Det finns dock flera hjälpmedel och API:er för att åstadkomma detta. Några av de populäraste API:erna är Google Maps[9], Leaflet [18]och OpenLayers [24]. Det är dock ej någon större skillnad mellan dessa bibliotek. Eftersom Google är ett så stort företag med fler tjänster än bara Google Maps, som t.ex. platssök och vägbeskrivning, är det ett av de kraftfullare alternativen då dessa funktioner är lätta att integrera i Google Maps. Nackdelen med Google Maps är att det varken är gratis eller open-source. Eftersom det dock är det mest använda API:et finns det väldigt mycket information och guider om hur det kan användas, vilket är en stor hjälp för en utvecklare [14]. Leaflet och OpenLayers är de två mest populära open-source alternativen. OpenLayers brukar ses som det kraftfullare alternativet, med större flexibilitet och mer särdrag än det mer simpla och lättanvända Leaflet. Storleksmässigt skiljer de sig mycket. OpenLayers är ca 700kb stor medans Leaflet endast är 200kb, vilket säger en del om funktionaliteten och komplexiteten hos de två API:erna [18][24]. Både OpenLayers, Leafletjs och Google Maps arbetar med lager. Ett lager på kartan kan t.ex. vara en geografisk karta och ovanpå det kan det ligga ytterligare ett lager som markerar vägar eller radarbilder för väder. Vanligast är att grundlagret, ofta ett geografiskt lagret, är ett tile-layer och att lager som ligger ovanpå är vector-layers [24][18][9]. Ett tile-layer består av tiles, eller brickor av färdigrenderade bilder som hämtas från en databas. Dessa tiles läses in olika beroende på vilken zoomnivå användaren är på. På en hög zoomnivå kommer t.ex. endast landsgränser ritas ut på kartan, medan på en låg zoomnivå kommer städer och gator ritas ut med högre precision. Se figur 3.5 för en visualisering av hur tiles fungerar[25]. Ett vektorlager ligger oftast ovanpå ett tile-lager och används för att visualisera data eller punkter på kartan. I figur 3.6 visas hur ett vektorlager visar molnighet i olika städer. Här är grundlagret ett tilelager som ritar ut den geografiska kartan, och ett vektorlager ovanpå som ritar ut ikoner i intressanta punkter.

14 KAPITEL 3. VERKTYG, SPRÅK OCH API:ER 9 Figur 3.5: Representation av tiles Figur 3.6: Karta med vektorlager

15 Kapitel 4 Arbetssätt Utvecklingen av applikationen har skett med metoder och verktyg avsedda för agil utveckling. Det här kapitlet innehåller beskrivningar av de olika delarna, så som mötesrutiner, testning, kravhantering, kommunikation och versionshantering. I kapitlet så kommer det också förklaras vad som skett i varje sprint. 4.1 Utvecklingsmetodik Gruppen arbetar enligt den agila utvecklingsmetoden Scrum. För att arbeta enligt Scrum delas arbetet in i ett flertal sprint. Enligt Scrum har gruppen en sprint 0 under vilken arbetet planerades och en förstudie genomfördes. Under denna sprint beslutade gruppen att varje sprint skulle vara två veckor långa. Vissa sprints blev lite längre på grund av ledighet. Även saker som vilka verktyg, API:er samt vilka förstudier som behövde göras diskuterades [27]. I sprint 1 började gruppen att spåna fram en grov skiss av hur sidan skulle se ut på en whiteboardtavla. Under sprint 1 parprogrammerade gruppen, delvis för att gruppen fann det svårt att dela in arbetet i mindre delar men även för att hjälpa varandra att komma igång med arbetet. I slutet av sprint 1 hade en simpel design samt hemsidans komponenter implementerats. Hemsidans komponenter är en karta, en graf, en tabell, en slider och en sökruta. En första version släpptes av gruppen, se 4.1. När gruppen planerade nästa sprint gjordes en prototyp för hemsidan i Photoshop, se 4.2. Figur 4.1: Den första färdigställda versionen av hemsidan 10

16 KAPITEL 4. ARBETSSÄTT 11 Figur 4.2: Prototyp för hemsidan gjord i Photoshop I sprint 2 utvecklades funktionalitet för hemsidans olika komponenter. Gruppen gjorde även användartester för att få återkoppling på hemsidans funktionalitet. Se 4.3 för den andra versionen av hemsidan. Figur 4.3: Den andra färdigställda versionen av hemsidan I sprint 3 beslutade gruppen att inte använda Googles API för tabell och graf. Tabellen skapades istället i HTML och grafen skapades med hjälp av Highcharts. En slider skapades och kopplades till SMHI:s data för att kunna navigera framåt i tiden och därigenom visa framtida prognoser. Se 4.4 för den tredje versionen av hemsidan [10]. I sprint 4 fungerade de olika komponenterna var för sig, gruppen implementerade funktionalitet så att de olika komponenterna kunde interagera med varandra. Om användaren exempelvis klickar på en plats i kartan så ska både grafen och tabellen uppdateras och visa den valda platsen. Användaren kan även använda sökfältet för att söka på en stad och sidans övriga komponenter uppdateras då till den valda staden. I tabellen kommer den valda staden och de fyra närmsta städerna att visas. I tabellen visas en ikon för vädret, temperatur, nederbörd och vind. Klickar användaren på någon av dessa i tabellen så visas den valda vädertypen i grafen. En graf ritas upp då parametrarna temperatur eller vindhastighet är vald, visas i figur 5.4. Om användaren väljer nederbörd i tabellen så ritas ett

17 KAPITEL 4. ARBETSSÄTT 12 Figur 4.4: Den tredje färdigställda versionen av hemsidan stapeldiagram upp. Stapeldiagrammet ritar upp värdet ifrån den aktuella platsen som staplar och det möjliga maxvärdet för nederbörd ritas upp i ljusblått över den andra stapeln 5.5. Se 4.5 för en version av hemsidan med både dessa komponenter. Figur 4.5: Den fjärde färdigställda versionen av hemsidan 4.2 Dokumentation Under hela projektets gång fördes protokoll vid varje möte. Dessa var till för att förtydliga arbetet och dess bestämmelser och finns tillgängliga för hela gruppen på Google Drive. Utöver detta gjordes automatiserad dokumentation med hjälp av Trello[34] samt GitHub som skapar tidsstämplar för utfört arbete, Trello fungerar dessutom som projektets backlog. Se 4.6 för en bild på hur användargränssnittet ser ut [8].

18 KAPITEL 4. ARBETSSÄTT 13 Figur 4.6: Trellos användargränssnitt JSDoc Utvecklingsgruppen valde att kommentera alla funktioner i koden enligt JSDoc[15], ett märkspråk för JavaScript. Block-kommentarerna är tydliga med vilka parametrar som hanteras i funktionen, samt vad funktionen returnerar [14]. Ett exempel taget ur filen map.js: /** * Constructor for the map Map smhidata Data from smhi */ JSDoc skapar efter kompilering av koden en HTML-genererad hemsida med alla komponenternas funktioner och konstruktorer. Denna sida kan både utvecklarna, såväl som kunden, använda för att öka förståelsen för koden och få en bättre inblick i vad komponenterna gör. Hur denna exempelkommentar ser ut på dokumentationshemsidan kan ses i 4.7. Figur 4.7: Del av dokumentationen som genererats ifrån JSDoc

19 KAPITEL 4. ARBETSSÄTT Mötesrutiner De möten som gruppen har är daily scrum, srint review, sprint retrospective, sprint planning och kundmöten. Gruppen hade som mål att ha ett daily scrum varje dag då gruppen planerat att jobba med projektet. Efter varje sprint hade gruppen en sprint review där gruppen diskuterade hur arbetet med projektet gått. Gruppen har även en sprint retrospective där gruppen utvärderade hur gruppen fungerat ihop. I början av varje sprint så hade gruppen en sprint planning, där uppdaterades projektets product backlog. Uppgifterna i projektets product backlog rangordnades efter hur hög prioritet de har. De uppgifter som inte hann bli klara från föregående sprint flyttades till nästa sprint. När gruppen uppdaterade sin product backlog togs uppgifter som inte längre ansågs relevanta bort [27]. 4.4 Testning Under hela utvecklingsprocessen har koden testats vid körning. För att se till att koden alltid är fungerande kom gruppen överens om att den kod som låg på master branch på GitHub alltid skulle vara en fullt funktionell version. Gruppen följde inte något bestämt testningsmönster för att prova alla funktioner på sidan. I slutet av varje sprint gick gruppen tillsammans igenom koden för att leta fel och öka gruppens förståelse för andra delar av applikationen. 4.5 Kravhantering Då kraven från kunden inte var specificerade gällande till exempel responstid eller vad för komponenter som skulle finnas med på hemsidan, så satte gruppen egna krav på projektet. Gruppen valde att sätta som krav att hemsidan ska ha en responstid under tre sekunder oberoende av användarens uppkoppling och enhet. Gruppen valde även att ha som krav att visualiseringarna för väderprognosen ska vara tydliga. 4.6 Kommunikation Slack [30] är ett populärt kommunikationsmedel som passar bra för gruppkonversationer. En stor fördel med Slack över andra kommunikationsverktyg är att det är möjligt att integrera Git, Google och liknande tjänster, vilket gör arbetet mer organiserat. En annan bra funktion med Slack är att det finns möjlighet att skapa flera chattrum vilket är användbart då endast en liten del av gruppen behöver ett kommunikationsmedel. Ett annat bra användningsområde för dessa chattrum är att det enkelt går att begränsa ett chattrum till att t.ex. endast visa Git-notiser. 4.7 Versionshantering Ett av de vanligaste hjälpmedlen för versionshantering är Git. Git är ett verktyg som är till för att förenkla versionshanteringen och är ett bra sätt att hantera ett projekt med flera utvecklare. För att flera utvecklare ska kunna arbeta med projektet samtidigt och på olika håll skapas en branch för varje story. En ny branch skapas från master branch och är en kopia av master branch då den

20 KAPITEL 4. ARBETSSÄTT 15 skapas. Ändringar som sker i en branch kommer bara ske på just denna branch. När en branch är färdig sker merge den åter med master branch och en ny version av programmet skapas [8]. När utvecklaren blir klar med en uppgift skapas en commit. En commit sparar arbetet lokalt, och när utvecklaren vill spara arbetet på Git-servern kan han eller hon göra en push till master branch. Se figur 4.8 för ett exempel på hur branches för ett projekt kan se ut. Här skapas den 29 februari fyra branches från master: Figur 4.8: Branch-exempel från Github Graph Getdata Tabell Karta Prickarna som syns på varje branch är commits. Vid varje commit lämnar utvecklaren även ett meddelande som beskriver vad som ändrats eller lagts till. På så sätt är det enkelt att gå tillbaka till en gammal commit om någonting skulle gå fel. 4.8 Användartest För att försäkra applikationens användarvänlighet utförde gruppen tester. Användartesterna utfördes genom att visa upp applikationen för diverse personer och låta dem prova de funktioner som implementerats. Därefter fick de som testat applikationen fylla i ett formulär via Google docs med utvalda frågor från utvecklarna. Med frågorna var tanken att få en bättre överblick över till exempel hur användarvänligheten kunde förbättras.

21 Kapitel 5 Resultat Den slutliga färdiga produkten består av tre stycken huvudkomponenter, se 5.1.Dessa komponenter är en karta, en graf och en tabell som ska hjälpta användaren att enkelt få en prognos utifrån dessa tre olika visualiseringar. Sidan har även en navbar-komponent med ett sökfält för att användaren lätt ska kunna söka på städer, se 5.2. Alla komponenter på sidan interagerar även med varandra. D.v.s. om en användare t.ex. klickar på temperaturen för en stad i tabellen kommer grafen att visa temperaturen, och stadens namn visas i navigeringsfältet. Den färdiga produkten applikationen går att testa på Figur 5.1: Slutgiltiga produkten 5.1 Karta Kartan är en av huvudkomponenterna på sidan och används främst för att användaren ska kunna navigera sig, samt ge en bättre överblick på hur vädret i närliggande städer blir. Kartan implementerades med Openlayers, se 3.9. Den geografiska kartan utgör grundlagret och är ett tile-lager från CartoDB [5]. Ovanpå det geografiska lagret ligger ett vektorlager som genereras utifrån datans punkter, samt deras longitud och latitud. Utifrån den filen skapas sedan ikoner som innehåller stadens namn och väderprognosen för den aktuella tidpunkten. För att kartan inte ska bli full av ikoner visas ikonerna dynamiskt beroende på zoomnivån. Om användaren är på en hög zoomnivå kommer endast ett fåtal städer visas, och när han eller hon zoomar in på kartan så kommer flera ikoner dyka upp. Om 16

22 KAPITEL 5. RESULTAT 17 användaren klickar på en ikon i kartan uppdateras positionen för de övriga komponenterna till den aktuella positionen och en popup-ruta visas i kartan som innehåller mer information om prognosen i den aktuella punkten än vad ikonen kan representera. Se 5.3. Under kartan finns även en slide-komponent, se 5.3 När användaren manuellt drar i slide-komponent eller trycker på play-knappen till vänster så uppdateras den aktuella tidpunkten och ikonerna uppdateras. Figur 5.2: Sökfält som ger förslag på städer. Figur 5.3: Karta med popup och slider. 5.2 Tabell Tabellen ska ge användaren en översikt över hur vädret kommer att förändras under de kommande timmarna och dagarna. Osäkerheten kommer visas i varje cell av tabellen i form av en min/max-osäkerhet i temperatur och nederbörd. Gruppen ansåg att detta var det mest intressanta för en användare att vilja se i en tabell och hur de parametrarna förändras över en närliggande framtid. 5.3 Graf Grafen ämnar att ge användaren en bild av det angivna vädret och ett spann av potentiella skillnader. Den graf som används på hemsidan implementerades genom Highcharts. I grafen går det i nuläget att se temperatur, vindhastighet och nederbörd. Det finns möjlighet att sortera på flera parametrar om utvecklingsgruppen så önskar att lägga till. Om grafen visar temperatur eller vindhastighet visualiseras osäkerheten genom en kurva samt ett minimum-maximum spann kring kurvan 5.4. Utifall användaren vill se nederbörd bytes istället kurvan ut mot ett stapeldiagram där det går att se angiven nederbörd samt potentiell maximal nederbörd 5.5[10].

23 KAPITEL 5. RESULTAT 18 Figur 5.4: Graf som visualiserar temperatur. Figur 5.5: Graf som visualiserar nederbörd.

24 Kapitel 6 Analys och diskussion Gruppen har använt ett flertal olika verktyg och tekniker, så som olika programspråk, APIer och typer av testning. Nedan följer en närmare analys och diskussion om projektets olika delar. 6.1 Utvecklingsmetod Som det diskuterats tidigare, se 4.1 i rapporten har projektet utvecklats enligt den agila utvecklingsmetoden Scrum. På grund av annan schemalagd tid har utvecklingsgruppen inte alltid haft möjlighet att följa alla de grunder som Scrum innehåller. Gruppen har följt de grunder som finns så gott som möjligt. Varje sprint har avslutats med en sprint review och en sprint retrospective samtidigt som gruppen granskat och diskuterat kod och diskuterat potentiella buggar och förbättringar. Scrum-metoder, så som sprints, korta dagliga möten och att dela upp projektet i många små tasks har effektiviserat arbetet gentemot om gruppen inte hade använt någon typ av agil process [27]. Gruppen valde att börja projektet med att programmera i par. Efter första sprinten, när applikationen hade fått en grund, övergick utvecklarna till att arbeta självständigt på mindre tasks. Att arbeta på så vis gjorde att gruppmedlemmarna ursprungligen fick ett bra grepp kring de delar respektive par suttit med. Bra grundkunskaper som delas med flera utvecklare i gruppen gör att det självständiga arbetet underlättas när idéer och lösningar går att diskutera. 6.2 Språk och APIer De språk och APIer som har använts diskuteras och analyseras i det här underkapitlet JavaScript och TypeScript Applikationen utvecklades främst i JavaScript. Gruppen beslutade att använda JavaScript under sprint 0. Beslutet togs då alla i gruppen sedan tidigare har en god översikt över språket och har tidigare arbetat i språket. JavaScript var enligt gruppen det mest lämpade kodspråket för projektet eftersom applikationen ska utvecklas till webben. Tidigare i rapporten kan det läsas om hur utvecklarna hanterade JavaScript[14]. Ett alternativ som togs upp under sprint 0 var att koda i TypeScript[35] istället för JavaScript. Type- Script är ett superset av JavaScript utvecklat av Microsoft efter de upplevda brister som JavaScript har när det kommer till större projekt. TypeScript kompileras till JavaScript för att visas i webblä- 19

25 KAPITEL 6. ANALYS OCH DISKUSSION 20 sare, och eftersom det är ett superset av JavaScript, kan utvecklarna även skriva JavaScript-kod i TypeScript-filerna. Fördelarna med TypeScript är att det erbjuder objektorienterad programmering av JavaScript utan externa ramverk. Även statisk typning finns i TypeScript till skillnad mot JavaScript [14] Googles API:er och Highcharts Under projektets början användes huvudsakligen Googles API:er för att visa både graf och tabell. Googles API:er är enkla att få igång men under projektets gång insåg gruppen att dessa var inflexibla. Gruppens vision av applikationen skulle inte gå att uppnå utan att gå ifrån Google och söka alternativa lösningar. Tabellen gjordes i HTML men grafen krävde ett nytt JavaScript bibliotek. Efter en grundlig efterforskning såg biblioteket Highcharts ut att passa projektet bäst. Highcharts erbjuder allt som projektet kräver och mycket mer. Biblioteket är gratis att använda så länge det inte används kommersiellt [10]. En huvudsaklig anledning till att Google Charts inte räckte till var att det inte fanns tillräckligt med dokumentation. Highcharts har väldokumenterade exempel på alla typer av grafer och inställningar som biblioteket innehåller. Eftersom gruppen enats om att representera spatial osäkerhet i grafen genom att visualisera min/max-värden för respektive parametrar visade sig Google Charts inte erbjuda tillräckligt för att åstadkomma det. Däremot kunde Highcharts representera denna osäkerhet och därför togs valet att byta [10] Bootstrap Ursprungligen planerade gruppen att ha en responsiv applikation, som fungerade lika bra oavsett användares plattform. Eftersom applikationen utvecklats med verktyget Bootstrap sköttes repsonsiviteten därigenom. Gruppen gick ifrån responsiviteten alltmer under utvecklingens gång. Avvikelsen från den ursprungliga planen kom då gruppen valde att prioritera den version som skapats för datorer. Att se till att applikationen förblev lika funktionell, oavsett plattform, tog tid som kunde lagts på annan utveckling [3] RequireJS, varför inte AngularJS? AngularJS är ett JavaScript-ramverk med en MVC-arkitektur som är vanligt förekommande när webbapplikationer skapas. Det är även en central del i MEAN-stacken[19] som beskrivs mer i AngularJS-utvecklarna släppte under projektets gång Angular 2, som till skillnad mot Angular 1 är skrivet helt och hållet i TypeScript. Hade detta skett innan projektets start hade gruppen kanske varit ännu mer intresserade av att förstudera Angular, då TypeScript var under diskussion att använda i projektet [1]. Utvecklingsgruppen hade inte någon tidigare erfarenhet av AngularJS, så istället valdes RequireJS som nämnts tidigare i 3.2. Gruppen insåg senare att det hade varit bättre att göra förstudier och implementera AngularJS. Detta hade lett till att saker som att interaktionen mellan grafen, tabellen och kartan skett automatiskt, eftersom Angular har Two-way Data Binding. Detta innebär att varje komponent använder sig av samma variabler [2]. Alltså synkroniserar komponenterna med varandra och när användaren ändrar i en komponent, ändras den i de andra. Gruppen fick istället lösa detta med funktioner som uppdaterar variablerna i komponenterna allt eftersom användaren ändrar dem.

26 KAPITEL 6. ANALYS OCH DISKUSSION Implementation av karta Anledningen till att gruppen valde att använda Openlayers för att implementera kartan var för att gruppen ville ha ett open-source och gratis API. Därmed föll Google Maps bort direkt. Eftersom OpenLayers har mer funktionalitet än Leaflet valdes OpenLayers för att implementera kartan. Open- Layers har även en omfattande dokumentering, se OpenLayers API [24]. Det finns även mycket exempelkod på OpenLayers hemsida, samt väldigt mycket information och hjälp från andra hemsidor. En nackdel med OpenLayers är dock att mycket av informationen som går att hitta är för OpenLayers 2, medans gruppen använder OpenLayers 3. Kodmässigt skiljer sig dessa två versioner mycket. Det finns t.ex. flera funktioner i OpenLayers 2 som har fallit bort, eller bytt namn, vilket gör det svårt att hitta uppdaterad information om dessa [18] MEAN-stack MEAN står för MongoDB, ExpressJS, AngularJS och NodeJS. Denna MEAN-stack har blivit en vanligt förekommande utvecklingplattform mot webben på grund av att den använder sig av Java- Script som kodspråk i alla dess fyra delar. Utvecklarna behöver alltså inte lära sig olika språk för front-end och back-end programmering. Den de facto standardplattformen vid webbprogrammering är LAMP, som står för Linux, Apache, MYSQL och PHP/Python/Perl [17]. Den stora skillnaden är att LAMP kräver att utvecklarna kan flera kodspråk och vet hur de interagerar med varandra för att effektivt kunna skapa en webbapplikation [19]. Som beskrivet i hade inte gruppen någon erfarenhet i AngularJS och så var även fallet med MEAN. Gruppen bestämde under sprint 0 att det skulle gått åt för mycket tid åt att sätta sig in i alla de ramverk som MEAN innefattar, men i efterhand hade MEAN varit en fördelaktig plattform att jobba med. I nuläget är det bara AngularJS som fattas för att kunna säga att applikationen är utvecklad som en MEAN-applikation [1][19]. 6.3 Testning Från projektets start var det planerat att gruppen skulle skicka ut användartester när varje sprint var färdig. Det första användartestet gjordes efter sprint 1 då gruppen hade en första prototyp av applikationen. Den applikation som demonstrerades innehöll inte någon typ av osäkerhetsvisualisering utan bara visulaisering av godtyckliga värden för olika väderparamterar. Testet var ämnat att testa gränssnittet gruppen valt att använda. Testet kom ut till 10 personer av olika åldrar varierande från 22 till 63. Användartesterna gav utvecklarna information om vad som kunde förbättras, vilket åtgärdades i kommande sprint. Under utvecklingen begicks endast det första användartestet. Gruppmedlemmarna är ense om att flera användartester hade varit lämpligt. Det hade varit bra med fler för att se till att applikationen skulle vara så användarvänligt och intuitiv som möjligt, samt för att ge så tydliga visualiseringar av vädret som möjligt. När det kommer till testning av kod under körning valde gruppen, som tidigare nämnts, att inte följa ett bestämt testmönster vid varje test. Gruppen upplevde att detta inte har skapat några problem. Att gruppen kunde undvika större problem grundar sig i att projektet delats upp i flera filer och att majoriteten av funktioner hos graf, karta och tabell hanterats separat. Vid ett större projekt hade bestämda testprinciper varit viktigt.

27 KAPITEL 6. ANALYS OCH DISKUSSION Kravhantering Med tydliga krav kan en tydlig arbetsprocess skapats genom att utifrån dessa krav göra tasks. Projektets krav har erhållits från kund via diskussioner över tänkt funktionalitet. Detta har gjorts utan användningen av hjälpmetoder och verktyg som UML-Metoder, vilket gruppen ansåg inte behövas för just detta arbete. Utöver dessa krav har gruppen själva satt egna krav på hemsidan, som tillexempel att ha en responstid under tre sekunder oberoende av användarens enhet och uppkoppling. Då projektets fokus med tiden började skifta mot datoranvändare minskade detta värde för att göra upplevelsen mer kontinuerlig då datoranvändare ofta har en bättre uppkoppling. Ytterligare ett eget krav från gruppen själva var att ha tydliga visualiseringar som redogör för väderprognosen. 6.5 Design Applikationen har under arbetet behållit relativt samma design. Noterbara förändringar skedde då utvecklingsgruppen valt att byta API:er till grafen och tabellen. Det första gruppen gjorde var att skissa olika designer för hemsidan. Därifrån valde gruppen att använda en modern och stilren design. Mot slutet av projektets arbete valdes att prioritera graf och tabell över karta och sidan ändrade form markant. Valet av designbyte kom främst ifrån användartestning och utomstående personers synpunkter. 6.6 Arbetet i ett vidare sammanhang Applikationen tillhandahåller en användare med data för städer i Sverige. En detaljerad prognos för en plats utanför städerna finns det inte tillgång till, istället visas närmsta stads prognos. Att filtrera information till att bara finnas i städer främjar samhällets urbanisering genom att ge användare som bor i städer bättre information angående vädret i sitt närområde.

28 Kapitel 7 Slutsatser I det här kapitlet diskuteras det hur frågeställningarna som ställdes i början av rapporten har besvarats samt redogör även för framtida utvecklingsmöjligheter. 7.1 Frågeställningar Hur ska det valda programmeringsspråket, JavaScript, hanteras på ett sådant sätt att gruppen kan arbeta på projektet tillsammans? Under kapitel 3 och sektion diskuteras RequireJS som gruppen har nyttjat för att hålla Java- Script så lättarbetat som möjligt. Med RequireJS kunde gruppen dela på arbetet [26][14]. Hur ska gruppen gå till väga för att se till att visualiseringen av osäkerhet i väderdata framgår på ett så begripligt sätt som möjligt? Gruppen experimenterade med olika typer av visualisering av osäkerhet. Dessa testades på användare i användaretester och med resultat från dessa kunde beslut tas kring vilka av visualiseringarna som upplevdes intuitiva. Vilka typer av osäkerhet kan beräknas utifrån SMHI:s data? Gruppen planerade i projektets början att beräkna både temporal och spatial osäkerhet utifrån datan från SMHI, men valde senare under projektets gång att lägga mer fokus på spatial data. Anledningen till detta var för att gruppen inte ville lägga för mycket tid och arbetskraft på själva osäkherhetsberäkningen, utan istället lägga mer fokus på visualiseringen av osäkerhetsdatan. Vilka alternativ finns för visualisering av väderprognos-data och hur kan dessa komplettera varandra? Gruppen valde att begränsa sig till tre olika typer av väderprognos-visualiseringar. En karta, en tabell och en graf. Anledningen till att gruppen valde just de tre komponenterna, är för att de kompletterar varandra bra för att visa prognoser, beroende på vad användaren är ute efter. Kartan gör det exempelvis lättare för en användare att kunna navigera sig och se prognoser på närliggande platser, men är inte lika bra på att visualisera osäkerhetsprognoser. Till det passar grafen bättre. I grafen är det lättare att visualisera ett spann på t.ex. nederbörd eller temperatur, vilket gör det lättare för användaren att snabbt 23

29 KAPITEL 7. SLUTSATSER 24 se osäkerhetsdatan. Grafen gör det även lättare att se framtida väderprognoser, då den har en tidsaxeln, medan kartan och tabellen visar bara väderdata för en tidpunkt. Tabellen är bättre på att visualisera flera typer av parametrar samtidigt vid olika tidpunkter, men ger inte en lika intuitiv överblick som grafen. Slutligen implementerades interaktion mellan de olika komponenterna. Om användaren t.ex. klickar på en stad i kartan eller i tabellen så uppdateras samtliga komponenter till att visa väderdata för den aktuella staden och tidpunkten. 7.2 Framtida utveckling Filtreringen av data har skett genom att endast hämta information på platser där det finns en stad. Vidare utveckling av applikationen bör innehålla funktionalitet för att dynamiskt hämta data på en godtycklig plats i Sverige. Detta kan ske genom att på något sätt placera ut en markör i kartan och utifrån positionen av markören hämta data och göra osäkerhetsberäkningar. Ytterligare så kan den positionen sparas och bindas till användare. På så sätt kan en användare spara några positioner och slippa proceduren att placera ut markören nästa gång. De dynamiska ikonerna har genererats endast genom att lägga bilder över varandra. Alternativ till denna metod, såsom färg-/genomskinlighetmanipulering eller animationer är ämnen för vidare utveckling. Även användning av dynamiska ikoner i kartan är intressant. Genom att gruppera data i områden över Sverige skulle en ikon kunna (i ett utzoomat läge) representera data för flera platser. Om det exempelvis regnar på något ställe i området skulle den information bidra till att ikonen som representerar flera datapunkter visar regn, om det ska blåsa visa blåst och så vidare. Att lägga till parametrar som beror på den beräknade osäkerheten (t.ex. risk för regn") är rimligt. Det kan visualiseras med exempelvis animation eller genomskinlighet. Ytterligare arbete med grafen kan skapa möjligheter för användare att navigera temporalt. Att markera ett intervall för att ge information om förändringar under intervallet är ett sätt att låta användaren skapa sin egen osäkerhet samt en möjlighet att utforska temporal osäkerhet snarare än spatial osäkerhet som har behandlats under projektet. Även simpel navigation som tillåter användaren att zooma i grafen är ännu inte implementerad och är något som vidare utveckling bör fokusera på. Applikationen är i dagsläget webbaserad med en responsiv layout. I en vidare utveckling bör målgruppen utvidgas till att innehålla personer som vill få information om vädret på sin mobil och därmed bör en mobilversion utvecklas. Mobilversionen kan vara en applikation eller en mobilanpassad hemsida. Då denna rapport skrivs är det fortfarende 1 Sprint kvar i planeringen. Under den är det planerat att utveckling av de dynamiska ikonerna ska ske samt att användarstudier ska genomföras. Detta leder till att resultatdelen 5 inte är fullständig och kommer fyllas ut ytterligare till nästa version av rapporten.