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