Detta examensarbete har genomf¨orts i samarbete med DGC. Handledare p˚aDGC: Paul Weingarten och Bj¨orn Osterman.¨

Karttill¨ampningar f¨or rikst¨ackande accessn¨at Map applications for nationwide access net

Johan Camling Fredrik Lonnegren¨

Examensarbete inom Datorteknik Grundniv˚a,15 hp Handledare p˚aKTH: Jonas W˚ahsl´en Examinator: Ibrahim Orhan Skolan f¨or teknik och h¨alsa TRITA-STH 2013:73

Kungliga Tekniska H¨ogskolan Skolan f¨or teknik och h¨alsa 136 40 Handen, Sweden http://www.kth.se/sth

i

Sammanfattning

Denna rapport ˚atergerarbetsprocessen kring att utv¨ardera geografiska tj¨anster, och att utveckla karttill¨ampningar f¨or n¨atverk av rikst¨ackande om- fattning. Arbetet utf¨ordes p˚aplats hos DGC, en datakommunikations-, tele- och n¨atoperat¨or som distribuerar kundf¨orbindelser i hela Sverige d¨ar konsu- menter ansluts till stamn¨atet.

Uppgiften bestod av att utv¨ardera m¨ojligheter till att sl˚aupp koordinater f¨or etablerade kundplatser, rita ut accessn¨atet i ett kartgr¨anssnitt och ta fram ett eller flera st¨odverktyg f¨or bland annat orderprocesser.

Anv¨andningsfall utifr˚an ¨onskem˚al,arkitekturm¨onster samt analys av yttre leverant¨orers tj¨anster f¨or geocoding avgjorde hur det slutgiltiga systemet var utformat. Mjukvaran som utvecklades integrerades b˚adei befintliga system och som ensamst˚aendetill¨ampningar. En publicering/release genomf¨ordes som avslutande moment i arbetet.

I rapporten beskrivs hur kartl¨aggning gjordes med hj¨alp av KML, hur geogra- fisk data hanterades, utformningen av ¨overvakningsverktyget som framtogs samt hur koordinater f¨or adresser h¨amtades.

iii

Abstract

This thesis describes the process of analyzing and evaluating geographic ser- vices, and the development of map applications for nationwide networks. The project was performed at DGC, a datacommunications-, telephony- and networks operator which distributes customer access across Sweden where consumers are connected to the backbone network.

In whole, the task consisted of an analysis regarding the possibilities of address-to-coordinate lookup for established customer sites, displaying the access network in a map interface and developing one or more tools, aimed at supporting order processes.

Architecture patterns, use-cases construed from user requests and analysis of external provider services for geocoding determined the design of the so- lution. Software was partially integrated in existing systems, and partially distributed as stand-alone applications. The product was finalized with a re- lease.

Read further to get a description of the monitoring tool, network mapping with KML, dealing with geographic data, and also the process of fetching coordinates for addresses.

v

F¨orord

Vi vill passa p˚aatt ge ett stort tack till Paul Weingarten och Bj¨orn Osterman¨ f¨or det st¨od och samarbete som vi hade i projektet. Vi har med hj¨alp av er f˚atten djupare f¨ors˚aelsei distribuerade system, SQL och programutveckling i bland annat .NET. Vi vill g¨arna ge ett snabbt tips till l¨asaren om teckenf¨orklaringen som inleder rapporten: som h¨anvisning till n˚agraav de termer och f¨orkortningar som anv¨ands i texten. Ocks˚aett stort lycka till, till Thomas Lundberg och Alexander Heimonen som p˚ab¨orjade sitt examensarbete, ocks˚ap˚aDGC, knappt fyra veckor efter att vi hade startat.

vii

Teckenf¨orklaring

.NET - Microsofts platform AJAX - Asynchronous Javascript And XML API - Application Programming Interface CLR - Common Language Runtime DAL - Data Access Layer MVVM - Model View Viewmodel WCF - Windows Communication Foundation WPF - Windows Presentation Foundation XML - Extensible Markup Language XAML - Exstensible Application Markup Language Webservice - En tj¨anst som anropas f¨or att f˚adata genom antingen REST- f¨orfr˚agningareller SOAP-anrop REST - Representational State Transfer SOAP - Simple Object Access Protocol Caching - Processen att spara data i minnet f¨or en applikation KV - Key-value-par DB/Db - Databas SQL - Structured Query Language Parsing - Processen att tolka information ur ett svar fr˚ant.ex en webservice

GPS - Global Positioning System GIS - Geographic Information System OSM - Open Streetmap KML - Keyhole Markup Language KMZ - Keyhole Markup Zip

TDD - Test Driven Development

ix

Inneh˚all

1 Inledning och bakgrund 1 1.1 F¨oretagsbeskrivning ...... 1 1.2 Projektbeskrivning ...... 1 1.2.1 M˚alformulering ...... 2 1.2.2 Avgr¨ansningar ...... 3 1.2.3 L¨osningsmetoder ...... 3 1.3 Nul¨agesbeskrivning ...... 4 1.4 Summering ...... 4

2 Teoretisk referensram 5 2.1 Geodesi ...... 5 2.1.1 Latitud och longitud ...... 5 2.2 Geocoding ...... 5 2.3 Datatypen Geography ...... 6 2.4 KML och KMZ ...... 6

3 F¨orstudie 7 3.1 Externa geografitj¨anster ...... 7 3.2 Geocoding, licensiering och persistent datalagring ...... 8 3.2.1 Google Maps APIs ...... 8 3.2.2 Bing Maps Platform APIs ...... 9 3.2.3 Yahoo! Maps API ...... 10 3.2.4 MapQuest ...... 10 3.2.5 Nominatim ...... 11 3.3 Tillf¨orlitlighet av uppslag ...... 11 3.3.1 Google ...... 11 3.3.2 Bing ...... 12 3.3.3 MapQuest ...... 12 3.3.4 Nominatim ...... 12

4 Genomf¨orande 13 4.1 Tredjepartstj¨anster ...... 13 4.1.1 Val av tredjepartsleverant¨orer ...... 13 4.2 Arkitektur ...... 14 4.2.1 Geocoding Service ...... 14 4.2.2 Geofinding Service ...... 14

xi 4.2.3 Webbvy med modell ...... 14 4.2.4 DbSeeder ...... 15 4.3 Geocodes fr˚anextern leverant¨or ...... 15 4.3.1 J¨amf¨orelse med viktade v¨arden ...... 15 4.3.2 Parsing ...... 17 4.3.3 Confidence-filter ...... 17 4.3.4 Cache ...... 19 4.4 Lagring av positionsdata ...... 20 4.5 WPF ...... 21 4.6 Webbvyer ...... 22 4.6.1 Javascriptmodulen geo.js ...... 22 4.6.2 Overvakning¨ ...... 23 4.7 Publicering ...... 24 4.7.1 Beslut om geocoding ...... 24 4.7.2 Tillkomna st¨od med tillh¨orande licenser ...... 25 4.7.3 Verktyg ...... 25

5 Interna ¨onskem˚al 26 5.1 Kundportal ...... 26 5.2 Vy med huskroppar ...... 26

6 Resultat 27 6.1 Geocode service ...... 27 6.2 Anv¨andargr¨anssnitt i form av kartor ...... 27 6.2.1 Overvakningsvy¨ ...... 28 6.2.2 Kundvy ...... 28 6.2.3 KML i Google Earth ...... 28 6.3 Enhetstestning och dokumentation ...... 29 6.4 Uppfyllande av m˚alen...... 29

7 Slutsatser 30

8 Rekommendationer 31

K¨allf¨orteckning 32

Bilagor 37 A Systemarkitektur ...... 37 B KML i en geografisk l¨asare ...... 38

xii B.1 Exempeldata i KML ...... 39 B.2 KML-generering med LINQ To XML ...... 40 C Kartvy ...... 41 D How-To ...... 42 D.1 Controller ...... 42 D.2 Modul ...... 43 D.3 View ...... 45

xiii

1 Inledning och bakgrund

I detta avsnitt beskrivs bakgrunden f¨or hur projektet kom att uformas, vilket sorts f¨oretag det gjordes f¨or och en ¨overgripande beskrivning av m˚als¨attningarna. Aven¨ de val av tillv¨agag˚angss¨att som gjordes under projektet och tillm¨otesg˚aendeav de behov som fanns motiveras.

1.1 F¨oretagsbeskrivning DGC ¨ar en n¨atoperat¨or som utvecklar och s¨aljer datakommunikations-, drift- och telefonil¨osningar i ett eget rikst¨ackande n¨at till f¨oretag och organisationer som har verksamhet p˚am˚angaplatser. DGC hyr koppar- och fiberf¨orbindelser av n¨at¨agare i Sverige f¨or att ansluta slutkunderna till sitt stamn¨at. Slutkundens adress och geografiska position avg¨or vilka n¨at¨agare som ¨ar aktuella samt vilka tj¨anster som de kan erbjuda DGC.

1.2 Projektbeskrivning N¨ar internetaccess skulle s¨aljas till nya kunder unders¨oktes f¨orst vilken un- derleverant¨or som kablage skulle hyras av baserat p˚aslutkunders adress. I de orderprocesser som genomf¨ordes unders¨oktes slutkunders adresser i detalj, men systemst¨od f¨or att s¨oka fram adressers koordinater och spara dessa i ett strukturerat format saknades. Detta medf¨orde kostnader i tid f¨or de beslut som r¨orde kunders geografiska placering i f¨ors¨aljningsprocessen. F¨or att kunna ta fram verktyg som skulle underl¨atta beslutsprocesser vid ink¨op av n¨attj¨anster ¨onskade DGC modifiera sina befintliga system f¨or att st¨ojda koordinater, samt ta fram ett nytt system f¨or uppslag av koordinater fr˚anextern leverant¨or. Ut¨over nyttan i ink¨opsprocessen s˚av¨arderade DGC m¨ojligheten att anv¨anda geografisk information f¨or att presentera sina tj¨anster p˚aen karta, b˚adein- ternt och i sin kundportal.

