Detta examensarbete har genomf¨orts i samarbete med DGC.
Handledare p˚a DGC: Paul Weingarten och Bj¨orn ¨Osterman.
Karttill¨ampningar f¨or rikst¨ackande accessn¨at Map applications for nationwide access net
Johan Camling Fredrik L¨ onnegren
Examensarbete inom Datorteknik Grundniv˚a, 15 hp Handledare p˚a KTH: 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
Sammanfattning
Denna rapport ˚aterger arbetsprocessen 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˚a plats 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˚a upp 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˚ade i befintliga system och som ensamst˚aende till¨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.
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.
F¨ orord
Vi vill passa p˚a att 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˚att en djupare f¨ors˚aelse i 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˚agra av de termer och f¨orkortningar som anv¨ands i texten.
Ocks˚a ett stort lycka till, till Thomas Lundberg och Alexander Heimonen som p˚ab¨orjade sitt examensarbete, ocks˚a p˚a DGC, knappt fyra veckor efter att vi hade startat.
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˚a data genom antingen REST- f¨orfr˚agningar eller 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˚an t.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
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
4.2.3 Webbvy med modell . . . 14
4.2.4 DbSeeder . . . 15
4.3 Geocodes fr˚an extern 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
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˚aende av 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˚a m˚anga platser.
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˚a slutkunders 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˚an extern leverant¨or.
Ut¨over nyttan i ink¨opsprocessen s˚a v¨arderade DGC m¨ojligheten att anv¨anda geografisk information f¨or att presentera sina tj¨anster p˚a en karta, b˚ade in- ternt och i sin kundportal.
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˚a befintlig 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˚an t¨athet.
• Implementation i befintliga system.
Grundtanken med projektet var att skapa flera, i s˚a h¨og grad som m¨ojligt, anv¨andbara verktyg f¨or intern verksamhet p˚a DGC. Programvara skulle va- ra fels¨aker och skriven med kvalitetss¨akrad kod, b˚ade f¨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˚a h¨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˚all av 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˚a implementationsniv˚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˚a h¨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˚a var 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˚agningar mot externa leverant¨orer f¨or att kringg˚a de 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˚alet var 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˚and mellan koordinater.
• Kartl¨agga interna ¨onskem˚al f¨or att uppn˚a h¨ogsta m¨ojliga anv¨andbarhet.
• Unders¨oka heuristiska metoder f¨or att dela upp kartvyer med h¨ansyn till t¨athet (kartomr˚aden med m˚anga accesser beh¨ovde anpassas s˚a att 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˚aden d¨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˚al om 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˚a upp 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˚angspunkt fr˚an DGC:s behov och ¨onskem˚al togs en ¨overgriplig pro- jektdefinition fram med styrande m˚al och 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˚anga av de tekniker som anv¨andes i arbetet. Tanken ¨ar att av- snittet ska ge en f¨orst˚aelse och m¨ojlighet till ˚aterkoppling som underl¨attar l¨asningen av kommande kapitel med en ¨overgripande genomg˚ang av 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˚adet ing˚ar det att utf¨ora punktm¨atningar utifr˚an pla- 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˚a jordens yta i form av vinklar mot mittpunkten. Altitud anv¨ands f¨or att m¨ata avst˚and ovanf¨or jordytan.
Ett exempel p˚a ett 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˚a externa 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 ˚at via REST. Alla tj¨anster varierar i tr¨affs¨akerhet, baserat p˚a vilken 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].
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˚ar det att anv¨anda dessa klasser direkt i databaslogiken.
F¨or att fr˚an databasen f˚a ut distansen mellan tv˚a geografiska 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˚an DAL direkt till da- tabasen som ¨ar optimerad f¨or att behandla stora m¨angder data. Detta ger ocks˚a f¨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 ˚ar 2001 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˚a ett av de mest grundl¨aggande m˚alen f¨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˚an angivna 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˚a gratisalternativ; Nominatim och MapQuest. Respektive leverant¨or kr¨avde att vissa villkor uppfylldes (3.2) om deras tj¨anster implementerades av, f¨or dem, utomst˚aende applikationer. Dessa villkor gav en grund till den bed¨omning som gjordes.
3.2 Geocoding, licensiering och persistent datalagring
Avg¨orande f¨or projektet var om det, enligt villkoren f¨or anv¨andning, var till˚atet att 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]:
• 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˚an t.ex Geocoding Service i mer ¨an 30 dagar (mest p˚a grund av att Google inte vill att f¨or˚aldrat data anv¨ands, och upp- muntrar till att uppdatera ofta).
2. Anv¨anda data h¨amtat fr˚an Googles tj¨anster i applikationer och system som presenterar geografi grafiskt med n˚agot annat ¨an Google Maps.
3. Distribuera och ˚aterf¨ors¨alja n˚agon form av information f¨or kommersiellt bruk som kan relateras till Googles tj¨anster.
8
Just detta urval fr˚an Googles 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˚an google skulle rensas bort efter 30 dagar, men uppslagna platser som redan anv¨andes av systemet lagrades under en l¨angre tid p˚a grund 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˚a best¨amd tid, s˚avida en ers¨attning inte arvoderades Google, vilket i st¨orsta m¨ojliga m˚an ville undvikas. P˚a grund 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˚allen data, f¨orutom att geocodes f˚ar lagras 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˚a grund av dessa f¨orh˚allanden skulle ett system som exklusivt byggde p˚a Bing Maps Platform APIs inte kunna till¨ampa ett flexibelt f¨orfarande, likt hur det s˚ag ut med Googles motsvarighet.
Skillnaden med Bing, trots det kommersiella omf˚anget av varum¨arket, mot Google Maps regler ¨ar dock att det inte finns en begr¨ansning f¨or hur stora m¨angder data som f˚ar beg¨aras per tidsenhet [6].
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˚a och 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˚a det 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˚ag MapQuest att det var l¨ampligt att informera (ge en varning) om att en utomst˚aende tj¨anst kunde komma att kr¨ava h¨og pre- standa, och d¨arf¨or g¨ora en ¨overrenskommelse med MapQuest. P˚a samma 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˚aende samling tj¨anster vilka ligger som fundament f¨or b˚ade Open Streetmap [20] och MapQuest Open Initiative [21] i form av att tillhandah˚alla OSM-data. I dessa tj¨anster ing˚ar bland 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˚a tr¨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˚a till 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˚an f¨orfr˚agningar tolkas 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˚ar geografisk data fr˚an bland andra Tele Atlas, som ¨ar v¨arldens n¨ast st¨orsta akt¨orer p˚a marknaden 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].
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˚a introducerar 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˚an OSM [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˚a s¨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˚as fr˚an en 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˚as av Nominatim [23].
I ett svar fr˚an Nominatim 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˚a ett 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˚alla fram 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˚ang av 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˚a adresser har h¨og tr¨affs¨akerhet (helst s˚a pass bra att t.o.m. antal trappor och d¨orr finns med som parametrar i svaren). Utifr˚an dessa tester och vetskapen fr˚an tidigare 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˚a grund av att Yahoo!s tj¨anst skulle st¨angas ner och att massiv datalagring av koordinater h¨amtade fr˚an Google 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˚aningom avsluta anv¨andandet av tj¨ansten
4.2 Arkitektur
En analys genomf¨ordes f¨or att f¨ors¨oka hitta en s˚a modul¨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˚aende system eller enbart fungera som en p˚abyggnad p˚a ett 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˚a upp) 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˚agningar som 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˚ata modellen 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˚a grund av att geocoding-tj¨ansten be- gr¨ansade antalet f¨orfr˚agningar (baserat p˚a yttre 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˚ an extern leverant¨ or
Processen att utf¨ora en f¨orfr˚agan f¨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˚ag i hur svaret var utformat fr˚an respektive extern tj¨anst. Me- toden som anv¨andes bestod av att anskaffa resultatlistor fr˚an flera 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˚as av respektive extern leverant¨or. Google p˚ast˚ar sig ha fem olika tr¨affar p˚a s¨okningen, Bing tv˚a, Nominatim tre och MapQuest en. Hur kan man d˚a ta reda p˚a vilket 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?
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˚an grader 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) ∗ (±Conf idence)
Varje kartesisk summa l¨aggs till i en total -variabel, som sedan anv¨ands f¨or att r¨akna ut centerpunkten:
center = totx+ toty+ totz
n , d¨ar n ¨ar antalet samlade resultat
Alla punktspecifika summor modifieras (f¨ors¨amras) allts˚a utefter det confi- dence resultaten hade, d¨ar v¨arden som var mindre ¨an center spreds ut ned˚at beroende p˚a hur 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˚ag n¨armst center ans˚ags vara det mest tr¨affs¨akra resul- tatet och returnerades. Denna funktion f¨ors¨okte eliminera d˚aliga h¨amtningar, framf¨orallt f¨or att inte l˚ata s¨okningen hamna i fel land (d˚a confidence var l˚agt i s˚adant fall). Problem uppstod n¨ar samtliga resultat var i fel land, vilket d˚a oftast berodde p˚a att 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˚adan h¨ar funktion.
16
4.3.2 Parsing
Tj¨ansten Geocoding Service utnyttjade LINQ to XML [30] f¨or att plocka ut data fr˚an de svar som genererades av leverant¨orstj¨ansterna.
F¨orfarandet bestod i att:
1. Utforma en f¨orfr˚agan utifr˚an det objekt som klienten beg¨ar:
• Dela upp adress, stad, land och postnummer i str¨angar
• F¨orena varje delstr¨ang (och kontrollera s˚a att formatet blir r¨att
¨aven om n˚agon best˚andsdel inte 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˚alla fram tr¨affs¨akerheten av varje s¨okresultat. Confidence f¨or ett resultat delas upp i:
• Exact - tr¨aff p˚a angivet husnummer
• Good - exempelvis r¨att gatuadress, men inte ett specifikt husnummer
• Approx - tr¨aff p˚a omr˚ade som t.ex v¨ag, stad, kommun eller l¨an
• Bad - tr¨aff p˚a landsniv˚a
• NotFound - inga tr¨affar (mycket d˚aligt resultat)
Urskilja tr¨affs¨akerhet fr˚an Google:
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˚an Google ¨ar ”antingen/eller”. Parametern location type ¨ar det som anv¨ands f¨or att avg¨ora tr¨affs¨akerheten. Exempel p˚a dessa ¨ar:
• ROOFTOP
• RANGE INTERPOLATED
• APPROXIMATE
ROOFTOP anger ett exakt husnummer, ibland till och med vilken v˚aning i h¨oghus adressen ligger p˚a.
RANGE INTERPOLATED betyder ofta att svaret inte ¨ar exakt p˚a husnum- mer, utan snarare att resultatet st¨ammer ¨overrens p˚a gata 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˚an Google 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˚ade som returneras.
Urskilja tr¨affs¨akerhet fr˚an Bing:
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˚an MapQuest:
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˚a delkoder.
Exempel:
Koden L1AAA anger med granularity L1 att resultatet ¨ar en adress. Confi- dence AAA anger med f¨orsta tecknet (s¨akerhet p˚a gatuniv˚a), andra tecknet (s¨akerhet p˚a omr˚adesniv˚a) samt tredje tecknet (s¨akerhet p˚a postnummer) 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˚an Nominatim:
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˚an det.
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˚aldrade geocodes angavs som aktuella gjor- des dessutom en kontroll p˚a cache: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˚alla en- lighet med anv¨andningskraven fr˚an Google.
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˚an databasen nyttjades C#-klassen SqlData- Reader [33]. Valet f¨oll p˚a vanliga SQL-queries ist¨allet f¨or en ORM, som t.ex Entity Framework [34], p˚a grund av att stora m¨angder data skulle skickas fr˚an en WCF-tj¨anst vilket gjorde att det kr¨avdes h¨og kontroll ¨over storle- ken av den data som h¨amtades fr˚an databasen 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˚an business-object-logiken, men efter stresstester p˚afanns on¨odig overhead i att ha den strukturen. P˚a grund av detta om- strukturerades systemet s˚a att data h¨amtades och uppdaterades direkt mot aktuell WCF-tj¨anst.
Ett problem som st¨ottes p˚a var att det inte verkade finnas n˚agot s¨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˚a positionsdatan returneras i en textstr¨ang som sedan g˚ar att 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˚an databasen. Koden s˚ag d˚a ut 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˚a databassidan.
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˚an t.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˚att potentialen 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.
4.6 Webbvyer
Stationer och kundplatser som f˚att sina geografiska positioner uppslagna vi- sades p˚a en 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˚an de 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˚a grund av att m˚anga av vyerna delade mycket av initialiseringsprocessen och filtrering av vilka f¨orbindelser och noder som skulle visas p˚a kartan togs en javascriptmodul fram som sk¨otte detta arbete.
Modulen ansvarade f¨or att h˚alla koll p˚a h¨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.
<script type="text/javascript">
var map = geo.createMap(’map-div’);
$.post(GetSiteUrl, {siteId: 1}, function(site) { var marker = geo.createSiteMarker(map, site);
});
</script>
<div id="map-div"></div>
Exempel p˚a att rita ut en kundplats(site”) med id 1 p˚a en karta Liknande funktionalitet lades ¨aven till f¨or stationer. P˚a grund 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˚anga mark¨orer skulle visas p˚a kar- tan (¨over 10,000 mark¨orer) blev kartvyn oresponsiv och ikonerna ¨overlappade varandra. F¨or att p˚a ett 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˚a f¨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˚alen som 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˚agon optimering. F¨or kundplatserna var detta dock inte m¨ojligt i samma m˚an p˚a grund 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˚ags inte 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˚ata klustraren rita om sig sj¨alv n¨ar alla efterfr˚agningar efter ¨overvakningsdata f¨or ett interval hade kommit tillbaka.
Med hj¨alp av JQuery ser det ut som exemplet nedan.
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˚agan till 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˚att svar fr˚an servern.
4.7 Publicering
Som avslutande moment i arbetet genomf¨ordes en ¨overgripande release. Samt- liga delar av projektet sl¨apptes samtidigt med s˚a mycket 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˚ang anv¨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˚a modifikationer 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˚a DGC.
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˚a Google 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˚a bland 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
5 Interna ¨ onskem˚ al
Efter halva projektets g˚ang genomf¨ordes en ¨onskem˚alsunders¨okning bland de tillt¨ankta anv¨andarna hos DGC.
Detta ledde till att ett antal troliga anv¨andningsomr˚aden togs 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˚a en karta. Denna vy skulle ha ett tunnare och mer enkelt gr¨anssnitt med f¨argkodad status p˚a l¨ankar. Man ans˚ag att 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˚a ett ¨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˚an de adresser som s¨oktes.
26
6 Resultat
De huvudsakliga m˚alen med projektet var att med hj¨alp av en webservice kunna sl˚a upp 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˚alsatt men f¨orbis˚ags var WPF- till¨ampningen, som beslutades vara ¨overfl¨odig.
6.1 Geocode service
Den f¨orsta delen, vilken l˚ag som st¨ottepelare f¨or ¨ovrig funktionalitet i syste- met, som framtogs var WCF-tj¨ansten Geocode service. Med den g˚ar det att sl˚a upp adresser till koordinater med h¨og tr¨affs¨akerhet tack vare att den f˚ar data fr˚an ett 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˚ata att gamla uppslagningar kunde h¨amtas direkt fr˚an tj¨anstens lagrade historik, ist¨allet f¨or att varje g˚ang en uppslagning g¨ors skicka f¨orfr˚agningar till 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 ˚aterges hur Google Earth anv¨andes f¨or att st¨odja n¨atplanering.
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˚agon anledning 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˚an Geocode service f¨or att rita ut platsmarkeringar f¨or stationerna p˚a en Sverigekarta.
6.2.2 Kundvy
I ett av de befintliga interna systemen hos DGC implementerades en vy f¨or att kunna se kundplatser p˚a en 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˚a platser och stationer i katalogerna f¨ardades utforskarens gr¨anssnitt ¨over Sverigekartan och centrerade sig p˚a den 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˚ade f¨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˚alla och vidareutveckla. Samtliga delar av systemet dokumenterades b˚ade i form av kommentarer i kod och systemdokumentation i interna verktyg.
6.4 Uppfyllande av m˚ alen
Enligt de m˚al som 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˚a upp 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˚ater anv¨andare att bland annat se individuella kundplatser p˚a en karta. Se ¨aven 6.1 och 6.2.
7 Slutsatser
Geocoding ¨ar f¨orh˚allandevis simpelt 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˚an en leverant¨or skulle f¨or en nyb¨orjare i t.ex. C# g˚a fort, 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˚al till att rita DGC:s n¨at i Google Earth.
Systemet som framtogs f¨orenklade ¨aven det dagliga arbetet i b˚ade orderpro- 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˚an unders¨okningen som gjordes kom det fram att det ¨aven var ¨onskv¨art att f˚a fram brandbreddsutnyttjande f¨or f¨orbindelser. Detta skulle ¨oppna upp f¨or att kunna se geografiska problemomr˚aden och eventuella flaskhalsar p˚a ett mer ¨oversk˚adligt s¨att. Detta f¨oll dock bort p˚a grund 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˚aller l¨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˚anga upp fel som annars l¨att missas n¨ar javascript ¨ar med i bilden.
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˚an Wikipedia: ”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 BingR TM 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.]
[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.]
[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˚agon direkt anknytning till texten. Nedan f¨oljer bland annat ett ¨oversk˚adligt diagram f¨or systemarkitektur och exempelbilder p˚a de kart- vyer som utvecklades i projektet.
A Systemarkitektur
Figur 1: ¨Overgripande arkitektur f¨or geografitj¨anster och anknutna system.
I denna skiss visar pilarna ˚at vilket h˚all data fl¨odar.
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˚al av en <Placemark>-tag i KML. Linjerna ¨ar dragna med
<LineString>-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˚agon annan GIS-utforskare finns installerad f¨or att kunna ¨oppna och se KML:en.
38
B.1 Exempeldata i KML
<?xml version="1.0" encoding="utf-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<open>1</open>
<name>Exempel KML</name>
<!-- En folder med ett namn, l¨amnas st¨angd som default -->
<Folder>
<name>Kategori</name>
<open>0</open>
<Placemark>
<name>Platsmarkering 1</name>
<Point>
<coordinates>18.0642,59.3334,0</coordinates>
</Point>
</Placemark>
...
<Placemark>
<name>Linje 1</name>
<LineString>
<extrude>1</extrude>
<tessellate>1</tessellate>
<coordinates>
18.0642,59.3334,0 17.6187,59.8511,0
</coordinates>
</LineString>
<Style>
<LineStyle>
<color>#ffffffff</color>
<width>5</width>
</LineStyle>
</Style>
</Placemark>
</Folder>
</Document>
</kml>
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˚a en av kartvyerna som implementerades
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 });
module.maps[mapIndex].sites.push({
site: site, marker: marker, info: info });
};
module.createSimpleInfoWindow = function(mapIndex, marker) { var info = new window.google.maps.InfoWindow({
content: ’<p>Hej</p>’
});
window.google.maps.event.addListener(marker, ’click’, function () {
info.open(module.maps[mapIndex].map, marker);
});
return info };
return module;
}(window.geo = window.geo || {}));
44
