Oklart - LiU

Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete |Medieteknik

Vårterminen 2016 | LiU-ITN-TEK-G--16/017--SE

OklartApplikation för visualisering av osäkerhet iväderdata

Matthias BergDaniel BöökJohanna ElmesiööEmil JuopperiJens KaskeAdam Söderström

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-581 83 Linköping

013–28 10 00, www.liu.se

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ändarenupplevelsen av att applikationen tillhandahåller utförligare information än andra källor för väderpro-gnoser.

En skalbar systemarkitektur har använts och både server- och klientsidan av applikationen har byggtsmed moderna verktyg för webbaserad utveckling. Möjligheterna är stora för vidare utveckling ochnya 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 erfarenhetav detta samt för att få utvecklingen att komma så långt som möjligt. Programmering har skett bådei par och individuellt och versionshantering har genomsyrat rutinerna för utvecklingen. Flera verktygmed olika funktioner (dokumentation, versionshantering, bibliotektshantering) inom utvecklingsme-todik har använts och beskrivs ytterligare i rapporten.

Resultatet är ett webbaserat gränssnitt med visualiering av spatial osäkerhet. Visualisering i form aven graf med ett markerat intervall samt visualisering i form av dynamiska ikoner som med hänsyn tillflera parametrar i väderprognosen genereras genom att lägga bilder med alpha-kanal över varandra.

i

Innehåll

Typografiska konventioner och termer iv

1 Inledning 11.1 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Relaterat arbete 32.1 Framtagning av väderprognos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Osäkerhetsberäkning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Osäkerhetsvisualisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Verktyg, språk och API:er 53.1 HTML och CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 JavaScript och RequireJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3 Node och osäkerhetsberäkningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.4 ExpressJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5 Osäkerhetsvisualisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5.1 Dynamiska ikoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5.2 Intervall i grafen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.6 Bower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.7 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.8 Google visualization API och Highcharts . . . . . . . . . . . . . . . . . . . . . . . 8

3.9 Karta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Arbetssätt 104.1 Utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2.1 JSDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Mötesrutiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ii

INNEHÅLL iii

4.4 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 Kravhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.7 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.8 Användartest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Resultat 165.1 Karta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Tabell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.3 Graf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Analys och diskussion 196.1 Utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2 Språk och APIer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.1 JavaScript och TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2.2 Googles API:er och Highcharts . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2.4 RequireJS, varför inte AngularJS? . . . . . . . . . . . . . . . . . . . . . . . 20

6.2.5 Implementation av karta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2.6 MEAN-stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.3 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.4 Kravhantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.6 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7 Slutsatser 237.1 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.2 Framtida utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Litteraturförteckning 25

APPENDICES 27

A Individuellt bidrag 28

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 programminginterface).

• 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

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 desom 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 iregnet.

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älvaprognosen 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 utforskamö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 utveck-lingsgrupp skapa en webbaserad applikation. En agil utvecklingsmetodik används dels med syftet attprojektet ska få ett så bra resultat som möjligt och dels i pedagogiskt syfte för att förbereda studenternapå liknande arbete i arbetslivet.

1.2 Frågeställning

Gruppens frågeställningar fokuserar främst på den tekniska delen av utvecklingen. Anledningen till attgruppen valde följande frågeställningar var för att de valen skulle påverka utvecklingen av projektetgenom hela arbetets gång.

• Hur ska det valda programmeringsspråket, JavaScript, hanteras på ett sådant sätt att gruppenkan 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årpå 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 kompletteravarandra?

1

KAPITEL 1. INLEDNING 2

1.3 Avgränsningar

I projektet har gruppen enbart tagit fram spatiala osäkerheter. Gruppen valde att inte lägga mer fokuspå 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ördeinte 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 visualise-ringarna på hemsidan syns bäst på en datorskärm. Det är ett symptom av att projektet har haft syftetatt 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 ap-plikationen visualisera att det finns risk för regn i Norrköping. Kunden föreslår att använda andrapotentiella källor för osäkerhet så som att jämföra YR och SMHI tillsammans med beräkningar inärliggande data. På projektet arbetar sex stycken erfarna utvecklare. Gruppen arbetar enligt en agilutvecklingsmetod. Eftersom applikationen är webbaserad och responsiv fungerar den oavsett om denanvänds på en dator eller på en mobil.

Kapitel 2

Relaterat arbete