1 1.2.1 M˚alformulering Arbetet f¨orv¨antades resultera i ett eller flera system, efterforskningar och analyser. Dessa var:

• En unders¨okning av vilka leverant¨orer av geografiska tj¨anster som b¨ast kunde l¨osa problemet och som en webtj¨anst sedan skulle implementera.

• Ett strukturerat s¨att att lagra geografisk data i befintliga system.

• En kartl¨aggning och teknisk analys av delsystemens syften och vad de skulle ha f¨or roll i ett st¨orre sammanhang.

• Funktionalitet f¨or att ber¨akna n¨arhet mellan koordinater.

• Utf¨ora geocoding p˚abefintlig data i befintliga system.

• Kartl¨aggning av interna ¨onskem˚al.

• Generera geografisk information till ett strukturerat format och sedan anv¨anda informationen f¨or uppritning i vyer.

• En webvy f¨or att presentera data grafiskt.

• En WPF-kontroll som presenterar data grafiskt.

• Att kunna m¨ata proximitet mellan punkter f¨or att avg¨ora hur en order ska f¨orfaras.

• Att kunna anpassa grafisk presentation utifr˚ant¨athet.

• Implementation i befintliga system.

Grundtanken med projektet var att skapa flera, i s˚ah¨og grad som m¨ojligt, anv¨andbara verktyg f¨or intern verksamhet p˚aDGC. Programvara skulle va- ra fels¨aker och skriven med kvalitetss¨akrad kod, b˚adef¨or att f¨ors¨akra att delsystem var robusta i drift och f¨or att underl¨atta framtida utveckling.

2 1.2.2 Avgr¨ansningar Arbetet omfattade ej:

• Utveckling utanf¨or plattformen .NET. Detta f¨or att uppn˚ah¨og kohe- rens med befintliga system och kodkonventioner hos DGC.

• Utveckling av k¨allkod f¨or geografiska uppslag ut¨over nyttjande av exi- sterande webtj¨anster.

• F¨orvaltning eller underh˚allav systemet efter arbetets slutf¨orande

F¨or att uppfylla den korrekthet som ¨onskades av DGC l¨amnade k¨allkod och annat projektrelaterat material inte DGC:s intran¨at. D¨arf¨or ¨ar denna un- ders¨okande rapport till stor del inte beskrivande p˚aimplementationsniv˚a, och namngivelser samt arkitektoniska strukturer f¨orblir till viss del dolda.

1.2.3 L¨osningsmetoder De tillv¨agag˚angss¨att som anv¨andes under arbetet var ¨overrenskomna med DGC. F¨or att undvika fallgropar och f¨orseningar i s˚ah¨og grad som m¨ojligt, samt f¨or att optimera arbetet fanns det rum f¨or ¨andringar i dessa metoder.

• Ta fram en ¨overgripande arkitektur f¨or systemen, och i den kunna peka p˚avar de geografiska tj¨ansterna skulle befinna sig, och vilka data de skulle ha ˚atkomst till.

• Utveckla webtj¨anster med tydligt definierade uppgifter och funktioner f¨or geografiska uppslag.

• Anpassa f¨orfr˚agningarmot externa leverant¨orer f¨or att kringg˚ade pro- blem som framst¨alldes i och med att det fanns ett maximalt antal h¨amtningar som fick g¨oras per tidsenhet.

• Enhetstester/Test Driven Development (TDD), d¨ar m˚aletvar att samt- liga delar av l¨osningen var testade.

• Lagra data med hj¨alp av de Common Language Runtime (CLR)-klasser f¨or geografisk data som fanns tillg¨angliga, och anv¨anda dessa f¨or att m¨ata avst˚andmellan koordinater.

• Kartl¨agga interna ¨onskem˚alf¨or att uppn˚ah¨ogsta m¨ojliga anv¨andbarhet.

3 • Unders¨oka heuristiska metoder f¨or att dela upp kartvyer med h¨ansyn till t¨athet (kartomr˚adenmed m˚angaaccesser beh¨ovde anpassas s˚aatt information kunde presenteras l¨att¨oversk˚adligt).

• Unders¨oka Windows Presentation Foundation (WPF)-kontroller med kartor i ˚atanke; hur man kunde binda kartdata samt utnyttja MVVM (Model View ViewModel)-paradigmen f¨or att presentera en karta.

1.3 Nul¨agesbeskrivning DGC ¨ar ett b¨orsnoterat f¨oretag som s¨aljer och drifts¨atter datakommunika- tionsl¨osningar. Ut¨over de tj¨anster som DGC erbjuder bedrivs systemutveck- ling internt hos f¨oretaget.

Majoriteten av de system som utvecklas och drifts¨atts hos DGC har syf- tet att underl¨atta och f¨orb¨attra alla de interna processer som bedrivs. All ¨overvakning och mestadelen av s¨aljprocesser genomf¨ors med hj¨alp av de st¨odverktyg som tas fram. Nya anv¨andningsomr˚adend¨ar st¨odsystemen kan integreras p˚atr¨affas kontinuerligt, d¨ar funktioner som st¨odjer framf¨orallt s¨alj- och leveransf¨orlopp ¨ar beh¨ovliga.

Det finns ¨onskem˚alom att ta fram delsystem som arbetar med geografisk data f¨or att underl¨atta f¨ors¨aljningsf¨orfaranden, ¨overvakning och presenta- tion av accessn¨atet i b˚ade ¨overvakningssystem och kundportal. Data m˚aste struktureras och ansvaras av tydligt inramade l¨osningar och tj¨anster.

Att sl˚aupp koordinater f¨or befintlig data, d¨ar m¨angden av registrerade och etablerade kundaccesser ¨ar stor, kr¨aver en heuristisk l¨osning som ¨ar v¨al testad och dokumenterad f¨or att s¨akerst¨alla anv¨andbarhet samt framtida utveckling.

1.4 Summering Med utg˚angspunktfr˚anDGC:s behov och ¨onskem˚altogs en ¨overgriplig pro- jektdefinition fram med styrande m˚aloch avgr¨ansningar. F¨or att bem¨ota de krav som fanns gjordes en studie av hur orderprocesser kunde komma att underl¨attas med hj¨alp av de st¨odverktyg som skulle utvecklas.

4 2 Teoretisk referensram

Detta kapitel syftar till att f¨orklara de begrepp och teorier som ligger till grund f¨or m˚angaav de tekniker som anv¨andes i arbetet. Tanken ¨ar att av- snittet ska ge en f¨orst˚aelseoch m¨ojlighet till ˚aterkoppling som underl¨attar l¨asningen av kommande kapitel med en ¨overgripande genomg˚angav geografi (2.1), databehandlingsmetoder (2.2, 2.3) och representationsformat (2.4).

2.1 Geodesi Geodesi, vetenskapen om uppm¨atningar av planeten jorden. Inom det teoretiska omr˚adeting˚ardet att utf¨ora punktm¨atningar utifr˚anpla- cering, tyngdkraftsv¨arden och m.¨o.h [1] f¨or att ta fram en kartl¨aggning ¨over jorden. Geodesin ¨ar tillsammans med astronomin en av de ¨aldsta vetenska- perna [2]. Anledningen till att det tas upp h¨ar ¨ar f¨or att vetenskapen ligger till grund f¨or arbetet som genomf¨ordes, vad g¨aller att best¨amma positionering av adresser i DGC:s stamn¨at.

2.1.1 Latitud och longitud Eftersom jorden mestadels kan antas vara sf¨arisk [3] anv¨ands latitud (bredd, φ) och longitud (l¨angd, λ), vilka ¨ar gradm¨atningsv¨arden som beskriver punk- ter p˚ajordens yta i form av vinklar mot mittpunkten. Altitud anv¨ands f¨or att m¨ata avst˚and ovanf¨or jordytan. Ett exempel p˚aett latitud/longitud-par ¨ar lat 59◦, lon 18◦(Stockholm, Sve- rige).

2.2 Geocoding Med geocoding menas att hitta koordinater f¨or en namngiven plats. Adresser binds till ett latitud/longitud-par via ett uppslag mot en extern leverant¨or. Exempel p˚aexterna leverant¨orer ¨ar Google, vars prim¨ara databask¨alla ¨ar TeleAtlas (ett dotterbolag till TomTom [4]), och Microsofts Bing som har NavTeq som st¨orsta underleverant¨or [5]. Vanligast ¨ar att geocodetj¨anster koms ˚atvia REST. Alla tj¨anster varierar i tr¨affs¨akerhet, baserat p˚avilken databask¨alla som begagnas av dem. Dessutom skiljer sig distribut¨orer av geografiska tj¨anster i skala, d¨ar de som oftast ¨ar mindre tr¨affs¨akra har st¨orre omfattning av l¨ander och platser [6].

5 2.3 Datatypen Geography I .NET framework 4.5 [7] introducerades nya datatyper f¨or att hantera geo- grafi (DbGeography) och geometri (DbGeometry). Eftersom dessa typer ocks˚a ¨ar implementerade som .NET CLR-klasser i Microsofts SQL Server g˚ardet att anv¨anda dessa klasser direkt i databaslogiken. F¨or att fr˚andatabasen f˚aut distansen mellan tv˚ageografiska punkter anv¨ands d¨armed f¨oljande exempelkod i en databasf¨orfr˚agning:

SELECT @geog1 = GeogCol1 FROM SpatialTable WHERE id = 1; SELECT @geog2 = GeogCol1 FROM SpatialTable WHERE id = 2; SELECT @result = geog1.STDistance(@geog2);

Denna funktionalitet f¨orskjuter databehandlingen fr˚anDAL direkt till da- tabasen som ¨ar optimerad f¨or att behandla stora m¨angder data. Detta ger ocks˚af¨ordelen att mindre data beh¨over skickas mellan databas och DAL.

2.4 KML och KMZ KML ¨ar ett internationellt standardformat, till f¨or att presentera geogra- fisk data visuellt. Anda¨ sedan Keyhole utvecklade KML ˚ar2001 har flera geografiska l¨asare anpassat sina system f¨or att st¨odja spr˚aket. Det officiella namnet OpenGIS KML 2.2 Encoding Standard (OGC KML) kommer fr˚an och kontrolleras av Open Geospatial Consortium [8, 9]. KML st¨ods av bland andra:

