INOM
EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2017,
Användning av geografisk data vid mjukvaruutveckling
CASPER GENFORS
KTH
SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK
Abstract
Gemit Solutions is a company that develops web based solutions for
geographical analysis on pollution. One of the solutions is called EnvoMap, which is a map based tool for analyzing pollution on the water and sewage system.
The assignment that this project will be working on is to implement a new functionality to EnvoMap. The idea is that it should be possible for the user to choose an area on the map and get the underlaying data for that area. To solve this an iterative method for development will be used. The result will be a prototype that meets the desired functionality.
This assignment also provides the opportunity to study an interesting topic about the usage of geographical data in software development. Methods that will be used for the study is literature study, implementation, documentation and analysis. The given result includes theories, experiences and
recommendations from working on the project and will try to answer the thesis question about usage of geographical data in software development.
Keywords
Geographical data, web maps, integrals, shapefiles
Abstract
Gemit Solutions är ett företag som utvecklar webbaserade lösningar för bland annat geografisk analys av föroreningsbelastning. En av lösningarna heter EnvoMap och är ett kartbaserat system för analys av föroreningsbelastning på VA-nätet (vatten och avlopp).
Uppgiften det här projekt skall lösa är att Gemit vill ha en ny funktionalitet på EnvoMap. Tanken är att det skall gå att välja ett område på kartan och få ut underliggande data för det området. För att lösa detta kommer en iterativ utvecklings metod att användas. Resultatet av detta är tänkt att ge en prototyp/lösningsförslag som möter de funktionella kraven.
Den här uppgiften medför också möjligheten till en intressant frågeställning om användning av geografisk data vid mjukvaruutveckling, som rapporten kommer undersöka. Metoder som litteraturstudie, implementation,
dokumentation och analys kommer användas för undersökningen. Resultat som ges av undersökningen innefattar teorier, erfarenheter och
rekommendationer från arbetet och kommer att försöka besvara
frågeställningen om användning av geografisk data vid mjukvaruutveckling.
Nyckelord
Geografisk data, webbkartor, integraler, shapefiler
1
Innehållsförteckning
1 Introduktion ... 1
1.1 Bakgrund ... 1
1.2 Problemformulering ... 1
1.3 Syfte ... 2
1.4 Mål ... 2
1.5 Metoder ... 2
1.6 Avgränsningar ... 3
1.7 Disposition ... 3
2 Bakgrund ... 5
2.1 Vad är geografisk data? ... 5
2.2 Vilka standarder finns för geografiskdata? ... 5
2.3 Lagring av geografisk data ... 6
2.4 Programstrukturer och existerande lösningar för användning av geografisk data ... 6
2.5 Beräkning av areor på kartan ... 7
2.6 Litteraturöversikt och relaterat arbete ... 9
3 Metod ... 11
3.1 Undersökningsmetod ... 11
3.2 Vetenskaplig grund i den valda metoden ... 12
3.3 Projektmetod/Arbetsplan ... 13
3.4 Tekniska metoder ... 14
3.5 Metod för systemdokumentation ... 14
4 Resultat ... 17
4.1 Företagets existerande lösningar ... 17
4.2 Lösning på företagets problem ... 18
4.3 Egna erfarenheter från implementation ... 21
5 Analys och Diskussion ... 23
5.1 Metoddiskussion ... 23
5.2 Resultatdiskussion ... 24
5.3 Etik och hållbarhet ... 24
5.4 Slutsats ... 25
5.5 Fortsatt arbete ... 26
Referenser ... 27
Appendix A Arkitektur ... 1
Bilaga 1 Funktionalitet ... 1
Funktionella krav ... 1
USE-CASE ... 4
MoSCoW prioritering ... 6
Bilaga 2 Design ... 7
Applikationens struktur ... 7
Klass- och paketindelning ... 8
Bilaga 3 Datahantering ... 9
Shapefiler ... 9
2 SQL databas ... 10
1
1 Introduktion
Det här kapitlet ger en introduktion till detta examensarbete. Kapitlet
innehåller en bakgrund till projektet, problemformulering, syfte och mål med projektet, samt avgränsningar och en inblick i hur rapporten är disponerad.
1.1 Bakgrund
Det här projektet utförs som ett examensarbete för högskoleingenjör i datateknik på KTH. Examensarbete utförs på ett företag som heter Gemit Solutions AB.
Gemit är ett företag som utvecklar webbaserade lösningar för bland annat analys av föroreringsbelastning på vatten nät. Gemit’s applikationer används framförallt av kommuner och miljöingenjörer. Det här projektet kommer jobba med att implementera en ny funktionalitet till en av Gemit’s
applikationer, som heter EnvoMap.
EnvoMap är ett webbaserat stöd för analys och kartläggning av
föroreningsbelastning på vatten nät. Webbapplikationen använder sig av en dynamisk karta, där användare kan lägga ut olika lager med geografisk data.
Analys av föroreningsbelastning i ett geografiskt område är ett exempel på funktionalitet. Några exempel på information som kan hämtas och analyseras i applikationen är: olika företags miljöpåverkan i ett område och
föroreningsbelastning på VA-nätet (vatten och avlopp). EnvoMap ger alltså kommunerna ett smidigt sätt att kartlägga sin miljö och
föroreningsbelastning.
1.2 Problemformulering
Hur kan man programmatiskt hämta information från ett geografiskt
område på en dynamisk webbkarta? Problemet som det här projektet skall ta fram en prototyp/lösningförslag till är att företaget vill implementera en ny funktionalitet till EnvoMap.
Den nya funktionalitet som företaget vill ha är att man ska kunna lägga ut ett rutnät med geografisk position på webbkartan, där rutnätet kan innehålla data om t.ex. föroreningsbelastning på området. Tanken är sedan att en användare av applikationen skall kunna välja ett område, genom att rita in det som en polygon på webbkartan, och få ut data om föroreningsbelastningen från den specifika delen av rutnätet.
Projektet ska alltså genom undersökning och implementering ta fram ett lösningsförslag i form av en prototyp som möter dessa krav. Företagets problem ger då möjligheten till en intressant frågeställning som rapporten skall försöka besvara: hur kan geografiskdata användas vid
mjukvaruutveckling på ett standardiserat och hållbart sätt. Med
standardiserat menas vilka standarder som finns och hur de kan användas i
2 programmering. Hållbart innebär, hur mjukvaruutveckling med geografisk data, kan bidra till hållbarutveckling.
1.3 Syfte
Det första syftet med projektet är att förbättra en av Gemits befintliga
applikationer, genom att försöka implementera ett lösningförslag, i form av en prototyp som uppfyller kraven på den nya funktionaliteten.
Det andra syfte med projektet är att svara på frågeställningen, om hur
geografiskdata kan användas vid mjukvaruutveckling, vilket är tänkt att öka kunskaper om implementering av geografisk data vid programmering.
1.4 Mål
Projektets olika mål kan delas upp i tre delar [1]. Det första är effektmålen som beskriver varför projektet skall utföras. Det andra är resultatmålen som beskriver vad resultatet av projektet skall bli. Det sista är projektmålen som beskriver projektgruppens egna mål med projektet.
Det här projektets effektmål är att förbättra Gemits befintliga system, genom att implementera ny funktionalitet för hantering av geografisk data.
Resultatmålet med det här projektet är att ta fram ett lösningförslag och prototyp som möter funktionaliteten och kraven som ställs i
problemformuleringen.
Projektmålen för det här projektet är att skriva en rapport med värde för andra ingenjörer, att uppfylla akademins krav för ett examensarbete och att rapporten ska besvara frågeställningen om, hur geografisk data kan
användas vid mjukvaruutveckling på ett standardiserat och hållbart sätt.
1.5 Metoder
Vid val av metoder för projektet fanns ett flertal med i åtanke. Exempel på metoder som skulle kunna användas under utförandet av ett projekt som detta är fallstudie, kvantitativ/kvalitativ studie, deduktiv/induktiv studie och
litteraturstudie.
För frågeställningen som ställs i det här projektet kommer en fallstudie utföras som metod för undersökning. En kvalitativ metod kommer sedan att användas för analys av användarbarhet.
För utveckling och implementering av lösningsförslaget kommer förstudie att användas som metod för att läsa på om olika lösnings alternativ, samt test på utvalda alternativ. Programmeringsspråk som kommer att användas vid implementation är C#/.Net, JavaScript och Html, samt utvald
metod/funktion för att hantera data.
3 1.6 Avgränsningar
Projektet är begränsat till programmeringsspråken C#, HTML och JavaScript, då den existerande applikation, EnvoMap, som projektet skall implementera ny funktionalitet till, är skrivet i dessa språk. Eftersom att C# måste användas, så begränsas också val av programmeringsmiljö till Microsoft Visual Studio.
Vidare så sattes en begränsning att inte arbeta direkt med EnvoMap, då det är ett rätt stort system, så risken för att fastna på grejer som inte har med
uppgiften att göra skulle kunna bli stor. Med tanken på projektets
tidsbegränsning, valdes istället att skriva ett eget testprogram i mindre skala, att implementera den önskade funktionaliteten på. Detta medförde att fokus kunde läggas mer på implementering av den nya funktionaliteten, istället för att spendera för mycket tid på att försöka hitta i och förstå sig på koden i EnvoMap.
Området som användaren ska få ringa in på webbkartan i applikationen, enligt problemformuleringen, begränsas till endast räta linjer. Detta ger enklare beräkningar över områdets föroreningsbelastning, då projektet nu bara behöver ta hänsyn till funktioner enligt räta linjens ekvation, y = k x + m.
1.7 Disposition
För att börja så ger kapitel 1 en inledning till projektet med bland annat bakgrundsbeskrivning, syfte, mål och avgränsningar. Kapitlet ger också en inblick i hur rapport är upplagd och disponerad.
Vidare så redogör och förklarar kapitel 2 olika bakgrundsfakta och teorier som är bra att känna till för projektet.
Kapitel 3 redogör för det olika metoder som använts under projektets gång.
Kapitlet tar upp de undersökningsmetoder, projektmetoder, tekniska metoder och metoder för systemdokumentation som använts.
För att fortsätta så redovisar kapitel 4 projektets olika resultat. Resultat som företagets existerande lösningar, lösning på företagets problem, samt egna erfarenheter tas upp.
Slutligen går kapitel 5 igenom och diskuterar de metoder som används under projektets gång, de resultat som projektet har givit, samt get en slutsats och en introduktion till fortsatta arbeten.
4
5
2 Bakgrund
Det här kapitlet redogör för de viktiga och bakomliggande fakta och teorier som har använts i projektet. Exempel på fakta som kapitlet tar upp är vad geo och geospatial data är.
2.1 Vad är geografisk data?
Geografisk data eller geo data som det också kallas, är information om sådant som har ett geografiskt läge [2]. Alltså geo data beskriver allt som går att läges bestämma, som t.ex. vägnät, sjöar, fastigheter, osv.
När man arbetar med geografisk data, hanterar man dem ofta som lager som kan staplas på varandra. Exempelvis kanske du lägger ut en karta som
bakgrundslager, för att sedan lägga på ett geo lager om vägnät och fastigheter för att visualisera deras geografiska positioner på kartan.
Ett exempel på hur geografisk data används i applikationer och
webbapplikationer, kan vara att du t.ex. vill hitta närmaste butik som har en viss produkt i lager. Då kan du få upp en karta, som t.ex. Google Maps, med de butiker som har produkten i lager markerade med sina geografiska positioner, så att du kan lokalisera din närmaste butik.
2.2 Vilka standarder finns för geografiskdata?
Vilken typ av data som är geografisk kan vara flera typer, som beskrivs i avsnitt 2.1. Dock finns standarder för hur geografiskdata ska positioneras. För att bestämma position på geografisk data kan standarder som SWEREF 99 och WGS 84 användas.
I Sverige är SWEREF 99 standard [3] och används som det officiella
referenssystemet för att bestämma geografisk position på objekt. Det innebär att hela landet kan delas in i en kartprojektion, SWEREF 99 TM, där kartan ses som ett tvådimensionellt koordinatsystem. Vid användning anges
koordinaterna i östlig koordinat (East) och nordlig koordinat (North). Den nordliga koordinaten är sjusiffrig [4] och den östliga koordinaten består oftast av sex siffror. Koordinaterna uttrycks i meter.
Vidare är WGS 84 (World Geodetic System) en global standard som fungerar i hela världen. Det är den standard som vanligen används i GPS-mottagare.
Koordinater enligt WGS anges vanligen som Latitud och Longitud. För att enkelt beskriva hur latitud och longitud fungerar, så delas jorden in i vertikala och horisontella linjer. Där latitud är de horisontella linjerna (kan ses som y- koordinaten) och longitud de vertikala linjerna (kan ses som x-koordinaten).
Skillnaden mellan SWEREF 99 och WGS 84 handlar om decimeter vilket inte är så stort, så för de flesta praktiska användningarna spelar det ingen större roll vilken av dem som koordinaterna anges i.
6 2.3 Lagring av geografisk data
Det här avsnittet kommer ta upp och redogöra för några olika datatyper som kan användas för att spara geografisk data. Några exempel på datatyper som tas upp är raster och shapefiler.
Geografisk data kan sparas och hanteras på flera sätt [5], t.ex. som filer eller i en databas. Exempel på sätt som man kan spara geografisk data på är i
filtypen ”shapefile”, som ”raster” bilder, vilket är en typ av rutnät, där varje ruta innehåller information om t.ex. befolkningstäthet, i en geodatabas eller till och med som Microsoft Excel dokument.
En shapefil [6] är ett enkelt format för att spara geometrisk position och attribut information för geografiska objekt. En shapefil är ett format som består av tre eller fler filer, med specifika filändelser. Dessa filer skall placeras i samma mapp (workspace). Det finns tre filtyper som måste finnas med för att en shapefil skall kunna fungera, en huvudfil av typen .shp, en indexfil av typen .shx och en databasfil av typen .dbf.
För att enkelt förklara raster data [7], så är det bilder i matrix form, uppdelat i rader och kolumner. Exempel på raster kan vara digitala bilder, foton från satelliter och inskannade kartor.
Geografisk data kan också sparas och hanteras med en databas. Exempelvis använder sig det här projektet av en Microsoft SQL Server databas, där objekt med geografisk position som t.ex. företag, hanteras i en vanlig
relationsdatabas. Detta är möjligt då Microsoft SQL Server [8] kan hantera geografiska objekt. SQL Server har support för två typer av geografisk data, geometry och geography. Datatypen geometry används för vanliga 2- dimesionella koordinatsystem, medan geography används för longitud, latitud system baserade på Jorden, kallat Round-Earth.
Vidare går det självklart också att använda geografisk data i en SQL databas utan några speciella datatyper. Du kan t.ex. skapa en tabell i databasen, där du låter varje rad representera ett objekt med en geografisk position. Objekten skulle t.ex. kunna vara företag eller fastigheter som du vill visualisera på en karta. För att åstadkomma detta kan objekten exempelvis förses med attribut för longitud och latitud, vilket medför att klienten kan hämta koordinaterna och placera ut objektet på rätt plats på kartan.
2.4 Programstrukturer och existerande lösningar för användning av geografisk data
Till att börja med arbetar det här projektet med geografisk data specifikt för webbapplikationer. Därför kommer det här avsnittet framförallt ta upp programstrukturer och existerande lösningar för användning av
geografiskdata vid just webbutveckling.
För att kunna hantera dynamiska kartor och geografisk data i en
webbapplikation finns ett bra JavaScripts bibliotek som heter OpenLayers [9].
7 Detta ger en bra programstruktur, med smidiga funktioner för att skapa och hantera en dynamisk karta i en webbapplikation, samt för att lägga till lager och vektorer med geografisk data på kartan. Openlayers kan också användas för att sätta upp interaktioner som låter användaren rita på kartan.
För att hantera konverteringar mellan olika standarder och projektioner för koordinathantering, som SWEREF 99 och WGS 84, finns ett bra JavaScript bibliotek som heter Proj4js [10]. Vad Proj4js gör är att den kan transformera koordinater från ett system till ett annat.
Vidare för att hantera shape-filer och kunna hämta deras innehållande data, finns en bra opensource servertjänst som heter GeoServer [11]. GeoServer körs smidigast på en Tomcat server och funkar genom att den ger dig ett webbgränssnitt där du kan skapa geografiska lager från din shapefil, så att du kan lägga ut dem som lager i din webbapplikation.
För att få en bra struktur på programmet och koden, som är lätt att ändra och uppdatera, kan MVC användas. MVC (Model-View-Controller) är ett paket- och klassindelning för att separera vyn (användargränssnittet) och logiken i ett datasystem. Vid användning får ingen kommunikation ske direkt mellan vyn och modellen, all denna kommunikation skall gå via Controllern.
2.5 Beräkning av areor på kartan
Det här avsnittet redogör för matematiska formler som kan användas för att beräkna areor av polygoner i ett rutnät och under rätta linjer.
En polygon [12] kan definieras som ett geometriskt objekt, bestående av ett visst antal punkter (eng. vertices) och lika många räta linjer (eng. sides). Se figur 1 nedanför.
Figur 1: Exempel på polygoner, geometriska objekt med lika många hörn som kanter.
För att beräkna arean av en polygon kan Pick’s theorem [13] användas. Det definierar en formel som kan användas om polygonen visualiseras i ett
koordinatsystem (rutnät). Formeln säger att om A är arean av polygon, och B är antal punkter i koordinatsystemet (eng. lattice points) på polygonens
kanter och I är antal punkter i koordinatsystem som ligger inuti polygonen. Så är arean 𝐴 = 𝐼 + 12𝐵 − 1. Figur 2 på nästa sida förtydligar detta.
8
Figur 2: Bilden visar hur arean av en polygon kan beräknas med Pick’s theorem.
Figur 2 ovan visar en polygon inritad i ett koordinatsystem. Punkterna i koordinatsystemet som ligger på polygonens kanter är markerade i grönt, och de punkter i koordinatsystem som ligger inuti polygonen är markerade i rött.
Räknas dessa koordinat punkter, fås att polygonen har: 7 koordinatpunkter innanför sig och 8 koordinat punkter på kanterna. Alltså I = 7 och B = 8, sätts detta in i formeln från föregående sidan, fås att arean A för polygonen blir:
𝐴 = 7 + 1
2∗ 8 − 1 = 10 area enheter.
En annan variant är att beräkna arean under en rät linje, för det kan beräkning av integralen [14] användas. T.ex. om du vill ha arean för ett område begränsat av en kvadrat och en rät linje som skär den, kan kvadraten ses som ett koordinatsystem, och arean beräknas med integralen, som arean under linjen. Skulle du å andra sidan villa ha arean ovanför linjen i kvadraten, kan det ges av arean för kvadraten minus integralen (arean under linjen). Se figur 3 nedanför.
Figur 3: Bilden visar en kvadrat i blått, med en rät linje i rött som skär den.
9 Figur 3 visar en kvadrat i blått, från rutnätet på kartan. En rät linje i rött, från en inritad polygon, delar upp kvadraten i två areor. Den ena area hamnar utanför den inritade polygonen och den andra innanför. Den senare arean är den som är markerad i grönt.
För att beräkna arean av den gröna polygonen, kan kvadraten ses som ett koordinatsystem. Kvadratens nedre vänstra hörn ses då som origo, alltså koordinaten (0,0). Längden på kvadratens sidor är 250 meter, vilket ger att integralen för den räta linjen kan beräknas i intervallet 0 till 250. Det två punkter där den rätalinjen skär kvadratens kanter, ses som y värdena för den rätalinjen, alltså där x = 0 och där x = 250. Om den räta linjen har funktionen f(x), blir formen för polygonens area: ∫0250𝑓(𝑥) 𝑑𝑥.
2.6 Litteraturöversikt och relaterat arbete
Till att börja med fanns mycket information att hitta om geografisk data och standarder. Bland annat från t.ex. Lantmäteriet [3] och Länsstyrelsen
Stockholm [2]. Det fanns också relativ gott om existerande lösningar för programmering med geografisk data, som Openlayers [9] och GeoServer [11].
Formler för areaberäkningar fanns det också mycket att hitta, då matematik är ett stort område, och många källor. Exempel på en bra källa kan vara WolframMathWorld [12].
Vad det gäller liknande lösningar till det som tas fram i projektet, så finns inte så mycket, då det är en ny funktionalitet som tas fram. Dock gick det att dra nytta av andra programmeringslösningar, som använder sig av geografisk data, för att lösa problemet.
10
11
3 Metod
I det här kapitlet redogörs för vilka metoder som använts under projektet.
Kapitlet tar upp projektets undersökningsmetoder, projektmetoder och tekniska metoder och metoder för systemdokumentation.
3.1 Undersökningsmetod
Det här avsnittet går igenom de metoder som används i projektet för att på ett vetenskapligt [15] sätt undersöka och besvara frågeställningen, hur kan
geografisk data användas vid mjukvaruutveckling på ett standardiserat och hållbart sätt?
Eftersom att frågeställningen är så pass stor och generell, så kommer den brytas ner i delfrågor. Det leder till att frågeställningen kan undersökas och analyseras stegvis, med specifikt utvalda metoder för varje delfråga. Detta ger en bra struktur för att utföra en vetenskaplig undersökning och besvara frågeställningen.
Delfrågor som dyker upp är:
• Vad är geografisk data och vilka standarder finns?
• Hur ska datastrukturer och programstrukturer se ut för geografisk data?
• Vad finns det för existerande lösningar för att hantera geografisk data programmatiskt?
• Hur ser företagets existerande lösningar för hantering av geografisk data ut?
• Hur ser lösningsförslaget till företagets problem ut?
• Vilka egna erfarenheter från implementering av ny funktionalitet till företagets existerande lösning är aktuellt att redovisa i rapporten?
För att kunna ge ett bra svar på första frågan, vad är geografisk data och vilka standarder finns? Så kommer en litteraturstudie användas som metod, detta för att läsa på om och hämta referenser. De resultat som ges från denna litteraturstudie, tillsammans med förklaringar och referenser, redovisas i kapitlet Bakgrund.
Fortsättningsvis för att svara på fråga två, hur ska datastrukturer och programstrukturer se ut för geografisk data, kommer litteraturstudie användas som metod. Litteraturstudien kommer användas för att hämta referenser och läsa på om vilka datastrukturer som kan användas och hur programstrukturen kan se ut för användning av geografisk data i
programmering. De resultat som hämtas från denna studie, tillsammans med referenser och förklaring, redovisas också i kapitlet Bakgrund.
Vidare för att svara på den tredje frågan, vad finns det för existerande lösningar för att hantera geografiskdata programmatiskt, kommer
litteraturstudie att användas som metod för att läsa på om b.la. vilka server
12 lösningar som skulle kunna användas vid implementering av geografisk data i programmering. Resultatet av detta redovisas i kapitlet Bakgrund.
För att svara på fråga fyra, hur ser företagets existerande lösningar för hantering av geografisk data ut, kommer analys och implementation att användas som metod. Analys för att gå igenom och analysera det befintliga systemet. Samt implementation för att det ger en stor inblick i hur systemet fungerar och är uppbyggt. Resultatet av detta kommer redovisas i kapitlet Resultat.
Fortsättningsvis för att svara på den femte frågan, hur ser lösningsförslaget till företagets problem ut, kommer implementation att användas som metod.
Implementeringen av lösningsförslaget kommer utföras iterativt, vilket beskrivs mer detaljerat i avsnitt 3.2 projektmetod, och redovisas i kapitlet Resultat samt i bilagor.
Vidare för att svara på den sista delfrågan, vilka egna erfarenheter från implementering av ny funktionalitet till företagets existerande lösning är aktuellt att redovisa i rapporten, kommer dokumentering och analys att användas. Dokumentering för att samla alla erfarenheter och lärdomar från implementering av lösning, samt analys för att gå igenom och plocka ut de erfarenheter som känns aktuella att ta med i rapporten. Resultaten av detta kommer redovisas i kapitlet Resultat.
Avslutningsvis för att svara på den övergripande frågeställningen, hur kan geografisk data användas och vid mjukvaruutveckling på ett standardiserat och hållbart sätt, kommer diskussion och analys att användas som metod.
Detta för att gå igenom, analysera och diskutera den undersökning och det arbete som utförts under projektet. Resultatet av detta kommer att redovisas i kapitlet Analys och Diskussion.
3.2 Vetenskaplig grund i den valda metoden
Det här avsnittet går igenom och resonera för hur undersökningsmetoden för projektet är upplagd på ett vetenskapligt sätt.
En vetenskaplig arbetsmetod, enligt Ekholm [15], börjar med att problemet identifieras och att befintlig kunskap inom området identifieras och kartläggs.
I det tre första delfrågorna på undersökningsmetoden för det här projektet, utförs en litteraturstudie för att bland annat sätta sig in i vad geografisk data är, hur data- och programstrukturer skall se ut och vilka existerande lösningar som finns. Detta medför att förståelse för problemet fås, vilket är lite det identifieringen och kartläggningen går ut på.
Vidare menar Ekholm, att problemet skall förklaras och lösas med utgång i den bakgrundsfakta som hämtats. Nästa del av det här projektets
undersökningsmetoden, går ut på just det att analysera företagets (Gemit’s) existerande lösningar och den bakgrundsfakta som tagits fram. För att sedan utveckla en lösning på problemet.
13 Till sist menar Ekholm, att lösningsförslaget skall läggas fram och nya förslag och teorier ska föreslås. Den sista delen av undersökningsmetoden går ut på det, att dokumentera och analysera erfarenheter från att ha arbetat med projektet och att ge rekommendationer utifrån det.
Sammanfattningsvis går undersökningsmetoden för projekt ut på att identifiera problemet och befintlig kunskap. Att undersöka existerande lösningar och lösa problemet med utgång i bakgrundsfakta. Att redovisa problemet i from av lösningsförslaget, men också i from av erfarenheter och rekommendationer från projektet. Resultatet av detta är en
undersökningsmetod som baseras på vetenskapliga teorier.
3.3 Projektmetod/Arbetsplan
Det här avsnittet går igenom hur arbetet under projektets gång har varit uppdelat och strukturerat. Vilka arbetsmetoder som använts och hur
arbetsplanen har sätt ut, för att se till att projektet ger rätt resultat, på rätt tid och inom budget.
Till att börja med har arbetet under projektets gång delats upp i iterationer för att på ett smidigt sätt hålla koll på vad som ska göras och enklare kunna
hantera en eventuell förändring. Den iterativa metoden har fungerat på så sätt att de funktionella kraven ordnades i prioritet enligt MoSCoW-modellen, som beskrivs nedanför. Därefter har kraven implementerats iterativt ett i taget, med målet att kravet skulle vara i princip klart efter iterationen, och behövdes ett krav förbättras utfördes en till iteration på det kravet. Längden på
iterationerna har legat på ungefär en vecka. Exempel på iterationer från projektet är bland annat att få igång en fungerande test-/utvecklingsmiljö, kunna få ut en dynamisk karta i en webbapplikation, kunna visualisera ett rutnät med geografisk data på kartan och kunna rita på kartan.
Vidare för att se till att uppnå en bra leverans när tiden är slut, används åtagandetriangeln utöver den iterativa metoden. Åtagandetriangeln går ut på att dess tre hörn representerar egenskaperna hos ett åtagande, tid, kostnad och funktionalitet. Eftersom att tiden och kostnaden för projektet är fast, då examensarbetet har en deadline, så har funktionaliteten setts till att hållas flexibel under projektet. Detta görs för att undvika problem, om t.ex. tidsbrist skulle uppstå. Har ett projekt alla tre hörn fasta, blir det oftast svårare att uppfylla leveranskraven, då det inte finns något spelrum.
För att hålla funktionaliteten flexibel under projektet användes MoSCoW- modellen. Vilket innebar att projektets funktionella krav ordnades i prioritet enligt Must, Should, Could och Won’t. Alltså krav som måste vara klara i tid, krav som borde vara klara, men kan uppfyllas senare, krav som skulle vara bra att uppfylla, men som inte är kritiska och krav som inte ställs i projektet, men som är bra för framtiden. Genom att prioritetsordna kraven på detta sätt, gavs ett smidigt sätt att se vilka krav som var tvungna att bli klara i tid, och vilka som kunde hoppas över vid eventuell tidsbrist och lösas i efterhand.
14 3.4 Tekniska metoder
Det här avsnittet går igenom vilka tekniska val som gjorts under projektets gång, vilka programmerings- och utvecklingsmiljöer som använts och andra tekniska verktyg för t.ex. filhantering och modulering som använts under projektets gång.
Eftersom att applikationen EnvoMap som det här projektet skulle
implementera ny funktionalitet till, enligt problemformuleringen, var skrivet i C#, föll valet av utvecklingsmiljö enkelt på Visual Studio, då det i princip är ett måste vid utveckling i C#/.Net. Närmare bestämt användes versionen ”Visual Studio Express 2013 For Web” för det här projektet.
För att fortsätta, då EnvoMap är en webbapplikation, är klientsidan skriven i Html och JavaScript. Det också är möjligt att utveckla med i Visual Studio, men en extra editor som var mer anpassad för webbutveckling valdes också att användas, i det här fallet WebStorm. För att vara mer exakt användes
”JetBrains WebStorm 2017.1” för den del av utvecklingen som utfördes i Html och JavaScript.
Vidare valdes SQL Server 2014 för databashantering under projektet. Det var också ett tämligen enkelt val, då Gemit, företaget, använder sig av just SQL Server för databashantering. Någon form av servertjänst för att hantera geografisk data behövde också användas, för det här projektet föll valet på GeoServer, som beskrivs i kapitel 2, Bakgrund.
För att se till att koden som skrevs för projektet fick en så bra struktur och design som möjligt, valdes MVC som metod. Det är bra då MVC ger en bra paket- och klassindelning för systemet, vilket gör det lätt att underhålla, uppdatera och lägga till ytterligare funktionalitet till systemet. Detta redovisas mer i detalj i kapitel 4, Resultat.
För att sammanfatta användes alltså programmeringsspråken nämnda ovan, C#/.Net, Html, JavaScript och SQL för utvecklingen under projektets gång.
Där serversidan skrevs i C# i Visual Studio, klientsidan i Html och JavaScript i WebStorm och datahantering med SQL Server och GeoServer. Mer tekniska detaljer över lösningförslaget redovisas i kapitel 4, Resultat.
3.5 Metod för systemdokumentation
Det här avsnittet redogör för vilka metoder som använts för att dokumentera det lösningsförslag/prototyp som genom implementation, tagits fram för att lösa företagets (Gemit’s) problem.
Till att börja med borde projekt som arbetar med system- och
mjukvaruutveckling se till att ha en bra dokumentation över de system, applikationer och/eller funktioner som byggs. Detta för att underlätta för andra att ta del av och sätta sig in i de lösningar som utvecklats under projektets gång.
15 För att dokumentera projektets funktionella krav användes USE-CASE i UML som modell. Detta för att USE-CASE ger en tydlig visuell överblick på ett projekts krav. Resultatet av detta redovisas i bilaga 1 Funktionalitet.
Vidare användes klassdiagram i UML [16] för att dokumentera
lösningsförslagets design och datastruktur. Det ger en bra överblick på hur en applikation, lösning, är strukturerad och uppbyggd, vilken paketindelning och vilka klasser som används. Detta redovisas också i bilaga 2 Design.
För att dokumentera en databas som utvecklats under ett projekt, används vanligtvis t.ex. en relationsdatabasmodell. Eftersom databasen för detta projekt är så pass liten och endast använder sig av en tabell för några få test objekt, valdes att bara kortfattat beskriva den i text. Resultatet av detta redovisas i bilaga 3 Datahantering.
Vidare användes Git för att hantera den källkoden som skrevs under projektet, men även som metod för paketering och överlämning av resultat till Gemit, (företaget). För att hantera de dokument som skrevs under projektet användes Google Drive.
16
17
4 Resultat
Det här kapitlet går igenom projektets olika resultat. Kapitlet tar upp resultat på analys av företagets existerande lösningar, resultat från implementering av företagets (Gemit’s) problem, samt egna erfarenheter från implementation.
4.1 Företagets existerande lösningar
Det här avsnittet redogör för Gemit (företagets) existerande lösningar för hantering och användning av geografisk data i programmering.
Till att börja med hade Gemit lösningar för att visualisera och analysera geografisk data i form av objekt. Där objekten representerades med deras geografiska positioner, som ikoner på en dynamisk webbkarta. Ett exempel på objekt är olika företag.
Vidare fanns lösningar för att kunna söka efter objekt och få dem utritade på webbkartan. Användaren kunde också trycka på ikonen för ett visst objekt på kartan och få dess data listad. Lösningar för att kunna filtrera ut vilka objekt som skulle visas på kartan fanns också. Figur 4 nedanför visar en USE-CASE modell över de delar av EnvoMap som var väsentliga för projektet.
Figur 4: Bilden visar en USE-CASE modell över utvald funktionalitet från EnvoMap.
Bilden i figur 4 ovan visar en sammanfattande USE-CASE modell över huvudfunktionalitet på den del av EnvoMap som projektet har jobbat mot.
Observera att en del av funktionliteten utelämnades i den här modellen, men en mer detaljerad modell finns att se i bilaga 1 Funktionalitet.
18 För att fortsätta då projektet gick ut på att implementera en ny funktionalitet, hade inte Gemit någon existerande lösning för att kunna representera rutnät från shapefiler på webbkartan och hämta den data som rutnätet innehåller.
Figur 5 nedanför visar samma USE-CASE modell som i figur 4, men med de nya funktionella kraven inritade.
Figur 5: Bilden visar USE-CASE modellen för EnvoMap med de nya kraven inritad.
Figur 5 ovan visar USE-CASE modellen med utvald funktionalitet från
EnvoMap i vitt och den önskade funktionaliteten som projektet skulle uppfylla i grönt.
Resultat på lösningen till Gemit’s (företagets) problem som redovisas i avsnitt 4.2, skulle alltså kunna visualisera ett rutnät från en shapefil på en dynamisk webbkarta. Vidare skulle användare kunna välja ett område på kartan genom att rita på kartan och sedan kunna visa underliggande data för det området.
4.2 Lösning på företagets problem
Det här avsnittet går igenom och redovisar lösningsförslaget/prototypen som tagits fram under projektets gång, hur den fungerar och är uppbyggd.
Problemet som projektet skulle lösa var att Gemit, företaget, ville
implementera en ny funktionalitet till sin webbapplikation, EnvoMap. Den nya funktionaliteten var att en användare skulle kunna välja ett område på en dynamisk webbkarta i applikationen och få ut information om underliggande data i det området. Där underliggande data skulle läsas in från en shapefil i form av ett geografiskt rutnät.
19 Lösningen på detta blev en webapplikation uppdelad i en klient och en server sida. Server sidan skrevs i C# och klienten skrevs i html och JavaScript.
Resultatet av detta illustreras av figur 6 nedanför.
Figur 6: Bilden visar hur en användare har ritat in ett område på kartan.
Bild ovanför visar hur en användare har valt ett område på kartan genom att rita in det i form av den röda polygonen. De blåa linjerna visar det rutnät som lästs in som ett lager från en shapefil till kartan. Användaren kan sedan trycka var som helst i sin inritade polygon och få ut underliggande data om det området som polygonen begränsar. Informationen visas i form av den gråa textrutan. Exempel på underliggande data är vilka rutor och hur stor del av dessa som finns med i området, samt den data som rutorna innehåller.
Rutnätet från den shapefil som användes för test till lösningsförslaget i figur 1, bestod av kvadratiska rutor på 250 x 250 respektive 1000 x 1000 meter och hade en geografisk position i longitud och latitud. Varje ruta motsvarade ett geografiskt område och innehöll information om antal invånare för det området som testdata. När funktionaliteten från den här lösningen
implementeras på EnvoMap, systemet som företaget ville ha funktionaliteten till, så kommer rutorna dock innehålla data över föroreningsbelastning på VA- nätet (vatten och avlopp). Då uppgiften bara gick ut på att kunna hämta hur stor del av rutorna som fanns med i ett valt område, spelade det ingen roll vilken typ av information rutorna innehöll.
Vidare för att få en bra struktur för koden till lösning och för att koden skulle vara lätt att ändra och uppdatera, så användes mjukvarumönstret MVC, som förklaras i kapitel 2 Bakgrund. Klassdiagrammet i Figur 7 visar hur paket och klassindelningen ser ut för lösningen.
20
Figur 7: Klassdiagram över lösningen som togs fram i projektet.
Lösningen består av en server sida i C# som är indelad i pakten View,
Controller, Model, Integration och DTO. Se figur 7 ovanför. I modellen utförs beräkningarna som tar fram areorna av de rutor som finns med i det valda området. Klassen ViewHandler kommunicerar sedan med klienten för att skicka data mellan klienten och servern. Klienten är uppbyggd i Html och JavaScript. För en mer detaljerad beskrivning av lösningens klass och paket struktur se bilaga 2 Design.
För att kunna visa ett objekt eller ett rutnät från en shapefil på webbkartan, skapas en feature för det objektet eller den shapefilen, med openlayers som beskrivs i kapitel 2 Bakgrund. Figur 8 nedanför illustrerar ett exempel på detta.
Figur 8: Exempel kod för att skapa ett geometriskt objekt (feature).
Bilden i figur 8 ovan illustrerar hur en Feature kan skapas för ett objekt med dess longitud och latitud, genom användning av Openlayers. Denna Feature kan sedan skrivas ut som ett lager på kartan.
Vidare behövde lösningen kunna hantera geografiska rutnät i ”shapefile- format”, då det var ett av kraven på den nya funktionaliteten som företaget ville uppnå. För att lösa detta valdes GeoServer, som beskrivs i kapitel 2
21 Bakgrund. Kortfattat fungerar det så att shapefilen läggs upp på GeoServer, och läses sedan in till kartan i lösningen som illustreras i figur 6.
För att beräkna hur stor del av rutorna från rutnätet som ingick i det område användaren valde, behövdes areorna för de rutor som delvis låg med i den polygon användare ritat in beräknas. För att göra detta användes två metoder Pick’s Theorem och vanlig integral beräkning. Den senare användes till största delen, då beräkning av integralen var enklare för majoriteten av fallen.
Beräkningarna utfördes i C# på server sidan.
4.3 Egna erfarenheter från implementation
Det här avsnittet redovisar några av de erfarenheter som fåtts från det arbete som gjorts under projektets gång och ger rekommendationer utifrån det.
Till att börja med vid användning av geografisk data i mjukvaruutveckling, är det viktigt att tänka på vilket referenssystem som används eller ska användas av applikationen du utvecklar. Alltså vilken standard som används för att bestämma geografisk position på objekt. T.ex. om du vill räkna ut storleken på områden på kartan kanske SWEREF 99 funkar bäst, då den anger
koordinaterna i meter, dock funkar den bara för Sverige. Skulle något mer internationellt behövas, skulle en standard som WGS 84 fungerar bättre.
För att fortsätta vid användning av geografisk data i webbutveckling, finns ett bra JavaScript bibliotek som heter OpenLayers. Det innehåller en massa bra funktioner för hantering och användning av geografisk data, och kan vara värt att kolla på istället för att uppfinna hjulet igen.
För att gå vidare är det också bra att för användning av geografisk data vid mjukvaruutveckling, kolla på hur dess data sparas eller ska sparas. Vill du som exempel spara objekt innehållande data med geografisk position, är shapefil troligen det bästa formatet. För andra situationer skulle kanske något annat format fungera bättre, som t.ex. rasterbilder, eller SQL databas.
Ett annat tips om du gör ett liknande projekt och har tiden, gör inte förstudien för snabbt och gå inte nödvändigtvis på första bästa alternativ som fungerar.
Det kan finnas bättre lösningsalternativ, som du då går miste om. Ett exempel från det här projektet som var lite första bästa lösningen, är GeoServer som förvisso funkar riktigt bra för hanteringen av shapefiler, dock kan det finns smidigare sätt att lösa det på.
22
23
5 Analys och Diskussion
Det här kapitlet går igenom och diskuterar de metoder som används under projektets gång och de resultat som projektet har givit. Kapitlet ger även en slutsats av projektet och en analys på fortsatt arbete.
5.1 Metoddiskussion
Det här avsnittet diskuterar de metoder som använts för projektet, med fokus på validitet och reliabilitet.
Till att börja med gjordes en litteraturstudie för att få en större förståelse för företagets problem och vad som skulle göras. Under litteraturstudien
samlades bland annat information och referenser om vad geografisk data var, hur data- och programstrukturer skulle se ut, och vilka existerande lösningar som fanns.
Litteraturstudie som metod fungerade bra överlag och gav de svar/resultat som man hade förväntat sig, dock hade det förmodligen varit bra att vara lite bredare i undersökning av existerande lösningar för geografisk data. Då projektet hade en relativt kort deadline, så blev förstudien mer att hitta en lösning som fungerade och sedan implementera den, istället för att kolla på flera möjliga lösningar och försöka hitta en som var så bra som möjligt.
För att fortsätta användes åtagandetriangeln för att se till att projektet hölls flexibelt. Detta gjordes för att leveransen skulle bli så bra som möjligt vid projektets slut, även om något som t.ex. tidsbrist skulle uppstå. Tid och budget var fast för detta projekt, då det gjordes som examensarbetet, därför vart funktionaliteten tvungen att hållas flexibel. Det fungerade bra då MoSCoW prioritering användes. Dock borde tiden för rapportskrivning räknats in lite bättre i planen.
Efter litteraturstudien så analyserades kraven på lösningen och
prioritetordnades enligt MoSCoW. Detta var smidigt, då det enkelt gick att se vilka krav som skulle uppfyllas och det enkelt gick att hålla funktionaliteten rörlig och flexibel. Hade du i projektets början bestämt att exakt dessa krav skall uppfyllas, hade du inte haft något spelrum, då deadline och budget var fasta för detta examensarbete. Detta löstes på ett bra sätt med MoSCoW och åtagandetriangeln.
Nästa steg var att börja implementera de krav som var tvungna att bli klara.
Detta gjordes iterativt, det vill säga att ett krav i taget valdes och
implementerades som en iteration. Om ett av kraven behövde förbättras efter iterationens slut, kunde ett nytt iterationsvarv utföras. Att utveckla iterativt fungerade bra, då det enkelt gick att se vad som skulle utföras för stunden, och risken att försöka göra för mycket på en gång minskas. Dock borde kanske rapportskrivning tagits med i iterationerna, då det förmodligen hade gett en bättre struktur för hela arbetet och inte bara för utvecklingsdelen.
24 5.2 Resultatdiskussion
Det här avsnittet går igenom och diskuterar det resultat som givits av projektet.
Till att börja med diskuteras resultat på analys av företagets existerande lösningar. Resultaten som gavs där var huvudsakligen två USE-CASE
modeller för kraven. En för existerande funktionalitet på företagets befintliga system och den andra med kraven för den önskade funktionaliteten inritade.
Dessa resultat gav en tydlig bild på vad EnvoMap (företagets system) kunde göra och vad det skulle kunna göra efter avslutat projekt. Resultatet gavs utifrån analys av företagets existerande lösning och kraven på det
lösningsförslag som projektet skulle ta fram. Utifrån det så känns resultat som det förväntade, dock hade man kunnat kolla på större delar av EnvoMap och kanske också på andra lösningar som företaget har. Å andra sidan kan det vara bra att inte gräva ner sig på för mycket annat, utan istället fokusera på det som verkligen är väsentligt för projektet.
Nästa resultat som tas upp är lösningsförslaget som togs fram för att lösa företagets problem. Lösningsförslaget, som redovisas i kapitel 4.2, har förväntad funktionalitet, förutom en liten beräkningsformel som inte hanns med i projektet på grund av tidsbrist. Detta är dock inte kritiskt för projektet och kan lösas i efterhand. Det man skulle kunna gjort om det funnits lite mer tid vore att ha genomfört en mer omfattande förstudie, för att hitta en så bra lösning som möjligt. Dock gav resultatet ett fungerande lösningsförslag och några prestandakrav ställdes inte i projektet.
Efter det gavs resultat i form av egna erfarenheter och rekommendationer för användning av geografisk data vid mjukvaruutveckling. Dessa togs från det arbete som hade utförts under projektets gång, där de som kändes mest väsentliga valdes ut och dokumenterades som resultat. Då arbetet kretsade kring några få funktionella krav och gjordes som examensarbete, skulle förmodligen andra som gjort ett liknande projekt med ungefär samma förutsättningar kommit fram till liknande rekommendationer. Det som kanske skulle kunna gjorts bättre, vore att ha haft lite fler relevanta
rekommendationer och erfarenheter från utveckling med geografisk data i resultatet. Dock så var utvecklingsdelen ganska begränsad då projektet
gjordes som examensarbete, vilket medförde en svårighet i att hinna samla på sig många och bra erfarenheter från utveckling med geografisk data.
5.3 Etik och hållbarhet
Till att börja med, skrevs ett sekretessavtal på i början av projektet. Det innebar att information som kunde vara känsligt för företaget, inte fick delas hur som helst. Därför har en viss information som känsliga koder och data utelämnats från rapporten. Den shapefil som användes för projektet var som nämnt, en testfil. Detta medförde att bilder från körning av resultatet, kunde tas med i rapporten.
25 För att fortsätta, så kommer lösningen som togs fram i projektet, ihop med EnvoMap, användas för att kartlägga miljöpåverkan på vattennätet. I
EnvoMap kan data från olika mätpunkter registreras och kartläggas, vilket ger användare ett enklare sätt att lokalisera områden med stor
föroreningsbelastning på vattennätet, för att eventuellt kunna sätta in en åtgärd. Tillsammans med lösning som tas fram i projektet, kommer
användaren enklare kunna filtrera ut områden på kartan, för närmare analys.
Detta ger en förenkling i miljöarbetet för kommuner och deras reningsverk.
Avloppsvattnet [17] måste renas innan de släpps ut, annars kan det resultera i miljöpåverkan, som övergödning och reproduktionssvårigheter hos fisk.
Avloppsvatten innehåller också bakterier och virus som kan orsaka sjukdomar hos människor och djur om det inte hanteras på rätt sätt. Att avloppsvattnet hanteras och renas innan det släpps ut i naturen igen, bidrar alltså till en bättre miljö, vilket i sin tur bidrar till en hållbarutveckling.
5.4 Slutsats
Det här examensarbete gick ut på att ta fram ett lösningsförslag på företagets problem. Företaget ville implementera en ny funktionalitet till ett av deras befintliga system, EnvoMap.
Den funktionalitet man ville uppnå, var att användarna skulle kunna välja ett område på karta genom att rita in det och kunna plocka ut underliggande data från det området. Resultatet på detta blev en fungerande testapplikation som möter den nya funktionaliteten. Dock fanns några små detaljer som inte fungerade fullt ut, huvudsakligen på grund av tidsbrist i slutet på projektet.
Dessa var dock inte kritiska för projekt och kunde därför väntas med att slutföras till efter projektet. De kan ses under avsnitt 5.4 Fortsatt arbete.
Nästa huvudsyfte med det här examensarbetet var att försöka besvara frågeställningen, om hur geografisk data kan användas vid
mjukvaruutveckling. Vilket har undersökts parallellt med arbetet att ta fram lösningsförslaget.
För att svara på frågeställningen utfördes en undersökning, där bland annat, förstudie, implementation, dokumentation och analys användes som metoder.
Resultatet på undersökning redovisades och diskuterades bland annat i form av teori, erfarenheter och rekommendationer utifrån det arbete som utförts under projektens gång.
Kortfattat gav undersökningen resultatet att det finns standarder för b.la. hur objekt med geografisk position kan placeras på en karta, som måste användas.
Att det finns många format och programmeringslösningar som kan användas för att lagra och hantera geografisk data, t.ex. shapefiler och OpenLayers. Att användning av geografisk data i programmering kan bidra till en
hållbarutveckling, bland annat genom att kartlägga föroreningsbelastning på t.ex. vattennätet. Vilket medför att område där föroreningsbelastning är stor på vattenätet, kan lokaliseras och åtgärder kan sättas in.
26 5.5 Fortsatt arbete
Det här avsnittet ger en inblick på hur fortsatt arbete skulle kunna se ut efter projektet. Både i form av vidare utveckling och forskning.
För att börja så skulle vidare utveckling kunna gå ut på att utveckla
areaberäkningen att kunna beräkna areor för rutor med fler än en skärande rät linje. Alltså t.ex. en ruta från rutnätet, som skärs av två linjer från
användarens valda område.
Vidare skulle fortsatt arbete kunna gå ut på att implementera den nya
funktionaliteten från testapplikationen till EnvoMap, (systemet som företaget ville ha funktionaliteten till).
En till sak som skulle kunna göras vore att forska lite mer på existerande lösningar, för bland annat hantering av shapefiler och areaberäkning. För att kanske kunna hitta en smidigare och/eller snabbare lösning.
27
Referenser
[1] Eklund, Sven. Arbeta I Projekt – individen, gruppen, ledaren. Upplaga 4.
Lund: Studentlitteratur, 2010.
[2] Länsstyrelsen Stockholm. Vad är geodata? – Länsstyrelsen I Stockholms län. 2017. http://www.lansstyrelsen.se/Stockholm/Sv/om-lansstyrelsen/om- lanet/kartor-och-geodata/Pages/vad-ar-geodata.aspx (Hämtad 2017-04-25).
[3] Lantmäteriet. SWEREF 99, projektioner. 2017.
https://www.lantmateriet.se/sv/Kartor-och-geografisk-information/GPS- och-geodetisk-matning/Referenssystem/Tvadimensionella-system/SWEREF- 99-projektioner/ (Hämtad 2017-05-23).
[4] Havs och Vatten myndigheten. Mer om koordinater. 2014.
https://www.havochvatten.se/hav/samordning--fakta/kartor--gis/mer-om- koordinater.html (Hämtad 2017-05-23).
[5] Environmental Systems Research Institute, Inc. What is geodata? – Help | ArcGis for Desktop. 2016.
http://desktop.arcgis.com/en/arcmap/10.3/main/manage-data/what-is- geodata.htm (Hämtad 2017-04-25).
[6] Environmental Systems Research Institute, Inc. Shapefile file extensions.2016 http://desktop.arcgis.com/en/arcmap/10.3/manage- data/shapefiles/shapefile-file-extensions.htm (Hämtad 2017-05-24).
[7] Environmental Systems Research Institute, Inc. What is raster data? 2016.
http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and- images/what-is-raster-data.htm (Hämtad 2017-05-24).
[8] Microsoft. Spatial Data (SQL Server). 2017.
https://docs.microsoft.com/en-us/sql/relational-databases/spatial/spatial- data-sql-server (Hämtad 2017-05-24).
[9] OpenLayers. OpenLayers – Welcome. 2017. https://openlayers.org/
(Hämtad 2017-04-25).
[10] Proj4js. Proj4js. 2017. http://proj4js.org/ (Hämtad 2017-05-24).
[11] Open Source Geospatial Foundation. About – GeoServer. 2014.
http://geoserver.org/about/ (Hämtad 2017-04-27).
[12] WolframMathWorld. Polygon. 2017.
http://mathworld.wolfram.com/Polygon.html (Hämtad 2017-05-29).
[13] WolframMathWorld. Pick’s Theorem. 2017.
http://mathworld.wolfram.com/PicksTheorem.html (Hämtad 2017-05-29).
28 [14] WolframMathWorld. Integral. 2017.
http://mathworld.wolfram.com/Integral.html (Hämtad 2017-05-29) [15] Andersson, Niclas och Ekholm, Anders. Vetenskaplighet – Utvärdering av
tre implementeringsprojekt inom IT Bygg och Fastighet. Lund 2002.
[16] Larman Craig, Applying UML And Patterns. Upplaga 3. Prentice Hall, 2004.
[17] Naturvårdsverket. Avloppsvattnets miljöpåverkan. 2016.
http://www.naturvardsverket.se/Sa-mar-
miljon/Vatten/Avloppsvatten/# (Hämtad 2017-06-26).
1
Appendix A Arkitektur Bilaga 1 Funktionalitet
Det här bilagan går igenom de funktionella kraven för lösningen, i form av USE- CASE diagram och förklaringar.
Funktionella krav
Under detta examensarbete utvecklades en webbapplikation som prototyp och lösningsförslag på Gemit’s (företagets) problem. Det Gemit ville åstadkomma var en ny funktionalitet på EnvoMap som skulle låta användaren välja ett område på kartan och visa underliggande data för det specifika området.
Den underliggande datan skulle läsas in från en shapefil i form av ett rutnät med geografisk position, till ett lager på kartan i applikationen. Där varje ruta kunde innehålla data om t.ex. föroreningsbelastning. Bilden i figur 1 nedanför visar hur rutnätet såg ut.
Figur 1: Bilden visar rutnätet från den shapefil som användes i projektet.
2 Alla rutor i figur 1 var kvadratiska, med de små rutorna i storleken 250 x 250 meter och de stora rutorna i storleken 1000 x 1000 meter. Vidare hade de en position på nedre vänstra hörnet i kartprojektionen SWEREF 99 TM, vilket innebar att positionen angavs i meter.
För att välja ett område på kartan skulle användare rita in det i form av en polygon. När användaren gjort det var tanken att applikationen skulle beräkna vilka rutor från rutnätet och hur stor del av dem som fanns med i polygonen.
Bilden i figur 2 nedanför visa hur en användare väljer ett område av rutnätet genom att rita på kartan.
Figur 2: Exempel på hur en användare kan välja ett område på kartan genom att rita.
De ljusblå linjerna i figur 2 visar hur användaren väljer ett område genom att rita en polygon direkt på kartan. Användaren kan sedan trycka på sin inritade polygon och få ut informationen från de rutor som ingick i området. Figur 3 visar detta.
3
Figur 3: Exempel på hur information om underliggande rutor visas för användaren.
4 USE-CASE
I det här avsnittet illustreras de funktionella kraven i form av USE-CASE diagram, för att få en tydligare bild över dem.
Till att böra med gjordes en analys på Gemit’s befintliga lösning (EnvoMap) för att se hur den fungerade och om det fanns något som kunde användas för utvecklandet av den nya funktionaliteten. Som resultat på detta gjordes en USE-CASE modell på den del av EnvoMap som kändes väsentlig för projektet.
Den visas i figur 4 nedanför.
Figur 4: USE-CASE modell för en del av EnvoMap.
EnvoMap består av flera vyer (delsidor), bland annat vy för att logga in, vyer för kemikalieanalys, administratörs vyer, mm. Då alla dessa vyer inte är väsentliga för projekt, gjordes USE-CASE modellen i figur 4 på den del av EnvoMap som projektet skulle arbete mot, nämligen kartvyn.
Exempel på vad en användare kan göra på kartvyn är att söka efter företag och objekt, filtrera vilka som skall visas och få dem utritade på kartan som ikoner.
Användare kan också trycka på en ikon för ett företag eller objekt och fått ut den information som finns tillgänglig för det företaget eller objektet. Exempel på objekt kan vara brunnar, provtagningspunkter och slamtömningspunkter.
Vidare kan användare också visa olika typer av vattenledningar, som t.ex.
ledningar för dricksvatten, dagvatten och spillvatten.
5 Efter analysen av EnvoMap, så gjordes en till USE-CASE modell där de nya kraven ritades in tillsammans med den befintliga funktionaliteten. Figur 5 visar detta.
Figur 5: USE-CASE modell för en del av EnvoMap plus den önskade funktionaliteten.
Den USE-CASE modell som visas i figur 5 ovanför, visar den befintliga funktionaliteten från figur 4, tillsammans med kraven för den önskade funktionaliteten. Befintlig funktionalitet illustreras i vitt och önskad funktionalitet i grönt.
För att sammanfatta är de funktionella krav för det lösningsförslag/prototyp som tas fram i projektet:
• Kunna visa ett rutnät med geografiskdata från en shapefil som ett lager på kartan.
• Kunna välja ett område på kartan genom att rita in det som en polygon.
• Kunna visa informationen från de rutor som ingår (överlappar) valt område, samt hur stor del (arean) av rutorna som ingår i det valda området.
6 MoSCoW prioritering
Det här avsnittet presenterar hur den önskade funktionaliteten från figur 5 delades in i mindre krav och prioriterades enligt MoSCoW.
Till att börja med tas kraven som måste vara klara upp, (Must):
• Kunna visualisera en karta i webbapplikationen
• Kunna visualisera innehållet från en shapefil på kartan
• Kunna rita en polygon på kartan för att välja område
• Kunna visa vilka rutor från rutnätet som överlappas av (ingår i) polygonen
Nästa del är de krav som borde vara klara, (Should):
• Beräkna arean av den del av en ruta som ligger i polygonen där rutan bara skärs av en linje
• Beräkna arean av den del av en ruta som ligger i polygonen där rutan skärs av två eller fler linjer.
• Kunna rita ut objekt från en SQL databas som ikoner på kartan Efter det har vi kraven som skulle vara bra att uppfylla, men som inte är kritiska för projektet, (Could):
• Kunna klicka på en ruta i rutnätet och få informationen om den rutan
• Kunna välja ritverktyg, t.ex. linje, polygon eller inget
• Kunna få ut vilka objekt som ligger i polygonen
Till sist har vi det krav som inte ställs i projektet, men som kan vara bra för framtiden, (Won’t):
• Kunna klicka på ett objekt och få ut informationen om den
• Kunna ta bort den inritade polygonen från kartan
• Kunna visa informationen som ”Popup rutor”.
Sammanfattningsvis ger det här en tydlig bild över vilka kraven som finns på projektet. Samt vilka som måstes ses till att bli klara och vilka krav som kan skjutas lite på utan någon kritisk påverka på projektet.
7
Bilaga 2 Design
Den här bilagan går igenom och förklara lösningens programstruktur. Hur den är indelad i paket och klasser och användning av MVC m.m. Strukturen illustreras i form av ett klassdiagram i UML.
Applikationens struktur
Följande avsnitt går igenom hur lösningsförslaget är strukturerad vad det gäller filer och kod. Figur 6 nedanför visar filstrukturen för applikationen.
Figur 6: Bilden visar filstrukturen för lösningsförslaget.
Applikationen är indelad i rotmappen TestWebAppForGeo, med
undermapparna App_Code, css, icons och js. Där App_Code innehåller all kod för server sidan i C#. Koden på server sidan är dessutom strukturerad enligt MVC, för att få en så lätt hanterlig kod som möjligt. Koden för klient ligger i filen index.html som ligger direkt i rotmappen. Att ha all C#/.Net kod i en mapp som heter App_Code och index.html i rotmappen görs för att det är standard för en .Net webbapplikation. Mappen css innehåller all css-kod för applikationen, icons innehåller ikoner som kan användas för att markera objekt och företag på kartan och js innehåller JavaScript filer för
applikationen.
8 Klass- och paketindelning
Det här avsnittet redogör och visar hur klass- och paketindelningen ser ut för applikationen. Vilka metoder och globala variabler som används av klasserna illustreras också. Se figur 7 nedanför.
Figur 7: Klassdiagram över lösningsförslaget.
Som tidigare nämnt så är applikationer strukturerad med MVC, med paketen och klasserna som kan se i figur 7 ovanför. All kommunikation mellan vyn, modell- och integrationslagret går via controllern. Där integrationslagret hanterar alla frågor mot databasen och modellen hanterar beräkningarna av rutornas areor.
Paketet DTO (står för Data Transfer Object), håller de objekt som används för överförning av data mellan klienten och servern, samt för att skicka data mellan klasserna på servern. Alltså har alla klasser associationer till paketet DTO, dessa valdes dock att inte ritas ut i klassdiagrammet då det lätt hade blivit väldigt rörigt.
9
Bilaga 3 Datahantering
Det här kapitel går igenom hur den data som används av lösningen hanteras, både som shapefiler och i SQL format.
Shapefiler
Det här avsnittet tar upp hur den shapefil som innehåller rutnätet, som används i lösningsförslaget, hanteras.
Till att börja med består shapefilen som används i lösningen av fyra filer, vilket kan ses i figur 8 nedanför.
Figur 8: Bilden visar de filer som shapefilen för projektet bestod av.
Filen med ändelsen .shp är huvudfilen som innehåller featurens geometri, .shx är indexfilen och .dbf är databasfilen som håller attribut informationen för shapefilen. Den sista filen med ändelsen prj innehåller
koordinatinformationen för shapefilen.
För att rita ut rutnätet från dessa filer som ett lager på kartan i
lösningsförslaget används GeoServer. GeoServer är en open source server för att dela geospatialdata. Den kan laddas ner som en WAR fil, vilket enklast körs på en Tomcat server. GeoServer körs sedan som en webbapplikation där du kan lägga upp dina shapefiler, se figur 9 neadnför.
Figur 9: Bild på användargränssnitt för GeoServer.
10 I bilden i figur 9 ovanför visas en bild för körning av GeoServer. I vyn som visas listas lager som är färdiga att ritas ut i t.ex. en webbapplikation. När en shapefil har lagts upp på din GeoServer listas den här så att du kan förhandsvisa hur dess innehåll ser ut. Ett exempel på hur förhandsvisningen kan se ut är bilden i figur 1 under avsnitt 1.1 Funktionella krav.
SQL databas
Det här avsnittet tar upp användningen av SQL databas för lösningsförslaget, hur databasen ser ut och hur den används.
För den här lösningen användes bara en liten SQL databas bestående av en tabell, som används för att lagra objekt som kan användas till test. Objekten har ett id för att identifiera dem unikt, ett namn, ett värde (för att kunna räkna på vid test) och till sist longitud och latitud för att kunna positionera dem på kartan i applikationen. Figur 10 nedanför illustrerar strukturen på tabellen.
Figur 10: Bilden visar strukturen för den databastabell som används i lösningen.
Databasen består som sagt av en tabell, ses i figur 10. Attributet ID är unikt för varje rad och används som primärnyckel. Attributen longitude och latitude sattes till typen float för att kunna ta tal med många decimaler. Attributet value sattes typen till bigint för att hålla större heltal som kunde användas för test.
Till sist har vi attributet name som är namnet på objekten, vilket hanteras som en string, alltså formen varchar i databasen.
1
TRITA TRITA-ICT-EX-2017:66
www.kth.se