Under inledningen av arbetet utfördes en förstudie. Under förstudien studerades arbete relaterat tillprojektet, som beskrivs nedan. Under förstudien jämfördes även olika tekniska lösningar, och för-och nackdelar med olika tekniska lösningar viktades emot varandra. Förstudien genomfördes för attgruppen skulle få en bättre insikt i hur en väderprognos tas fram men även hur data visualiseras på etttydligt 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 bear-betas sedan i en superdator och till sist bestämmer meteorologerna vilken modell som är lämpligastatt 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åndeti lufthavet. De parametrar som ingår i insamlandet är till exempel lufttryck, vind, temperatur, fuk-tighet 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 be-räkningar görs sedan med hjälp av globala fysikaliska prognosmodeller. Värden för olika parametrarberäknas upp till tio dygn framåt. Meteorologer har möjlighet att gå in i databasen och ändra enstakaparametrar 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äder-prognos som exempelvis kan presenteras på internet, i TV eller i radion. Datan förfinas i ett samarbetemellan 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 atmo-sfä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. Fel-tillväxten kan beskrivas genom den icke-linjära ekvationen 2.1. Ekvationen visar hur variabeln Y viden tidpunkt n+1 beror på värdet på Y i tidpunken n och på en parameter a. Y kan till exempel varatemperaturen i en viss punkt. Ekvationen är förenklad och inte en modell av den verkliga atmosfären[31].

3

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. Ensemblepro-gnoser innebär att man har flera lika rimliga uppskattningar om hur initialtillståndet ser ut, och/ellerflera olika modell-designer som är lika rimliga vilket kommer att ge olika prognoser. Detta innebäratt ett kluster av prognoser kan tas fram som är baserade på olika men lika rimliga uppskattningar avhur initialtillståndet ser ut och/eller lika rimliga modell-designer. Sannolikheten för att den verkligaprognosen 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 reflekterardet 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 upplevdegruppen att det var svårt att hitta information och tidigare forskning i området. Den informationgruppen hittade om ämnet behandlade mest hur osäkerhetsvisualiseringen kunde visas i kartan medhjälp av färger, genomskinlighet och storlek på ikoner [29]. Dessa visualiseringar upplevde gruppendock 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]. Rapportenbehandlar 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ärgegen-skaper, genomskinlighet och animering vilket gav gruppen inspiration.

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 somhar använts och varför vi valt att använda just de språken och API:erna. Kapitlet går även in meri detalj om hur de olika tekniska verktygen, och hjälpmedlen fungerar samt hur de varit till nytta iprojektets 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 blirobjektorienterat i det avseendet att RequireJS läser in JavaScript-filer som moduler och att en mo-dul kan hanteras som ett objekt. I en modulfil finns möjligheten att skapa privata och publika ob-jekt/funktioner, något som inte är möjligt i JavaScript utan en modulläsare såsom RequireJS. I ettstorskaligt 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öj-ligheter för att göra tröskeln mellan klient och server lägre för utvecklare. Med det menas att någonsom tidigare endast jobbat på klientsidan även kan skriva kod till servern utan att behöva lära sig ettnytt språk [14].

SMHI:s API innehåller mer högupplöst data än vad som är relevant för applikationen. Datan harfiltrerats genom att endast hämta information från 135 platser i Sverige. Varje plats motsvarar 9 GET-requests [12], 1 mitt på platsen och 8 runt om som används vid osäkerhetsberäkningarna. Informatio-nen om vilka platser som data hämtas från sparas i en JSON-fil [16] med longitud- och latitudvärdensom 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

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 kunnahämta information kring den platsen. Då information har hämtats från den plats som ligger närmastden 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 prognoserför sparas och skickas tillsammans med datan för den angivna punkten till databasen. Detta resulterari ett JavaScript-objekt (sparad i vår MongoDB databas) [20] med 135 fält (1 för varje plats) som varoch 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ärdensom hämtats från den givna platsen.

Att uppdatera databasen med data behöver ske då SMHI har uppdaterat sina prognoser, detta skerminst 6 gånger per dag. Trots att det sker dagligen är det såpass sällan att uppdateringen bör skeoberoende av användare, det vill säga att serverskriptet körs självständigt och att användare får densenaste datan från databasen. Informationen i databasen kan uppdateras en gång per dag utan attdatan över det kommande dygnet blir mindre högupplöst eftersom det finns data för varje timmeunder de första 48 timmarna. Under utvecklingsperioden har datan uppdaterats genom att manuelltkö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å serversi-dan.

3.5 Osäkerhetsvisualisering

Väderprognoserna innehåller inget mått på osäkerhet men en uppskattning av dess säkerhet görs ge-nom att se på förändringar spatialt. Oberoende av hur osäkerheten beräknas är det en utmaning attvisualisera osäkerheten så en användare kan ta till sig informationen. Under projektet har gruppen ex-perimenterat med olika metoder för att göra osäkerhetetsinformation lättillgänglig. Det har resulterati två typer av visualiseringar; dynamiska ikoner och intervall i grafen.