• Microsoft Virtual Earth

• Microsoft WorldWide Telescope

• NASA Worldwind

• ESRI ArcGIS Explorer

• Google Maps

• Google Earth

6 3 F¨orstudie

Innan n˚agon form av implementation och utveckling kunde genomf¨oras kr¨avdes kunskap och fakta vad g¨allde de byggstenar som systemet beh¨ovde, framf¨orallt f¨or koordinatuppslagningar. I f¨orstudien unders¨oktes fr¨amst m¨ojligheter f¨or geocoding vad g¨aller licensavtal och ¨oppenhet, och i detta avsnitt kommer dessa punkter att behandlas.

3.1 Externa geografitj¨anster F¨or att n˚aett av de mest grundl¨aggande m˚alenf¨or projektet, det vill s¨aga strukturerad koordinatdatalagring, kr¨avdes det att externa leverant¨orstj¨anster anv¨andes. Den funktionalitet som efters¨oktes var bland annan:

• Matris- och avst˚andsber¨akningar utifr˚anangivna koordinater.

• Operationer f¨or geocoding/reverse-geocoding (se 2.2).

• Grafisk presentation av data.

En avv¨agning gjordes f¨or att best¨amma vilken tj¨anst (eller kombination av tj¨anster) som l¨ampade sig b¨ast f¨or att uppn˚a ¨onskv¨arda resultat. Tre st¨orre leverant¨orer av karttj¨anster utv¨arderades; Google, Bing och Yahoo, samt tv˚agratisalternativ; Nominatim och MapQuest. Respektive leverant¨or kr¨avde att vissa villkor uppfylldes (3.2) om deras tj¨anster implementerades av, f¨or dem, utomst˚aendeapplikationer. Dessa villkor gav en grund till den bed¨omning som gjordes.

7 3.2 Geocoding, licensiering och persistent datalagring Avg¨orande f¨or projektet var om det, enligt villkoren f¨or anv¨andning, var till˚atetatt lagra uppslagna koordinater fr˚an olika leverant¨orer, samt i vilken utstr¨ackning anv¨andandet av geocodes var lovligt. Aven¨ andra anv¨andares erfarenheter av olika leverant¨orers tj¨anster unders¨oktes [10]. Ett urval av geocodetj¨anster ¨ar [11]:

• Google

• Yahoo

• Bing

• CloudMade

• OpenAddress

• MapQuest

• Nominatim

3.2.1 Google Maps APIs De villkor som st¨alldes f¨or anv¨andning av Google Maps APIs [12], vilka om- fattade samtliga verktyg i tj¨ansten, angav att det var f¨orbjudet att bland annat:

1. Lagra data h¨amtat fr˚ant.ex Geocoding Service i mer ¨an 30 dagar (mest p˚agrund av att Google inte vill att f¨or˚aldratdata anv¨ands, och upp- muntrar till att uppdatera ofta).

2. Anv¨anda data h¨amtat fr˚anGoogles tj¨anster i applikationer och system som presenterar geografi grafiskt med n˚agotannat ¨an Google Maps.

3. Distribuera och˚aterf¨ors¨alja n˚agonform av information f¨or kommersiellt bruk som kan relateras till Googles tj¨anster.

8 Just detta urval fr˚anGoogles anv¨andarvillkor (mer best¨amt punkt 1 ovan) presenterade ett problem, eftersom systemet skulle kr¨ava att kunna lagra geocodes persistent f¨or matchning mot interna system. Googles Terms of Service medf¨orde att systemet inte fick lagra platser f¨or en adress l¨angre ¨an 30 dagar. Detta betydde att cache:ade svar fr˚angoogle skulle rensas bort efter 30 dagar, men uppslagna platser som redan anv¨andes av systemet lagrades under en l¨angre tid p˚agrund av skillnaden mellan en plats och en adress.

I ¨ovrigt fanns det ¨aven best¨ammelser om att Googles tj¨anst f¨or geocoding/ reverse-geocoding inte till¨at fler ¨an 2.500 h¨amtningar per dag [13]. St¨orre applikationer som belastade Googletj¨ansten och ¨overskred denna siffra blev avst¨angda p˚abest¨amd tid, s˚avidaen ers¨attning inte arvoderades Google, vilket i st¨orsta m¨ojliga m˚anville undvikas. P˚agrund av skalan av den da- tam¨angd som systemet skulle hantera var denna aspekt inte f¨orsumbar, och en l¨osning d¨ar begr¨ansningen togs till h¨ansyn kr¨avdes.

3.2.2 Bing Maps Platform APIs Likt f¨or de best¨ammelser som fanns f¨or Google Maps APIs framst¨alldes pro- blem med att anv¨anda Bing Maps. Bing Maps villkor f¨or anv¨andning av tj¨ansten [14] beskriver:

• F¨orbud mot att kopiera, lagra, arkivera, eller skapa databaser med erh˚allendata, f¨orutom att geocodes f˚arlagras lokalt f¨or varje applika- tion (caching).

• F¨orbud mot att anv¨anda h¨amtade geocodes f¨orutom i samband med en Bing Map.

P˚agrund av dessa f¨orh˚allandenskulle ett system som exklusivt byggde p˚a Bing Maps Platform APIs inte kunna till¨ampa ett flexibelt f¨orfarande, likt hur det s˚agut med Googles motsvarighet. Skillnaden med Bing, trots det kommersiella omf˚angetav varum¨arket, mot Google Maps regler ¨ar dock att det inte finns en begr¨ansning f¨or hur stora m¨angder data som f˚arbeg¨aras per tidsenhet [6].

9 3.2.3 Yahoo! Maps API Yahoo! Maps [15] betraktades som en kandidat under ett tidigt skede. In- nan n˚agon form av efterforskning och testning av Yahoo!s tj¨anster hann ge- nomf¨oras uppt¨acktes dock att Yahoo! beslutat att st¨anga ner sin karttj¨anst [16]. F¨or ¨ovrigt hade Yahoo! Maps (innan dess att tj¨ansten st¨angdes ner) enbart st¨od f¨or uppslag mot gator och v¨agar, men inte f¨or adresser och hus- nummer.

3.2.4 MapQuest MapQuest ¨ar ett ramverk f¨or geografiska tj¨anster som ¨ar helt ¨oppet. Map- Quest gav olika valm¨ojligheter f¨or hur stort st¨od anv¨andare kunde f˚aoch hur mycket av funktionaliteten som skulle vara tillg¨anglig genom olika licensav- tal. De olika former av licensiering som framst¨alldes av MapQuest [17] var:

• ENTERPRISE EDITION (Licensed data)

• COMMUNITY EDITION (Licensed data)

• COMMUNITY EDITION (Open data)

Licenserna hade olika priss¨attningar och kravst¨allningar f¨or anv¨andning. Va- let f¨oll dock p˚adet API som MapQuest ger som ¨ar mer ¨oppet f¨or anv¨andning [18] (MapQuest Open). Detta alternativ innefattar funktionalitet f¨or bland annat: geocoding, reverse geocoding, kvalitetskoder som underl¨attar tr¨affs¨akerhetsbest¨ammelser och ¨ar dessutom helt gratis. MapQuest kr¨avde endast att deras tj¨anster gavs omn¨amnande i eventuella grafiska gr¨anssnitt som var implementerade med hj¨alp av deras tj¨anster. Vad g¨aller datam¨angd ans˚agMapQuest att det var l¨ampligt att informera (ge en varning) om att en utomst˚aendetj¨anst kunde komma att kr¨ava h¨og pre- standa, och d¨arf¨or g¨ora en ¨overrenskommelse med MapQuest. P˚asamma s¨att som anv¨andandet av Google Maps APIs kr¨avde en l¨osning d¨ar begr¨ansningar togs till h¨ansyn implementerades MapQuests tj¨anster med restriktioner f¨or att undvika f¨or stora m¨angder data¨overf¨oring.

10 3.2.5 Nominatim Nominatim [19] ¨ar en frist˚aendesamling tj¨anster vilka ligger som fundament f¨or b˚adeOpen Streetmap [20] och MapQuest Open Initiative [21] i form av att tillhandah˚allaOSM-data. I dessa tj¨anster ing˚arbland annat s¨okfunktion och geocoding. Nominatims utformning kan n¨armast liknas vid den som de enorma geogra- fiska databaser som ligger till grund f¨or bland andra Tele Atlas (TomTom) [4] och Navteq [22] har. S¨okfunktionerna som Nominatim erbjuder ¨ar ansenligt djupa [23], om ¨an inte fullt s˚atr¨affs¨akra som Googles.

Det enda kravet som st¨alldes f¨or anv¨andning av verktyget Nominatim [24] var att applikationen som till¨ampar tj¨ansten skulle identifieras. Det ¨ar egent- ligen bara ett s¨att f¨or Nominatim att se vilka som belastar tj¨ansten ansenligt mycket. Det positiva med detta var att det gick att ange kontaktinformation f¨or anv¨andaren som identifikation (email-adress t.ex), vilket betydde att Nomi- natim kunde kontakta anv¨andare (exempelvis systemutvecklingsavdelningar) genom att s¨anda mail om en applikation anstr¨anger tj¨ansten f¨or mycket. Det hj¨alper ocks˚atill att f¨orhindra ober¨aknelig IP-relegering i samspel med bru- kare; en mycket god egenskap.

3.3 Tillf¨orlitlighet av uppslag F¨or att kunna m¨ata hur pass tr¨affs¨aker en s¨okning hos en leverant¨or ¨ar m˚aste resultat fr˚anf¨orfr˚agningartolkas r¨att. Olika tj¨anster anv¨ander olika k¨allor f¨or sina databaser, vilka i sin tur skiljer sig i datam¨angd.

3.3.1 Google Google f˚argeografisk data fr˚anbland andra Tele Atlas, som ¨ar v¨arldens n¨ast st¨orsta akt¨orer p˚amarknaden f¨or geografiska informationssystem [25] (¨ovrig geografisk data ¨ar utforskad internt hos Google). Google har ¨overlag h¨ogst tr¨affs¨akerhet f¨or uppslag av adresser mot koordina- ter, och anger vilken tr¨affs¨akerhet varje svar har genom parametern location type [26].

11 3.3.2 Bing Eftersom Bings geografitj¨anst ¨ar en SOAP-webservice finns det datatyper i kontraktet som anger vilken s¨akerhetsgrad svaret har, vilket i sig underl¨attar implementationen, men ocks˚aintroducerar problematik vad g¨aller hur h¨og kontroll som ¨ar uppn˚aelig.Bing anv¨ander NavTeq [22] som databask¨alla.

3.3.3 MapQuest MapQuest h¨amtar data fr˚anOSM [27], vilket ¨ar en ¨oppen k¨alla f¨or geogra- fisk data. D¨arf¨or har MapQuests webservice varierande anvisningar [28] av tr¨affs¨akerheten p˚as¨okningar i form av en upps¨attning koder (se 4.3.3). F¨or att avg¨ora tr¨affs¨akerheten av ett svar som f˚asfr˚anen s¨okning kr¨avs det d¨arf¨or ett filter som tolkar koderna.

3.3.4 Nominatim Den riktligaste m¨angden av tr¨affs¨akerhetsangivelser hos de valda geocoding- tj¨ansterna f˚asav Nominatim [23]. I ett svar fr˚anNominatim finns inget distinkt v¨arde f¨or confidence eller qua- lity, utan ist¨allet ett KV-par som anger vilka typer av platser resultatet in- neh˚aller.Exempel p˚aett s˚adant KV-par ¨ar nyckeln ”waterway” med v¨ardet ”canal”, vilket f¨or den specifika uppgiften som systemet har ¨ar helt irrelevant. D¨arf¨or skulle det kr¨avas en smart funktion f¨or att s˚allafram ett tolkningsbart v¨arde.

12 4 Genomf¨orande

Detta kapitel beskriver genomf¨orandet, vilket bestod av att ta fram en ar- kitektur, som beskrivs i kapitel 4.2, och implementationen av geocoding i kapitel 4.3. Dessutom visas hur lagringen av positionsdata gjordes och en genomg˚angav anv¨andargr¨ansnittet i kapitel 4.5 och 4.6. Till sist visas vad som sl¨apptes i den planerade releasen i kapitel 4.7.

4.1 Tredjepartstj¨anster Ett antal grundl¨aggande tester (inte med mer ¨an ett tiotal adresser) gjordes f¨or att unders¨oka hur pass goda resultat de olika leverant¨orerna gav. Med go- da resultat menas att uppslagningar p˚aadresser har h¨og tr¨affs¨akerhet (helst s˚apass bra att t.o.m. antal trappor och d¨orr finns med som parametrar i svaren). Utifr˚andessa tester och vetskapen fr˚antidigare erfarenheter (se 3.2) beslutades att f¨oljande leverant¨orers tj¨anster skulle v¨aljas bort: Yahoo, CloudMade och OpenAddress.

4.1.1 Val av tredjepartsleverant¨orer Bland annat p˚agrund av att Yahoo!s tj¨anst skulle st¨angas ner och att massiv datalagring av koordinater h¨amtade fr˚anGoogle och Bing inte var till˚atet gjordes valet att anv¨anda:

MapQuest F¨or geocoding, fritt att lagra data

Nominatim F¨or geocoding, fritt att lagra data givet att kontaktinformation anges

Google F¨or geocoding och f¨or att integrera Google Maps i anv¨andargr¨anssnitt

Bing F¨or geocoding, dock enbart en test-version med reservation f¨or att s˚a sm˚aningomavsluta anv¨andandet av tj¨ansten

13 4.2 Arkitektur En analys genomf¨ordes f¨or att f¨ors¨oka hitta en s˚amodul¨ar l¨osning som m¨ojligt:

• I vilka befintliga system fanns de adresser som skulle hanteras? Hur skulle denna data h¨amtas?

• Hur pass omfattande skulle geografifunktionerna vara? Skulle det ut- vecklas ett ensamst˚aendesystem eller enbart fungera som en p˚abyggnad p˚aett existerande?

• I vilka anv¨andargr¨anssnitt skulle visuell presentation av kartor finnas?

Se ¨aven Arkitektur i bilagor.

4.2.1 Geocoding Service Geocoding-tj¨ansten var menad att vara en l¨oskopplad ”verktygsl˚ada”,obe- roende av intern data, som anropades i ett enda syfte; h¨amta (sl˚aupp) ko- ordinater f¨or en adress, om dessa ¨annu inte k¨andes till. Geocodingtj¨ansten implementerade en intern cache, som anv¨andes f¨or att returnera data utan att anropa externa leverant¨orer om s¨okningar hade gjorts sedan tidigare, f¨or att minimera antalet f¨orfr˚agningarsom st¨alldes till framf¨orallt Google.

4.2.2 Geofinding Service Till en b¨orjan implementrades en mellanhandstj¨anst, till f¨or att berika poster i interna system med koordinatdata, d¨ar dessa ¨annu inte fanns, och vidare- befordran av denna data till bland annat vyer.

4.2.3 Webbvy med modell En alternativ l¨osning till en ’hitta”-tj¨anst (4.2.2) var att l˚atamodellen f¨or anv¨andargr¨anssnittets vyer unds¨atta funktionalitet f¨or att hitta koordinater f¨or data som fanns i interna system, vilket hj¨alpte f¨or att minimera overhead. Modularitet gick till viss del f¨orlorad genom att att g¨ora denna implementa- tion.

14 4.2.4 DbSeeder F¨or att kunna f¨ora in geografisk data i befintliga system skrevs en simpel ”seeder” som tillsammans med geocoding-tj¨ansten kopplade platser till koor- dinater och lagrade det i en databas. P˚agrund av att geocoding-tj¨ansten be- gr¨ansade antalet f¨orfr˚agningar(baserat p˚ayttre leverant¨orers begr¨ansningar) med ett throttle sp¨arrades seeder, som i sin tur anv¨ande en backoff-funktion. I och med det k¨ordes seeder som ett ”natt-jobb”, som sakta men s¨akert ut¨okade intern data med platsinformation.

4.3 Geocodes fr˚anextern leverant¨or Processen att utf¨ora en f¨orfr˚aganf¨or att h¨amta koordinater f¨or en adress s˚ag mestadels likadan ut, oberoende av vilken tj¨anst som till¨ampades. Den stora skillnaden l˚agi hur svaret var utformat fr˚anrespektive extern tj¨anst. Me- toden som anv¨andes bestod av att anskaffa resultatlistor fr˚anflera tj¨anster; Nominatim, MapQuest, Google samt Bing (se 3.1), sedan j¨amf¨ora samtliga resultat med varandra f¨or att sist returnera det b¨asta m¨ojliga v¨ardet.

4.3.1 J¨amf¨orelse med viktade v¨arden Ponera att en lista av resultat f˚asav respektive extern leverant¨or. Google p˚ast˚arsig ha fem olika tr¨affar p˚as¨okningen, Bing tv˚a,Nominatim tre och MapQuest en. Hur kan man d˚ata reda p˚avilket resultat, ur varje lista, som st¨ammer b¨ast ¨overrens med s¨okningen? Och sedan vilket av dem (vilken leverant¨or) som har h¨ogst tr¨affs¨akerhet?

15 Resultaten f¨orbereds f¨or j¨amf¨oreslse genom att samlas till en enda lista. F¨or varje resultat i den enhentliga listan plockas latitud och longitud ut och omvandlas fr˚angrader till kartesiska v¨arden [29]:

Omvandla grader till radianer CLat = Latitud ∗ π/180 CLong = Longitud ∗ π/180

Transformera till kartesiska v¨arden x = cos(CLat) ∗ cos(CLong) y = cos(CLat) ∗ sin(CLong) z = sin(CLat)

Ta fram en viktad summa sum = (x + y + z) ∗ (±Confidence)

Varje kartesisk summa l¨aggs till i en total-variabel, som sedan anv¨ands f¨or att r¨akna ut centerpunkten: tot + tot + tot center = x y z , d¨ar n ¨ar antalet samlade resultat n Alla punktspecifika summor modifieras (f¨ors¨amras) allts˚autefter det confi- dence resultaten hade, d¨ar v¨arden som var mindre ¨an center spreds ut ned˚at beroende p˚ahur d˚aligt confidence var (se 4.3.3) och v¨arden st¨orre ¨an center spreds ut upp˚at.Resultat med tr¨affs¨akerhet ”NotFound” f¨orbis˚ags. Det v¨arde som sedan l˚agn¨armst center ans˚agsvara det mest tr¨affs¨akra resul- tatet och returnerades. Denna funktion f¨ors¨okte eliminera d˚aligah¨amtningar, framf¨orallt f¨or att inte l˚atas¨okningen hamna i fel land (d˚aconfidence var l˚agti s˚adant fall). Problem uppstod n¨ar samtliga resultat var i fel land, vilket d˚aoftast berodde p˚aatt s¨okstr¨angen var otillr¨acklig (till exempel att stad, ort och land saknades) eller felformulerad, och dessa gick i praktiken inte att f¨orb¨attra med en s˚adanh¨ar funktion.

16 4.3.2 Parsing Tj¨ansten Geocoding Service utnyttjade LINQ to XML [30] f¨or att plocka ut data fr˚ande svar som genererades av leverant¨orstj¨ansterna. F¨orfarandet bestod i att:

1. Utforma en f¨orfr˚aganutifr˚andet objekt som klienten beg¨ar:

• Dela upp adress, stad, land och postnummer i str¨angar • F¨orena varje delstr¨ang (och kontrollera s˚aatt formatet blir r¨att ¨aven om n˚agonbest˚andsdelinte finns) i en query-str¨ang • Generera ett WebRequest-objekt och ta emot ett WebResponse

2. Filtrera ut vilket confidence svaret har (se 4.3.3)