3.5.1 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ängdpåverkar vilket moln som visas, se figur 3.2 och 3.1. Rymden som spänns upp av parametrarna ärtvå 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 mantill 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 figur3.3.

Genom att generera ikoner enligt den här metoden undviker man att bortse från en parameter på grundav en annan. Alla de parametrar som visualiseras i ikonerna behandlas lika med avsikten att ikonernaska innehålla så mycket information som möjligt. Med färdiga ikoner ställs högre krav på att antaletikoner ska vara stort nog för att täcka alla fall, genom att generera ikonerna får man med färre ikonermer flexibilitet. Det är ett koncept med möjligheter för påbyggnad, de två parametrarna kan medenkelhet utökas till fler.


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 mentar hänsyn till varje parameter för sig och kan därmed fånga upp fall som annars hade förbisetts. Attlägga till en parametrar som beror på den beräknade osäkerheten (t.ex. “risk för regn”) är möjligt ochger en direkt visualisering av osäkerhet i ikonerna.

3.5.2 Intervall i grafen

Osäkerhetsberäkningarna resulterar i tre tidsserier med väderprognoser; två med minsta/största vär-den i ett område omkring den givna punkten och en med en prognos för den givna punkten. Grafenvisualiserar detta genom att markera ett intervall mellan prognoserna för minsta och största värdensamt en linje för prognosen för den givna punkten, se figur 3.4.

3.6 Bower

För att hantera paket, ramverk och bibliotek har Bower [4] använts. Bower är en pakethanterare somförenklar installationen av korrekt version av exempelvis Bootstrap [3], Highcharts [10] och Requi-reJS [26] till projektet. Med Bower exkluderas paketen ifrån GitHub, och laddas ner separat tillutvecklarens dator. Gruppen valde att använda Bower på grund av enkelheten i att varje utvecklarehåller sig till samma version av de externa paketen [26].


3.7 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 stan-darder och genom att inkludera detta ramverk kommer applikationen se likadan ut i till exempelGoogle 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 tabellsamt en graf skulle användas. De två olika verktyg som använts till detta är Google VisualizationAPI 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ändarelätt ska kunna navigera och få en visuell väderprognos. En karta skulle inte bara göra det enklare föranvä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älp-medel 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. Ef-tersom Google är ett så stort företag med fler tjänster än bara Google Maps, som t.ex. platssök ochvägbeskrivning, är det ett av de kraftfullare alternativen då dessa funktioner är lätta att integrera iGoogle Maps. Nackdelen med Google Maps är att det varken är gratis eller open-source. Eftersomdet dock är det mest använda API:et finns det väldigt mycket information och guider om hur det kananvä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 sessom det kraftfullare alternativet, med större flexibilitet och mer särdrag än det mer simpla och lät-tanvända Leaflet. Storleksmässigt skiljer de sig mycket. OpenLayers är ca 700kb stor medans Lea-flet 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 engeografisk karta och ovanpå det kan det ligga ytterligare ett lager som markerar vägar eller radarbilderför väder. Vanligast är att grundlagret, ofta ett geografiskt lagret, är ett tile-layer och att lager somligger 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. Dessatiles 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 utmed 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 tile-lager som ritar ut den geografiska kartan, och ett vektorlager ovanpå som ritar ut ikoner i intressantapunkter.


Figur 3.5: Representation av tiles

Figur 3.6: Karta med vektorlager

Kapitel 4

Arbetssätt

Utvecklingen av applikationen har skett med metoder och verktyg avsedda för agil utveckling. Dethä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 varjesprint.

4.1 Utvecklingsmetodik