3. Ta ut satsdelarna ur resultatet:

• Generera en upps¨attning klasser som ¨ar unika f¨or varje leverant¨or (GoogleLocationDescription, NominatimLocationDescription, etc) • H¨amta varje specifik komponent ur varje del av resultatet till ob- jekten som skall returneras

4.3.3 Confidence-filter Som beskrivet i 3.3 kr¨avdes en funktion f¨or att s˚allafram tr¨affs¨akerheten av varje s¨okresultat. Confidence f¨or ett resultat delas upp i:

• Exact - tr¨aff p˚aangivet husnummer • Good - exempelvis r¨att gatuadress, men inte ett specifikt husnummer • Approx - tr¨aff p˚aomr˚adesom t.ex v¨ag, stad, kommun eller l¨an • Bad - tr¨aff p˚alandsniv˚a • NotFound - inga tr¨affar (mycket d˚aligtresultat)

17 Urskilja tr¨affs¨akerhet fr˚anGoogle: Den mest koncisa av de tre Representational State Transfer (REST, ett s¨att att exponera en Webservice)-baserade externa tj¨ansterna; v¨ardet f¨or confi- dence i ett svar fr˚anGoogle ¨ar ”antingen/eller”. Parametern location type ¨ar det som anv¨ands f¨or att avg¨ora tr¨affs¨akerheten. Exempel p˚adessa ¨ar:

• ROOFTOP

• RANGE INTERPOLATED

• APPROXIMATE

ROOFTOP anger ett exakt husnummer, ibland till och med vilken v˚aningi h¨oghus adressen ligger p˚a. RANGE INTERPOLATED betyder ofta att svaret inte ¨ar exakt p˚ahusnum- mer, utan snarare att resultatet st¨ammer ¨overrens p˚agata eller kvarter. APPROXIMATE betyder i sin tur att det ¨ar ett relativt os¨akert svar, d¨ar en- bart stad, kommun eller till och med land ¨ar det enda som st¨ammer ¨overrens.

Resultattypen som anges i svar fr˚anGoogle g¨or det mycket enkelt att avg¨ora om man med s¨akerhet kan s¨aga var en adress finns, eller om det enbart ¨ar t.ex ett generellt omr˚adesom returneras.

Urskilja tr¨affs¨akerhet fr˚anBing: Eftersom Bing anropas genom SOAP kr¨avdes inget filter d¨ar, d˚a confidence angavs som en befintlig datatyp i CLR.

Urskilja tr¨affs¨akerhet fr˚anMapQuest: MapQuest anger hur h¨og kvalitet en geocode har med en kod som delas upp i granularity och confidence. Hj¨alpmetoden som h¨amtar det slutliga v¨ardet switchar mot dessa tv˚adelkoder. Exempel: Koden L1AAA anger med granularity L1 att resultatet ¨ar en adress. Confi- dence AAA anger med f¨orsta tecknet (s¨akerhet p˚agatuniv˚a),andra tecknet (s¨akerhet p˚aomr˚adesniv˚a)samt tredje tecknet (s¨akerhet p˚apostnummer) att resultatet ¨ar av mycket god kvalitet. Confidence ¨ar antingen A, B eller C. M¨ark v¨al att detta confidence inte ¨ar en analog till ConfidenceLevel som ¨ar den enum som anv¨ands i geocoding-tj¨anstens datakontrakt.

18 Urskilja tr¨affs¨akerhet fr˚anNominatim: Nominatim presenterar en enorm m¨angd identifikationer av tr¨affs¨akerhet, som beskrivet i 3.3.4. Hj¨alpmetoden som filtrerar confidence ur ett svar fr˚an Nominatim ¨ar ett massivt textstycke som behandlar alla t¨ankbara platstyper som kan f˚as,och f¨ors¨oker tolka ett v¨arde utifr˚andet. Exempel: Key: highway och value: residential anger en h¨og grad av tr¨affs¨akerhet, och anses d¨arf¨or vara ”Exact”. Hade value d¨aremot varit road anses det vara ett s¨amre resultat med v¨ardet ”Approx”.

4.3.4 Cache En cache implementerades i form av en Microsoft SQL-databas. Orsaken till varf¨or geocodingtj¨ansten anv¨ande en cache f¨or s¨okningar var f¨or att mini- mera antalet uppslag som gjordes mot externa leverant¨orer. Alla nya unika adresss¨okningar sparades med kolumnerna ”SearchString”, ”SearchDate” och resultatf¨alt f¨or bland annat koordinater. Om en s¨okning gjordes unders¨oktes f¨orst om det redan fanns resultat i cachedatabasen som kunde returneras.

Ett SQL-jobb skrevs f¨or att hantera f¨alt d¨ar antalet dagar sedan s¨okningar genomf¨ordes var mer ¨an 30 dagar, och i s˚adant fall rensades dessa ur cache- databasen.

F¨or att s¨akerst¨alla att inga f¨or˚aldradegeocodes angavs som aktuella gjor- des dessutom en kontroll p˚acache:ade resultatdatum vid uppslag, och en uppdatering av den befintliga s¨okningen, med eventuella nya resultatf¨alt la- des till i cachedatabasen. F¨oljande pseudokod beskriver processen: if(search has been made) { get existing result from cache if(days passed since this search was made is less than 30) return result else(run a new lookup and insert new result into cache) return new result } En annan anledning till att en cache implementerades var att bibeh˚allaen- lighet med anv¨andningskraven fr˚anGoogle.

19 4.4 Lagring av positionsdata Data lagrades i en MSSQL Server-databas, prim¨art med datatypen SqlGeo- graphy [31] f¨or bin¨ar positionsdata. Denna data konverteras sedan till ett DbGeography-objekt [32] f¨or att enklare kunna extrahera positionsdata fr˚an objektet. Databasdiagrammet f¨or lagringen av data hittas i Figur 1.

Figur 1: Databasdiagram f¨or positionsdata

Valet av att anv¨anda SqlGeography ist¨allet f¨or att spara latitud och longitud som flyttal gav en stor f¨ordel vid n¨arhetsber¨akningar (se 2.3). F¨or att l¨asa positionsdata fr˚andatabasen nyttjades C#-klassen SqlData- Reader [33]. Valet f¨oll p˚avanliga SQL-queries ist¨allet f¨or en ORM, som t.ex Entity Framework [34], p˚agrund av att stora m¨angder data skulle skickas fr˚anen WCF-tj¨anst vilket gjorde att det kr¨avdes h¨og kontroll ¨over storle- ken av den data som h¨amtades fr˚andatabasen och skickades vidare till vyn. Denna funkionalitet lades till en b¨orjan i en egen WCF-tj¨anst f¨or att abstra- hera bort databaslogiken fr˚anbusiness-object-logiken, men efter stresstester p˚afannson¨odig overhead i att ha den strukturen. P˚agrund av detta om- strukturerades systemet s˚aatt data h¨amtades och uppdaterades direkt mot aktuell WCF-tj¨anst.

Ett problem som st¨ottes p˚avar att det inte verkade finnas n˚agots¨att att direkt konvertera mellan ett SqlGeography-objekt och ett DbGeography- objekt. En genv¨ag f¨or att komma runt detta var att st¨alla en query mot databasen s˚apositionsdatan returneras i en textstr¨ang som sedan g˚aratt konverteras till ett DbGeography-objekt enligt f¨oljande exempel:

20 var sql = @"SELECT Location.STAsText() AS LocationString FROM dbo.Sites"; using(var cmd = new SqlCommand(sql, connectionString)) { var reader = cmd.ExecuteReader(); reader.Read(); DbGeography location = DbGeography.FromText(reader["LocationString"]); } Men precis som det fanns en funktion STAsText()fanns det funktioner f¨or att h¨amta latitud och longitud direkt fr˚andatabasen. Koden s˚agd˚aut som f¨oljer: var sql = @"SELECT Location.Lat() AS Latitude FROM dbo.Sites"; using(var cmd = new SqlCommand(sql, connectionString)) { var reader = cmd.ExecuteReader(); reader.Read(); double? latitude = reader["Latitude"] as double?; } Denna skillnad gjorde att en uppgradering till .NET Framework 4.5 inte blev n¨odv¨andig. Dock kr¨avdes fortfarande SQL Server 2012 f¨or att st¨odja detta p˚adatabassidan.

4.5 WPF WPF, Windows Presentation Foundation, ¨ar Microsofts ramverk som ¨ar till f¨or att skriva anv¨andargr¨anssnitt. XAML (extensible application markup lan- guage) anv¨ands f¨or att uforma applikationer. F¨or att kunna implementera en WPF-kontroll som har i uppgift att hantera kartor skulle det kr¨avas att den antingen ritar ut kartor med hj¨alp av tiles [35] eller enbart renderar en webbkarta fr˚ant.ex Google. Problemet med att anv¨anda tiles var att det mestadels inte ¨ar gratis att anv¨anda dem. Funktionaliteten i de vyer som sy- stemet skulle innefatta hade heller inte behovet av att presenteras med hj¨alp av tiles (framf¨orallt vad g¨allde ¨overvakning). Det grafiska gr¨anssnittet f¨or systemet hade inte n˚attpotentialen med, eller utnyttjat MVVM-paradigmen fullt ut, och att anv¨anda en WPF-kontroll hade blivit ¨overfl¨odigt. Modellen i ASP.NET MVC 4 (se 4.6) m¨otte d¨aremot de enkla krav som fanns f¨or anv¨andargr¨anssnittet. D¨arf¨or gjordes valet att inte utveckla n˚agot anv¨andargr¨anssnitt i WPF.

21 4.6 Webbvyer Stationer och kundplatser som f˚attsina geografiska positioner uppslagna vi- sades p˚aen karta i en egen hemsida. F¨or att generera hemsidan anv¨andes ASP.NET MVC 4 (Ett ramverk f¨or att bygga 3-lagers webapplikationer). Denna applikation fick i uppgift att h¨amta data fr˚ande WCF-tj¨anster som fanns och rita detta till en karta. Klientsidan fick ¨aven m¨ojlighet att anv¨anda AJAX f¨or att h¨amta data utan att beh¨ova ladda om sidan.

4.6.1 Javascriptmodulen geo.js P˚agrund av att m˚angaav vyerna delade mycket av initialiseringsprocessen och filtrering av vilka f¨orbindelser och noder som skulle visas p˚akartan togs en javascriptmodul fram som sk¨otte detta arbete. Modulen ansvarade f¨or att h˚allakoll p˚ah¨amtade kundplatser(site), no- der och kopplingar samt kunna visa ¨overvakningsinformation f¨or dessa asyn- kront. Den ansvarade ¨aven f¨or att dynamiskt uppdatera data i databasen n¨ar ¨andringar gjordes av anv¨andaren i kartvyn.

Exempel p˚aatt rita ut en kundplats(site”) med id 1 p˚aen karta

Liknande funktionalitet lades ¨aven till f¨or stationer. P˚agrund av att all data f¨or en site (eller kundplats) skickades med till modulen ansvarade mo- dulen ¨aven f¨or att skapa informationsrutor som ¨oppnades n¨ar en mark¨or klickades p˚a.

Ett problem som uppstod var att n¨ar m˚angamark¨orer skulle visas p˚akar- tan (¨over 10,000 mark¨orer) blev kartvyn oresponsiv och ikonerna ¨overlappade varandra. F¨or att p˚aett enkelt s¨att g¨ora kartan mer informativ och respon- siv anv¨andes Googles mark¨orklustrare [36] som klustrar ihop mark¨orer som ¨overlappar varandra.

22 Mark¨orklustraren modifierades f¨or att anv¨anda ¨overvakningsdata och f¨argade ikoner f¨or kluster f¨or att f¨orenkla ¨overblick vid avbrott p˚af¨orbindelser. I f¨oljande kod visas den del av klusterkalkylatorn som bed¨ommer vilken ikon som skall v¨aljas till ett kluster.