Gruppen arbetar enligt den agila utvecklingsmetoden Scrum. För att arbeta enligt Scrum delas arbetetin i ett flertal sprint. Enligt Scrum har gruppen en sprint 0 under vilken arbetet planerades och enförstudie genomfördes. Under denna sprint beslutade gruppen att varje sprint skulle vara två veckorlånga. Vissa sprints blev lite längre på grund av ledighet. Även saker som vilka verktyg, API:er samtvilka 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 whiteboard-tavla. Under sprint 1 parprogrammerade gruppen, delvis för att gruppen fann det svårt att dela inarbetet i mindre delar men även för att hjälpa varandra att komma igång med arbetet. I slutet av sprint1 hade en simpel design samt hemsidans komponenter implementerats. Hemsidans komponenter ären karta, en graf, en tabell, en slider och en sökruta. En första version släpptes av gruppen, se 4.1. Närgruppen 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

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ändar-tester 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 skapadesistället i HTML och grafen skapades med hjälp av Highcharts. En slider skapades och kopplades tillSMHI:s data för att kunna navigera framåt i tiden och därigenom visa framtida prognoser. Se 4.4 förden 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ändarenkan ä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. Itabellen visas en ikon för vädret, temperatur, nederbörd och vind. Klickar användaren på någon avdessa i tabellen så visas den valda vädertypen i grafen. En graf ritas upp då parametrarna temperatureller vindhastighet är vald, visas i figur 5.4. Om användaren väljer nederbörd i tabellen så ritas ett


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 detmöjliga maxvärdet för nederbörd ritas upp i ljusblått över den andra stapeln 5.5. Se 4.5 för en versionav 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 ochdess bestämmelser och finns tillgängliga för hela gruppen på Google Drive. Utöver detta gjordes au-tomatiserad dokumentation med hjälp av Trello[34] samt GitHub som skapar tidsstämplar för utförtarbete, Trello fungerar dessutom som projektets backlog. Se 4.6 för en bild på hur användargränssnit-tet ser ut [8].


Figur 4.6: Trellos användargränssnitt

4.2.1 JSDoc

Utvecklingsgruppen valde att kommentera alla funktioner i koden enligt JSDoc[15], ett märkspråk förJavaScript. Block-kommentarerna är tydliga med vilka parametrar som hanteras i funktionen, samtvad funktionen returnerar [14]. Ett exempel taget ur filen map.js:

/*** Constructor for the map

* @constructor Map

* @param smhidata Data from smhi

*/

JSDoc skapar efter kompilering av koden en HTML-genererad hemsida med alla komponenternasfunktioner och konstruktorer. Denna sida kan både utvecklarna, såväl som kunden, använda för att ökaförståelsen för koden och få en bättre inblick i vad komponenterna gör. Hur denna exempelkommentarser ut på dokumentationshemsidan kan ses i 4.7.

Figur 4.7: Del av dokumentationen som genererats ifrån JSDoc


4.3 Mötesrutiner

De möten som gruppen har är daily scrum, srint review, sprint retrospective, sprint planning ochkundmöten. Gruppen hade som mål att ha ett daily scrum varje dag då gruppen planerat att jobbamed projektet. Efter varje sprint hade gruppen en sprint review där gruppen diskuterade hur arbetetmed projektet gått. Gruppen har även en sprint retrospective där gruppen utvärderade hur gruppenfungerat ihop. I början av varje sprint så hade gruppen en sprint planning, där uppdaterades projektetsproduct 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 gruppenuppdaterade 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 fun-gerande kom gruppen överens om att den kod som låg på master branch på GitHub alltid skulle varaen fullt funktionell version. Gruppen följde inte något bestämt testningsmönster för att prova allafunktioner på sidan.

I slutet av varje sprint gick gruppen tillsammans igenom koden för att leta fel och öka gruppensfö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 kompo-nenter som skulle finnas med på hemsidan, så satte gruppen egna krav på projektet. Gruppen valdeatt sätta som krav att hemsidan ska ha en responstid under tre sekunder oberoende av användarensuppkoppling och enhet. Gruppen valde även att ha som krav att visualiseringarna för väderprognosenska vara tydliga.

4.6 Kommunikation

Slack [30] är ett populärt kommunikationsmedel som passar bra för gruppkonversationer. En storfördel med Slack över andra kommunikationsverktyg är att det är möjligt att integrera Git, Googleoch liknande tjänster, vilket gör arbetet mer organiserat. En annan bra funktion med Slack är att detfinns möjlighet att skapa flera chattrum vilket är användbart då endast en liten del av gruppen behöverett kommunikationsmedel. Ett annat bra användningsområde för dessa chattrum är att det enkelt gåratt 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 attfö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 branchför varje story. En ny branch skapas från master branch och är en kopia av master branch då den


skapas. Ändringar som sker i en branch kommer bara ske på just denna branch. När en branch ärfä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ärutvecklaren 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 fyrabranches 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 med-delande som beskriver vad som ändrats eller lagts till. På så sätt är det enkelt att gå tillbaka till engammal 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ördesgenom att visa upp applikationen för diverse personer och låta dem prova de funktioner som imple-menterats. Därefter fick de som testat applikationen fylla i ett formulär via Google docs med utvaldafrågor från utvecklarna. Med frågorna var tanken att få en bättre överblick över till exempel hur an-vändarvänligheten kunde förbättras.

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 dessatre olika visualiseringar. Sidan har även en navbar-komponent med ett sökfält för att användarenlä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 visatemperaturen, och stadens namn visas i navigeringsfältet. Den färdiga produkten applikationen går atttesta på http://visapp.itn.liu.se:3000/.

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 navi-gera sig, samt ge en bättre överblick på hur vädret i närliggande städer blir. Kartan implementeradesmed 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, samtderas longitud och latitud. Utifrån den filen skapas sedan ikoner som innehåller stadens namn ochväderprognosen för den aktuella tidpunkten. För att kartan inte ska bli full av ikoner visas ikonernadynamiskt 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

http://visapp.itn.liu.se:3000/

KAPITEL 5. RESULTAT 17

användaren klickar på en ikon i kartan uppdateras positionen för de övriga komponenterna till denaktuella positionen och en popup-ruta visas i kartan som innehåller mer information om prognosen iden 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-komponenteller trycker på play-knappen till vänster så uppdateras den aktuella tidpunkten och ikonerna uppda-teras.

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 tim-marna och dagarna. Osäkerheten kommer visas i varje cell av tabellen i form av en min/max-osäkerheti temperatur och nederbörd. Gruppen ansåg att detta var det mest intressanta för en användare att viljase 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 attse temperatur, vindhastighet och nederbörd. Det finns möjlighet att sortera på flera parametrar om ut-vecklingsgruppen så önskar att lägga till. Om grafen visar temperatur eller vindhastighet visualiserasosäkerheten genom en kurva samt ett minimum-maximum spann kring kurvan 5.4. Utifall användarenvill se nederbörd bytes istället kurvan ut mot ett stapeldiagram där det går att se angiven nederbördsamt potentiell maximal nederbörd 5.5[10].

KAPITEL 5. RESULTAT 18

Figur 5.4: Graf som visualiserar temperatur.

Figur 5.5: Graf som visualiserar nederbörd.

Kapitel 6

Analys och diskussion

Gruppen har använt ett flertal olika verktyg och tekniker, så som olika programspråk, APIer och typerav 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 utvecklings-metoden Scrum. På grund av annan schemalagd tid har utvecklingsgruppen inte alltid haft möjlighetatt följa alla de grunder som Scrum innehåller. Gruppen har följt de grunder som finns så gott sommöjligt. Varje sprint har avslutats med en sprint review och en sprint retrospective samtidigt som grup-pen 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 effektiviseratarbetet 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 applikationenhade 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 suttitmed. Bra grundkunskaper som delas med flera utvecklare i gruppen gör att det självständiga arbetetunderlä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.

6.2.1 JavaScript och TypeScript

Applikationen utvecklades främst i JavaScript. Gruppen beslutade att använda JavaScript undersprint 0. Beslutet togs då alla i gruppen sedan tidigare har en god översikt över språket och hartidigare arbetat i språket. JavaScript var enligt gruppen det mest lämpade kodspråket för projektet ef-tersom applikationen ska utvecklas till webben. Tidigare i rapporten kan det läsas om hur utvecklarnahanterade 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 JavaScripthar när det kommer till större projekt. TypeScript kompileras till JavaScript för att visas i webblä-

19

KAPITEL 6. ANALYS OCH DISKUSSION 20

sare, och eftersom det är ett superset av JavaScript, kan utvecklarna även skriva JavaScript-kod iTypeScript-filerna. Fördelarna med TypeScript är att det erbjuder objektorienterad programmering avJavaScript utan externa ramverk. Även statisk typning finns i TypeScript till skillnad mot JavaScript[14].

6.2.2 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 alterna-tiva lösningar. Tabellen gjordes i HTML men grafen krävde ett nytt JavaScript bibliotek. Efter engrundlig efterforskning såg biblioteket Highcharts ut att passa projektet bäst. Highcharts erbjuderallt som projektet kräver och mycket mer. Biblioteket är gratis att använda så länge det inte användskommersiellt [10].

En huvudsaklig anledning till att Google Charts inte räckte till var att det inte fanns tillräckligt meddokumentation. Highcharts har väldokumenterade exempel på alla typer av grafer och inställningarsom biblioteket innehåller. Eftersom gruppen enats om att representera spatial osäkerhet i grafengenom att visualisera min/max-värden för respektive parametrar visade sig Google Charts inte erbjudatillräckligt för att åstadkomma det. Däremot kunde Highcharts representera denna osäkerhet ochdärför togs valet att byta [10].

6.2.3 Bootstrap

Ursprungligen planerade gruppen att ha en responsiv applikation, som fungerade lika bra oavsettanvändares plattform. Eftersom applikationen utvecklats med verktyget Bootstrap sköttes repsonsi-viteten därigenom. Gruppen gick ifrån responsiviteten alltmer under utvecklingens gång. Avvikelsenfrån den ursprungliga planen kom då gruppen valde att prioritera den version som skapats för dato-rer. Att se till att applikationen förblev lika funktionell, oavsett plattform, tog tid som kunde lagts påannan utveckling [3].