module.clustererCalculator = function(markers, numStyles) { index = Math.min(nodes_down_count, numStyles); return { text: nodes_count + " - " + sites_count, index: style_up //style_up / style_mixed / style_down }; };

Funktionen returnerar ett JSON-objekt med texten som skall visas, samt ett index f¨or vilken ikon som ska anv¨andas. Indexet anger positionen f¨or en ikon i listan av ikoner som klustraren skapas med.

4.6.2 Overvakning¨ Ett av ¨onskem˚alensom fanns f¨or kartan var att den skulle kunna visa realtidsdata med ¨overvakningsstatus f¨or stationer och kundplatser. F¨or sta- tionerna och f¨orbindelserna mellan dessa valdes det att klienten fick pol- la ¨overvakningen eftersom datam¨angden inte kr¨avde n˚agonoptimering. F¨or kundplatserna var detta dock inte m¨ojligt i samma m˚anp˚agrund av antalet och att varje plats teoretiskt sett kunde ha flera f¨orbindelser. F¨or kundplat- ser h¨amtades d¨arf¨or ist¨allet ¨overvakningsdata n¨ar informationsbubblan f¨or en kundplats visades. Detta gjorde att f¨orbindelser mellan kundplatser in- te kunde visa ¨overvakning, men detta ans˚agsinte lika viktigt som att visa ¨overvakningsdata f¨or stationer.

Pollningen skedde med hj¨alp av javascripts inbyggda funktion setInterval. Denna funktion tar emot en annan funktion som parameter samt ett inter- vall i millisekunder. Uppdateringen av ¨overvakningsdata gav dock ett pro- blem med mark¨orklustraren som inte uppdateras automatiskt f¨or att byta ikon. L¨osningen till detta blev att l˚ataklustraren rita om sig sj¨alv n¨ar alla efterfr˚agningarefter ¨overvakningsdata f¨or ett interval hade kommit tillbaka. Med hj¨alp av JQuery ser det ut som exemplet nedan.

23 var nodes_requests = [] $.each(nodes, function() { node_requests.push(/* ¨overvakningsf¨orfr˚agan*/); }); $.when.apply(undefined, node_requests).then( function() { if (module.maps[mapIndex].clusterer) module.maps[mapIndex].clusterer.repaint(); } );

Denna kod sparar varje efterfr˚agantill servern i en array och anv¨ander sedan JQuerys funktion ’when’ f¨or att registrera en callback som exekveras n¨ar alla efterfr˚agningar i arrayen har f˚attsvar fr˚anservern.

4.7 Publicering Som avslutande moment i arbetet genomf¨ordes en ¨overgripande release. Samt- liga delar av projektet sl¨apptes samtidigt med s˚amycket f¨ardig funktionalitet som m¨ojligt.

4.7.1 Beslut om geocoding I samband med att de geografiska l¨osningarna sl¨apptes togs beslutet att en av de yttre leverant¨orerna av geocodes inte l¨angre skulle anv¨andas. Bing hade n¨amligen under arbetets g˚anganv¨ants med en test-nyckel, som endast var aktiv i 90 dagar. I och med det avgjorde man att Bing, som i ¨ovrigt heller inte gav exceptionellt goda s¨okresultat i j¨amf¨orelse med ¨ovriga leverant¨orer, inte l¨angre skulle anv¨andas. Dessutom utf¨ordes sm˚amodifikationer p˚a ¨ovriga geocodeh¨amtare (fr¨amst f¨or Nominatim) g¨allande kontaktinformation. I och med det var de kontaktupp- gifter som gavs till Nominatim hela systemutvecklingsavdelningen p˚aDGC.

24 4.7.2 Tillkomna st¨od med tillh¨orande licenser Eftersom valet gjordes att anv¨anda Google Earth som GIS (Geographic In- formation System)-utforskare i syftet att underl¨atta n¨atplanering och dylikt gjordes en extra unders¨okning av licenserna [37] f¨or anv¨andning av applika- tionen. I dessa beskrivs enbart restriktioner f¨or ˚aterf¨ors¨aljning i t.ex. kom- mersiella syften. Ingenting dock som bromsar anv¨andandet av Google Earth som ett internt st¨odverktyg hos DGC.

4.7.3 Verktyg De st¨odverktyg som inkluderades n¨ar systemet publicerades var:

Overvakningsverktyg¨ Ett webbgr¨anssnitt baserat p˚aGoogle Maps som visade livedata f¨or ¨overvakningsstatus i stamn¨atet

KML-generator En webbsida med inst¨allningsval f¨or att kunna generera kartn˚alsutritning av n¨atet baserat p˚abland annat accesstyper i Google Earth med en KMZ-fil (paketerad KML med egenvalda ikoner och bilder)

Integrerad systemvy Ett integrerat gr¨anssnitt i ett befintligt system

25 5 Interna ¨onskem˚al

Efter halva projektets g˚anggenomf¨ordes en ¨onskem˚alsunders¨okning bland de tillt¨ankta anv¨andarna hos DGC. Detta ledde till att ett antal troliga anv¨andningsomr˚adentogs fram. Dessa delades upp i anv¨andningsfall som diskuterades och utformades tillsammans med potentiella anv¨andare. Detta gav mer klarhet i hur information skulle presenteras och anv¨andargr¨anssnitt utformas.

5.1 Kundportal I den kundportal som DGC tillhandah¨oll sina kunder ville man presentera l¨ankstatus och kunders VAN (logiska f¨orbindelser) p˚aen karta. Denna vy skulle ha ett tunnare och mer enkelt gr¨anssnitt med f¨argkodad status p˚a l¨ankar. Man ans˚agatt detta skulle underl¨atta f¨or kunder att se huruvida en l¨ank faktiskt havererat eller inte, och ge en snygg presentation av vad kunden k¨oper.

5.2 Vy med huskroppar Genom att anv¨anda grafiken i en fullfj¨adrad GIS-utforskare som t.ex Google Earth kan man se huskroppar och gator, p˚aett ¨annu mer detaljerat s¨att ¨an i de satellitvyer som finns i vanliga kartgranssnitt. Genom att anv¨anda detta kunde man se kabeldragningar mellan hus, utifr˚ande adresser som s¨oktes.

26 6 Resultat

De huvudsakliga m˚alenmed projektet var att med hj¨alp av en webservice kunna sl˚aupp geocodes mot externa leverant¨orer, rita ut accessn¨atet i ett kartgr¨anssnitt och att med hj¨alp av framtagna verktyg kunna st¨odja order- processer genom att visa n¨arhet mellan befintliga kundf¨orbindelser. Den enda delen av systemet som var m˚alsattmen f¨orbis˚agsvar WPF- till¨ampningen, som beslutades vara ¨overfl¨odig.

6.1 Geocode service Den f¨orsta delen, vilken l˚agsom st¨ottepelare f¨or ¨ovrig funktionalitet i syste- met, som framtogs var WCF-tj¨ansten Geocode service. Med den g˚ardet att sl˚aupp adresser till koordinater med h¨og tr¨affs¨akerhet tack vare att den f˚ar data fr˚anett flertal yttre leverant¨orer, j¨amf¨or resultat och skickar tillbaka det h¨ogst trov¨ardiga svaret f¨or en s¨okning. Tj¨ansten implementerade ¨aven en cache, d¨ar s¨okningar sparades f¨or att till˚ataatt gamla uppslagningar kunde h¨amtas direkt fr˚antj¨anstens lagrade historik, ist¨allet f¨or att varje g˚ang en uppslagning g¨ors skicka f¨orfr˚agningartill leverant¨orer.

Tj¨ansten hade ¨aven en intern begr¨ansning, throttle, som var till f¨or att f¨ors¨akra att anv¨andandet av den inte ¨overskred de begr¨ansningar som externa leve- rant¨orer framst¨allde. Detta implementerades i form av ett serialiserat objekt som hade en tidsst¨ampel och en ”request-counter”. Om r¨aknaren ¨overskred 2000 lade sig tj¨ansten i v¨antel¨age tills dess att det nuvvarande dygnet pas- serat, och d˚a˚aterst¨alldes r¨aknaren till 0.

6.2 Anv¨andargr¨anssnitt i form av kartor Anv¨andargr¨anssnitten som utvecklades f¨or systemet hade i syfte att rita ut kartor med tillh¨orande information f¨or de platser i DGC:s n¨at som hade geocodes. I 6.2.1 beskrivs vad ¨overvakningsverktyget hade f¨or anv¨andningsomr˚ade, i 6.2.2 beskrivs vad som implementerades i befintliga system och slutligen i 6.2.3 ˚atergeshur Google Earth anv¨andes f¨or att st¨odja n¨atplanering.

27 6.2.1 Overvakningsvy¨ I en av webbvyerna som implementerades gick det att se realtidsdata f¨or ¨overvakning i DGC:s n¨at. D¨ar ritades f¨argkodade f¨orbindelser ut mellan sta- tioner i stamn¨atet f¨or att kunna se om l¨ankar var uppe (gr¨on), nere (r¨od) eller av n˚agonanledning saknade status (gr˚a).Javascriptmodulen som ansvarade f¨or kartgr¨anssnittet i ¨overvakningsvyn uppdaterade kartan i intervall om tre minuter, f¨or att minimera svarstiden i gr¨anssnittet. Overvakningsverktyget¨ var en av de delar i systemet som anv¨ande sig av de geocodes som h¨amtades fr˚anGeocode service f¨or att rita ut platsmarkeringar f¨or stationerna p˚aen Sverigekarta.

6.2.2 Kundvy I ett av de befintliga interna systemen hos DGC implementerades en vy f¨or att kunna se kundplatser p˚aen karta. I denna vy gavs funktionalitet f¨or att kunna se om n¨arliggande kundplatser hade fiberf¨orbindelser. Detta verktyg gav st¨od i framf¨orallt orderprocesser, genom att visa om fiberf¨orbindelser hos befintliga kunder potentiellt kunde delas till nya kunder. I kartvyn f¨or kundplatser gick det ¨aven att se vilken stamn¨atsnod kundplatser var kopplade till. Kundvyn kopplades samman med det befintliga systemet i form av en WinForms Webbrowser i gr¨anssnittet.

6.2.3 KML i Google Earth KML-generering med hj¨alp av LINQ to XML gav st¨od f¨or att rita ut ett urval av kundplatser, med tillh¨orande linjer f¨or att visa kopplingar mellan dem och stationer i stamn¨atet. KML-filerna gick att ¨oppna i Google Earth och gav en ¨overblicksbild av DGC:s n¨at. I Google Earth gick det att bl¨addra igenom mappar med sorterade kundplatser, med tillh¨orande f¨orbindelser, och statio- ner. Genom att dubbelklicka p˚aplatser och stationer i katalogerna f¨ardades utforskarens gr¨anssnitt ¨over Sverigekartan och centrerade sig p˚aden plats som hade valts. Med hj¨alp av den funktionalitet som finns i Google Earth kunde man se huskroppar och kabeldragningar med ett verklighetstroget per- spektiv, vilket gav st¨od b˚adef¨or att se m¨ojliga fibersplittar i orderprocesser, och allm¨an n¨atplanering.

28 6.3 Enhetstestning och dokumentation I projektet anv¨andes TeamCity (TC) [38] f¨or CI (Continuous Integration) och som byggserver. Med hj¨alp av de verktyg som finns i TC kunde mycket av den kod som skrevs kvalitetss¨akras och redundanta publika metoder och dylikt st¨adas bort. NUnit [39] anv¨andes f¨or att enhetstesta klasser och metoder vilket gjorde systemet enklare att underh˚allaoch vidareutveckla. Samtliga delar av systemet dokumenterades b˚adei form av kommentarer i kod och systemdokumentation i interna verktyg.

6.4 Uppfyllande av m˚alen Enligt de m˚alsom i b¨orjan sattes upp f¨or projektet genomf¨ordes f¨oljande:

• En webtj¨anst (Geocode Service) togs fram som anv¨ande flera olika da- tak¨allor f¨or att sl˚aupp adresser till positioner som kunde ritas ut p˚a en karta.

• Positionsdata lagrades i en databas med m¨ojlighet att logga ¨andringar av positionsdata samt visa om adressen ¨andrats efter att en uppslagning hade gjorts.

• Med hj¨alp av datatypen SqlGeography gavs det m¨ojligthet att hitta n¨arliggande platser direkt i databaslagret.

• En intern unders¨okning utf¨ordes f¨or att samla ihop anv¨andarfall.

• En webapplikation togs fram f¨or att presentera data i olika vyer.

• WPF-kontrollen ans˚ags ¨overfl¨odig och framst¨alldes d¨arf¨or inte.

• Vyerna i webapplikationen som togs fram visades i andra system med hj¨alp av WebBrowser-kontrollen i C# WinForms.

De vyer som implementerades anv¨ander sig av den grundl¨aggande funk- tionalitet som i b¨orjan av projektet togs fram, och till˚ateranv¨andare att bland annat se individuella kundplatser p˚aen karta. Se ¨aven 6.1 och 6.2.

29 7 Slutsatser

Geocoding ¨ar f¨orh˚allandevissimpelt att implementera, beroende p˚a ¨onskem˚al om tr¨affs¨akerhet, datam¨angd och s¨akerhet. Att skriva ett program som h¨amtar geocodes fr˚anen leverant¨or skulle f¨or en nyb¨orjare i t.ex. C# g˚afort, men n¨ar det kommer till att skriva cachefunktionalitet och tr¨affs¨akerhetskrav fr˚an s¨okningar blir implementationen snabbt mer komplex. Karttill¨ampningar som i sin tur anv¨ander sig av koordinater som h¨amtas fr˚an en geocoder skrivs med hj¨alp av t.ex. ett javascript-bibliotek.

I projektet utvecklades en webservice i form av en WCF-tj¨anst som fun- gerade som uppslagsverk f¨or adresser, och svarade med koordinater. De vyer och ¨ovriga delar av systemet som tillkom anv¨ande sig i sin tur av koordina- terna som h¨amtades f¨or att rita ut platser i anv¨andargr¨anssnitt, och hade funktionalitet f¨or att visa n¨arhet mellan platser och ¨overvakningsstatus f¨or dem. Vyerna skrevs i ASP.NET MVC 4 och implementerade kartor med hj¨alp av javascript-bibliotek.

De geografiska till¨ampningarna som utvecklades och publicerades i DGC:s st¨odsystem gav en bra grund f¨or att hj¨alpa DGC att visualisera sitt n¨at. KML anv¨andes f¨or detta ¨andam˚altill att rita DGC:s n¨at i Google Earth. Systemet som framtogs f¨orenklade ¨aven det dagliga arbetet i b˚adeorderpro- cessen och fels¨okning av f¨orbindelser genom ett ¨overvakningsverktyg och en geografisk kundvy i interna system.

Systemets alla delar dokumenterades och enhetstestades f¨or att ge m¨ojlighet till vidareutveckling och underh˚all.

30 8 Rekommendationer

Fr˚anunders¨okningen som gjordes kom det fram att det ¨aven var ¨onskv¨art att f˚afram brandbreddsutnyttjande f¨or f¨orbindelser. Detta skulle ¨oppna upp f¨or att kunna se geografiska problemomr˚adenoch eventuella flaskhalsar p˚a ett mer ¨oversk˚adligts¨att. Detta f¨oll dock bort p˚agrund av tidsbrist, men ¨ar en stark rekommendation f¨or framtida implementation.

Innan implementeringen av vyerna i kundportalen rekommenderas det ocks˚a att ut¨oka ˚atkomsts¨akerheten f¨or dessa vyer eftersom de inneh˚allerl¨ankar och data som ¨ar menade att f¨orbli interna. Till exempel m¨ojligheten till att g¨ora nya uppslagningar och ¨andra data i databaserna.

En sista rekommendation f¨or att avhj¨alpa avsaknaden av kompilator f¨or ja- vascript skulle vara att skriva om javascript-modulen geo.js som togs fram till att anv¨anda sig av TypeScript ist¨allet. Detta skulle underl¨atta fels¨okningen av projektet samt ge en extra hj¨alp att f˚angaupp fel som annars l¨att missas n¨ar javascript ¨ar med i bilden.

31 K¨allf¨orteckning Referenser

[1] Lantm¨ateriet, ”Geodesi”, http://www.lantmateriet.se/Kartor-och-geografisk-information/ GPS-och-geodetisk-matning/Om-geodesi/ [Senast bes¨okt 18 april 2013.]

[2] Nationalencyklopedin, ”Geodesi”, http://www.ne.se/geodesi [Senast bes¨okt 18 april 2013.]

[3] Fr˚anWikipedia: ”Geografiska Koordinatsystem”, 10 april 2013, http://sv.wikipedia.org/wiki/Geografiska koordinatsystem [Senast bes¨okt 26 april 2013.]

[4] Jeremy Bradley, CNN, ”Mapping the world, one street at a time”, 12 au- gusti 2009, http://edition.cnn.com/2009/TECH/08/12/digital. mapping/index.html [Senast bes¨okt 12 april 2013.]

[5] Microsoft, ”Bing Data Suppliers”, http://windows.microsoft.com/ en-us/windows-live/about-bing-data-suppliers [Senast bes¨okt 6 maj 2013.]

[6] GeoCoder Pro, ”Geocoding services”, http://www.geocoderpro.com/en/resources/ geocoding-service/#accuracy [Senast bes¨okt 12 april 2013.]

[7] Microsoft, ”.NET Framework 4.5”, http://msdn.microsoft.com/ en-us/library/vstudio/w0x726c2.aspx [Senast bes¨okt 28 maj 2013.]

[8] Josie Wernecke, informIT, ”A Quick Tour of KML: Geographic Visuali- zation for the Web”, 14 september 2008, http://www.informit.com/ articles/article.aspx?p=1276353 [Senast bes¨okt 22 april 2013.]

32 [9] Open Geospatial Consortium, ”KML”, http://www.opengeospatial.org/standards/kml/ [Senast bes¨okt 22 april 2013.]

[10] Neil Sweeney, Fubra, ”Google Maps Free Alternatives”, 24 no- vember 2011, http://www.fubra.com/blog/2011/11/24/ google-maps-free-alternatives/ [Senast bes¨okt 29 maj 2013.]

[11] Adam DuVander, Programmable Web, ”7 Free Geocoding APIs”, 21 juni 2012, http://blog.programmableweb.com/2012/06/21/ 7-free-geocoding-apis-google-bing-yahoo-and-mapquest/ [Senast bes¨okt 18 maj 2013.]

[12] Google, ”Maps/Earth APIs Terms of Service”, 10 maj 2013, https://developers.google.com/maps/terms [Senast bes¨okt 22 maj 2013.]

[13] Google, ”Maps/Earth APIs Terms of Service FAQ”, 15 maj 2013, https://developers.google.com/maps/faq#tos [Senast bes¨okt 22 maj 2013.]

[14] Microsoft, ”Microsoft R BingTM Maps Platform APIs’ Terms Of Use”, april 2013, http://www.microsoft.com/maps/product/ terms.html [Senast bes¨okt 19 mars 2013.]

[15] Yahoo! ”Yahoo! Maps API Terms of Use”, 3 maj 2008, http://info.yahoo.com/legal/us/yahoo/maps/mapsapi/ mapsapi-2141.html [Senast bes¨okt 19 mars 2013.]

[16] Yahoo! ”Yahoo! Maps API developer network’, http://developer.yahoo.com/maps/ [Senast bes¨okt 29 mars 2013.]

[17] MapQuest, ”Licensing and Terms Overview”, 2012, http://developer.mapquest.com/web/tools/ getting-started/terms-overview [Senast bes¨okt 12 april 2013.]

33 [18] MapQuest Developers, ”MapQuest Open Geocoding API Web service”, http://developer.mapquest.com/web/products/open/ geocoding-service [Senast bes¨okt 29 maj 2013.]

[19] Open Streetmap, ”Wiki: Nominatim”, 18 maj 2013, http://wiki.openstreetmap.org/wiki/Nominatim [Senast bes¨okt 22 maj 2013.]

[20] OpenStreetMap Foundation, ”Main Page”, 27 november 2012, http://wiki.osmfoundation.org/wiki/Main Page [Senast bes¨okt 29 mars 2013.]

[21] Open Streetmap, ”Wiki: MapQuest Open Initiative”, 19 april 2013, http://wiki.openstreetmap.org/wiki/MapQuest [Senast bes¨okt 22 maj 2013.]

[22] NavTeq, ”What We Do”, 2012, http://www.navteq.com/company what we do.htm [Senast bes¨okt 12 april 2013.]

[23] Open Streetmap, ”Wiki: Nominatim Special Phrases”, 14 juni 2012, http://wiki.openstreetmap.org/wiki/Nominatim/Special Phrases/SV [Senast bes¨okt 12 april 2013.]

[24] Open Streetmap, ”Wiki: Nominatim Usage Policy”, 15 april 2013, http://wiki.openstreetmap.org/wiki/Nominatim usage policy [Senast bes¨okt 22 maj 2013.]

[25] Marcel van de Hoef & Joram Kanner, Bloomberg, ”TomTom Agrees to Acquire Tele Atlas”, 23 juli 2007, http://www.bloomberg.com/ apps/news?pid=newsarchive&sid=agT1Po33faG4&refer= home [Senast bes¨okt 12 april 2013.]

[26] Google, ”The Google Geocoding API”, 13 februari 2013, https://developers.google.com/maps/ documentation/geocoding/#Results [Senast bes¨okt 12 april 2013.]

34 [27] Open Streetmap, ”Open Streemap Database”, 17 september 2012, http://wiki.openstreetmap.org/wiki/Database [Senast bes¨okt 18 april 2013.]

[28] MapQuest Developers, ”Geocode Quality Code Details”, http://www.mapquestapi.com/geocoding/ geocodequality.html [Senast bes¨okt 12 april 2013.]

[29] von Malmborg, Helena (19 juni 2006), Lantm¨ateriet. Rapportserie: Geodesi och Geografiska informationssystem, ”J¨amf¨orelse av Epos och n¨atverks-DGPS” blad 8-9, kapitel 2. http://www.lantmateriet.se/Global/Kartor%20och% 20geografisk%20information/GPS%20och%20m%C3% A4tning/Geodesi/Rapporter publikationer/Rapporter/ LMV-Rapport 2006 5.pdf

[30] MSDN, ”LINQ To XML”, 2 augusti 2012, http://msdn.microsoft.com/en-us/library/bb387098.aspx [Senast bes¨okt 15 april 2013.]

[31] MSDN, ”SqlGeography Class”, http://msdn.microsoft.com/en-us/ library/microsoft.sqlserver.types.sqlgeography.aspx [Senast bes¨okt 10 maj 2013.]

[32] MSDN, ”DbGeography Class”, http://msdn.microsoft.com/ SV-SE/library/system.data.spatial.dbgeography.aspx [Senast bes¨okt 10 maj 2013.]

[33] MSDN, ”SqlDataReader Class”, http://msdn.microsoft.com/ en-us/library/system.data.sqlclient.sqldatareader.aspx [Senaste bes¨okt 10 maj 2013.]

[34] Microsoft, ”Entity Framework”, http://msdn.microsoft.com/ en-us/data/ef.aspx [Senast bes¨okt 10 maj 2013.]

[35] Open Streetmap, ”Wiki: Tiles”, 18 april 2013, http://wiki.openstreetmap.org/wiki/Tiles [Senast bes¨okt 13 maj 2013.]

35 [36] Google Maps Utility, ”MarkerClustererPlus for Google Maps V3”, http://google-maps-utility-library-v3.googlecode.com/svn/ trunk/markerclustererplus/docs/reference.html [Senast bes¨okt 2 maj 2013.]

[37] Google, ”Google Maps/Earth Ytterligare anv¨andarvillkor”, 1 mars 2012, http://maps.google.com/help/terms maps.html [Senast bes¨okt 29 maj 2013.]

[38] JetBrains, ”TeamCity - Continuous Integration for Everybody”, 2013, http://www.jetbrains.com/teamcity/ [Senast bes¨okt 13 juni 2013.]

[39] NUnit, ”Home”, 2013, http://www.nunit.org/ [Senast bes¨okt 13 juni 2013]

[40] MapQuest, ”Terms of Use”, 2 januari 2013, http://info.mapquest.com/terms-of-use/ [Senast bes¨okt 29 mars 2013.]

[41] Lantm¨ateriet, ”WGS 84”, http://www.lantmateriet.se/Kartor-och-geografisk-information/ GPS-och-geodetisk-matning/Referenssystem/ Tredimensionella-system/WGS-84/ [Senast bes¨okt 18 april 2013.]

[42] Google, ”KML”, 1 mars 2012, https://developers.google.com/kml/ [Senast bes¨okt 22 april 2013.]

[43] TypeScript, http://www.typescriptlang.org/ [Senast bes¨okt 22 maj 2013.]

36 Bilagor

I det h¨ar avsnittet finns figurer och appendix f¨or projektrelaterat material som inte ¨ar i n˚agondirekt anknytning till texten. Nedan f¨oljer bland annat ett ¨oversk˚adligtdiagram f¨or systemarkitektur och exempelbilder p˚ade kart- vyer som utvecklades i projektet.

A Systemarkitektur

Figur 1: Overgripande¨ arkitektur f¨or geografitj¨anster och anknutna system. I denna skiss visar pilarna ˚atvilket h˚alldata fl¨odar.

37 B KML i en geografisk l¨asare

Figur 2: KML-fil som ¨oppnats i Google Earth. I det h¨ar exemplet motsva- ras varje kartn˚alav en -tag i KML. Linjerna ¨ar dragna med -element.

Filer som ska ¨oppnas med t.ex. Google Earth skrivs i KML, f¨orslagsvis i en text-editor, och sparas med ¨andringen .kml. D¨arefter ¨ar det enda som kr¨avs att Google Earth eller n˚agonannan GIS-utforskare finns installerad f¨or att kunna ¨oppna och se KML:en.

38 B.1 Exempeldata i KML 1 Exempel KML Kategori 0 Platsmarkering 1 18.0642,59.3334,0 ... Linje 1 1 1 18.0642,59.3334,0 17.6187,59.8511,0

39 B.2 KML-generering med LINQ To XML

Figur 3: Exempelkod f¨or att generera en ”Folder” i KML med en upps¨attning element d¨ar latitud och longitud finns som property.

40 C Kartvy

Figur 4: Exempel p˚aen av kartvyerna som implementerades

41 D How-To D.1 Controller public class MyMapController : Controller { public ActionResult ViewASite(int siteId) { return View(siteId); }

public JsonResult GetSiteJson(int siteId) { using(var db_client = new DatabaseServiceClient()) { return Json(db_client.GetSite(siteId)); } } }

42 D.2 Modul (var geo = (function(module) {

module.maps = [];

module.createMap(divParent, useCluster) { var map = new window.google.maps.Map(element, zoom: 10, mapTypeId: window.google.maps.MapTypeId.ROADMAP, maxZoom: 18, disableDefaultUI: false, center: new google.maps.LatLng(59.0, 18.0), mapTypeControlOptions: { style: window.google.maps.MapTypeControlStyle.DROPDOWN_MENU }

module.maps.push({ map: map, clusterer: useClusterer ? new window.MarkerClusterer(map, []), sites: [] });

return module.maps.length-1; };

module.createSiteMarker = function(mapIndex, site, draggable) { var lat_lng = new window.google.maps.LatLng(site.Latitude, site.Longitude); var marker = new window.google.maps.Marker({ position: lat_lng, title: ’Site’, draggable: draggable ? true : false });

43 module.maps[mapIndex].sites.push({ site: site, marker: marker, info: info }); };

module.createSimpleInfoWindow = function(mapIndex, marker) { var info = new window.google.maps.InfoWindow({ content: ’

Hej

’ });

window.google.maps.event.addListener(marker, ’click’, function () { info.open(module.maps[mapIndex].map, marker); }); return info };

return module; }(window.geo = window.geo || {}));

44 D.3 View

45