6.2.4 RequireJS, varför inte AngularJS?

AngularJS är ett JavaScript-ramverk med en MVC-arkitektur som är vanligt förekommande närwebbapplikationer skapas. Det är även en central del i MEAN-stacken[19] som beskrivs mer i 6.2.6.AngularJS-utvecklarna släppte under projektets gång Angular 2, som till skillnad mot Angular 1 ärskrivet 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 iprojektet [1].

Utvecklingsgruppen hade inte någon tidigare erfarenhet av AngularJS, så istället valdes RequireJSsom nämnts tidigare i 3.2. Gruppen insåg senare att det hade varit bättre att göra förstudier och im-plementera AngularJS. Detta hade lett till att saker som att interaktionen mellan grafen, tabellen ochkartan skett automatiskt, eftersom Angular har Two-way Data Binding. Detta innebär att varje kom-ponent använder sig av samma variabler [2]. Alltså synkroniserar komponenterna med varandra ochnär användaren ändrar i en komponent, ändras den i de andra. Gruppen fick istället lösa detta medfunktioner som uppdaterar variablerna i komponenterna allt eftersom användaren ändrar dem.


6.2.5 Implementation av karta

Anledningen till att gruppen valde att använda Openlayers för att implementera kartan var för attgruppen ville ha ett open-source och gratis API. Därmed föll Google Maps bort direkt. EftersomOpenLayers 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 ex-empelkod 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 OpenLayers2, medans gruppen använder OpenLayers 3. Kodmässigt skiljer sig dessa två versioner mycket. Detfinns t.ex. flera funktioner i OpenLayers 2 som har fallit bort, eller bytt namn, vilket gör det svårt atthitta uppdaterad information om dessa [18].

6.2.6 MEAN-stack

MEAN står för MongoDB, ExpressJS, AngularJS och NodeJS. Denna MEAN-stack har blivit envanligt 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örfront-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 atteffektivt kunna skapa en webbapplikation [19].

Som beskrivet i 6.2.4 hade inte gruppen någon erfarenhet i AngularJS och så var även fallet medMEAN. Gruppen bestämde under sprint 0 att det skulle gått åt för mycket tid åt att sätta sig in ialla de ramverk som MEAN innefattar, men i efterhand hade MEAN varit en fördelaktig plattformatt jobba med. I nuläget är det bara AngularJS som fattas för att kunna säga att applikationen ärutvecklad 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 varfärdig. Det första användartestet gjordes efter sprint 1 då gruppen hade en första prototyp av applika-tionen. Den applikation som demonstrerades innehöll inte någon typ av osäkerhetsvisualisering utanbara visulaisering av godtyckliga värden för olika väderparamterar. Testet var ämnat att testa gräns-snittet gruppen valt att använda. Testet kom ut till 10 personer av olika åldrar varierande från 22 till63. Användartesterna gav utvecklarna information om vad som kunde förbättras, vilket åtgärdades ikommande sprint. Under utvecklingen begicks endast det första användartestet. Gruppmedlemmar-na är ense om att flera användartester hade varit lämpligt. Det hade varit bra med fler för att se tillatt applikationen skulle vara så användarvänligt och intuitiv som möjligt, samt för att ge så tydligavisualiseringar 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öljaett bestämt testmönster vid varje test. Gruppen upplevde att detta inte har skapat några problem. Attgruppen kunde undvika större problem grundar sig i att projektet delats upp i flera filer och att majo-riteten av funktioner hos graf, karta och tabell hanterats separat. Vid ett större projekt hade bestämdatestprinciper varit viktigt.


6.4 Kravhantering

Med tydliga krav kan en tydlig arbetsprocess skapats genom att utifrån dessa krav göra tasks. Pro-jektets krav har erhållits från kund via diskussioner över tänkt funktionalitet. Detta har gjorts utananvändningen av hjälpmetoder och verktyg som UML-Metoder, vilket gruppen ansåg inte behövasför just detta arbete. Utöver dessa krav har gruppen själva satt egna krav på hemsidan, som tillex-empel 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 upp-levelsen mer kontinuerlig då datoranvändare ofta har en bättre uppkoppling. Ytterligare ett eget kravfrå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å ut-vecklingsgruppen valt att byta API:er till grafen och tabellen. Det första gruppen gjorde var att skissaolika designer för hemsidan. Därifrån valde gruppen att använda en modern och stilren design. Motslutet av projektets arbete valdes att prioritera graf och tabell över karta och sidan ändrade form mar-kant. 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ören plats utanför städerna finns det inte tillgång till, istället visas närmsta stads prognos. Att filtrerainformation till att bara finnas i städer främjar samhällets urbanisering genom att ge användare sombor i städer bättre information angående vädret i sitt närområde.

Kapitel 7

Slutsatser

I det här kapitlet diskuteras det hur frågeställningarna som ställdes i början av rapporten har besvaratssamt 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 gruppenkan arbeta på projektet tillsammans?

Under kapitel 3 och sektion 6.2.4 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årpå ett så begripligt sätt som möjligt?

Gruppen experimenterade med olika typer av visualisering av osäkerhet. Dessa testades på användarei användaretester och med resultat från dessa kunde beslut tas kring vilka av visualiseringarna somupplevdes 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 datanfrån SMHI, men valde senare under projektets gång att lägga mer fokus på spatial data. Anledningentill detta var för att gruppen inte ville lägga för mycket tid och arbetskraft på själva osäkherhetsberäk-ningen, 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 kompletteravarandra?

Gruppen valde att begränsa sig till tre olika typer av väderprognos-visualiseringar. En karta, en tabelloch en graf. Anledningen till att gruppen valde just de tre komponenterna, är för att de kompletterarvarandra bra för att visa prognoser, beroende på vad användaren är ute efter. Kartan gör det exempelvislättare för en användare att kunna navigera sig och se prognoser på närliggande platser, men är intelika bra på att visualisera osäkerhetsprognoser. Till det passar grafen bättre. I grafen är det lättare attvisualisera ett spann på t.ex. nederbörd eller temperatur, vilket gör det lättare för användaren att snabbt

23

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 visualiseraflera typer av parametrar samtidigt vid olika tidpunkter, men ger inte en lika intuitiv överblick somgrafen. 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äderdatafö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å engodtycklig plats i Sverige. Detta kan ske genom att på något sätt placera ut en markör i kartan ochutifrån positionen av markören hämta data och göra osäkerhetsberäkningar. Ytterligare så kan denpositionen sparas och bindas till användare. På så sätt kan en användare spara några positioner ochslippa proceduren att placera ut markören nästa gång.

De dynamiska ikonerna har genererats endast genom att lägga bilder över varandra. Alternativ tilldenna metod, såsom färg-/genomskinlighetmanipulering eller animationer är ämnen för vidare ut-veckling. Även användning av dynamiska ikoner i kartan är intressant. Genom att gruppera data iområ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 somrepresenterar flera datapunkter visar regn, om det ska blåsa visa blåst och så vidare. Att lägga till pa-rametrar som beror på den beräknade osäkerheten (t.ex. risk för regn") är rimligt. Det kan visualiserasmed exempelvis animation eller genomskinlighet.

Ytterligare arbete med grafen kan skapa möjligheter för användare att navigera temporalt. Att markeraett intervall för att ge information om förändringar under intervallet är ett sätt att låta användaren skapasin egen osäkerhet samt en möjlighet att utforska temporal osäkerhet snarare än spatial osäkerhet somhar 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ålgrup-pen utvidgas till att innehålla personer som vill få information om vädret på sin mobil och därmed bören 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 attutveckling av de dynamiska ikonerna ska ske samt att användarstudier ska genomföras. Detta leder tillatt resultatdelen 5 inte är fullständig och kommer fyllas ut ytterligare till nästa version av rapporten.

Litteraturförteckning

[1] Angular, hämtad: 2016-05-09https://angularjs.org

[2] Angular Two-way databinding, hämtad 2016-05-09https://docs.angularjs.org/guide/databinding

[3] Bootstrap, hämtad: 2016-04-18http://getbootstrap.com/

[4] Bower, hämtad: 2016-05-03http://bower.io

[5] CartoDB, hämtad: 2016-05-03https://cartodb.com/

[6] CSS, W3C, hämtad: 2016-05-03https://developer.mozilla.org/en-US/docs/Web/Guide/CSS

[7] ExpressJS, hämtad 2016-05-11http://expressjs.com/

[8] Github, hämtad: 2016-04-18https://github.com/

[9] Google Maps, Google, hämtad 2016-05-09https://www.google.se/maps

[10] Highcharts, hämtad: 2016-05-03http://www.highcharts.com/

[11] HTML, W3C, hämtad: 2016-05-03https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5

[12] HTTP Methods GET vs. POST, hämtad: 2016-05-03http://www.w3schools.com/tags/ref_httpmethods.asp

[13] Google Visualization API, Google, hämtad: 2016-05-11https://developers.google.com/chart/interactive/docs/reference

[14] JavaScript, hämtad: 2016-04-18https://www.javascript.com/

[15] JSDoc, hämtad: 2016-05-09http://usejsdoc.org

25

LITTERATURFÖRTECKNING 26

[16] JSON, hämtad: 2016-05-03http://www.json.org/

[17] Lamp-stack, hämtad: 2016-05-09https://www.turnkeylinux.org/lampstack

[18] Leafletjs, hämtad 2016-05-09http://leafletjs.com/

[19] MEAN-stack, hämtad: 2016-05-09http://mean.io/

[20] MongoDB, hämtad: 2016-05-03https://www.mongodb.org/

[21] Model-View-Controller, hämtad: 2016-05-09http://www.tutorialspoint.com/struts_2/basic_mvc_architecture.htm

[22] Node, hämtad: 2016-05-03https://nodejs.org/en/

[23] Oklart, hämtad: 2016-05-10http://visapp.itn.liu.se:3000/

[24] OpenLayers, hämtad: 2016-04-18http://OpenLayers.org/

[25] Representation av Tiles, hämtad: 2016-06-01https://msdn.microsoft.com/en-us/library/bb259689.aspx

[26] RequireJS, hämtad: 2016-04-18http://requirejs.org

[27] Schwaber, Ken and Sutherland,Jeff, Scrum Inc.The Scrum Guide,Juli 2013, hämtad: 2015-02-03http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf

[28] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, Interna-tional Edition, Pearson 2010

[29] Sanyal, Jibonananda, Mississippi State University, 2010 Uncertainty Visualization of WeatherEnsembles, hämtad 2016-05-11http://goo.gl/g2q7l7

[30] Slack, hämtad: 2016-04-18https://slack.com

[31] SHMI Ensembleprognoser, hämtad: 2016-05-09http://www.smhi.se/kunskapsbanken/meteorologi/ensembleprognoser-1.1029

[32] SHMI Open Data API, hämtad: 2016-04-18http://www.smhi.se/klimatdata/oppna-data/meteorologiska-data

[33] SMHI väderprognoser, hämtad: 2016-05-09http://www.smhi.se/kunskapsbanken/meteorologi/sa-gor-smhi-en-vaderprognos-1.4662

[34] Trello, hämtad: 2016-04-18http://trello.com/

LITTERATURFÖRTECKNING 27

[35] TypeScript, hämtad: 2016-05-09https://www.typescriptlang.org

[36] Ynnerman, Anders, Linköpings Universitet, En osäkerhetsmedveten visualiseringspipeline fördirekt volymsrendering, hämtad 2016-06-09http://swecris.se/converis/publicweb/Project/84021?share=false&cntpers=false&reqstfulltxt=false&reports=false&lang=1

Bilaga A

Individuellt bidrag

Matthias Berg

Matthias har arbetat med grafen, sliders och framtagning av närliggande städer. Matthias fokus harskiftat mycket under projektet och han har arbetat på många olika delar.

Daniel Böök

Daniel arbetade i början med designen av applikationen, för att sedan gå över till att jobba medtabellen. Daniel genomförde också refaktorering av kod och implementerade koddokumentation JS-Doc. Han har agerat kodansvarig under projektets gång och sett till att konventioner och struktur harföljts.

Johanna Elmesiöö

Johanna arbetade till en början med kartan, men övergick sedan till att skapa en fil där det bestämdesifrån vilka platser data skulle hämtas, en fil där de största städerna i Sverige och deras koordinater.Johanna har även arbetat med sökfältet.

Emil Juopperi

Emil har haft rollen som Scrum Master vilket har inneburit att hålla i möten samt hjälpa till så att allakänner att de har en tydlig uppgift. Under utvecklingen har Emil skrivit koden på serversidan (osäker-hetsberäkningar och databashantering). På klientsidan har han jobbat med gränssnittet, speciellt hurkomponenterna interagerar med varandra.

Jens Kaske

Jens har huvudsakligen varit ansvarig för grafen och två av de tre sliders som funnits på hemsidanunder arbetets gång. Arbetet inkluderar den ursprungliga, Google Charts, grafen och den slutgiltigasom är gjord med Highcharts och interaktionen mellan graf och sliders.

28

BILAGA A. INDIVIDUELLT BIDRAG 29

Adam Söderström

Adam har främst arbetat med implementering av kartan och alla dess komponenter såsom vektor-lagret, responsiv zoomnivå m.m. Adam har även jobbat med slidern, främst interaktion mellan slideroch graf, samt göra en ’play’-funktion till den slidern.

Documents

Oklart - LiU