Geospatial visualisering i 3D över öppna standarder och fri programvara LUKAS JOHANSSON

Geospatial visualisering i 3D över öppna standarder och fri programvara LUKAS JOHANSSON Examensarbete Stockholm, Sverige 2009

Geospatial visualisering i 3D över öppna standarder och fri programvara LUKAS JOHANSSON Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Kjell Lindqvist Examinator var Stefan Arnborg TRITA-CSC-E 2009:087 ISRN-KTH/CSC/E--09/087--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se

Sammanfattning Historiskt sett har området Geografiska informationssystem präglats av bristen på gemensamma standarder. Detta resulterade i att många specifika lösningar för geografisk data togs fram vilka ofta hade svårt att kommunicera och dela data med andra system. Grundandet av Open Geospatial Consortium tillsammans med det ökande intresset för öppen källkod har gjort att området på senare år har öppnats upp och att datautbyte mellan system har blivit allt enklare. I denna studie har författaren undersökt tillgängliga öppna standarder och öppen källkodsverktyg. Målet var att ta fram en prototyp för ett tredimensionellt webbaserad GIS. För att bestämma vilka standarder som skulle komma att användas i protypen genomfördes en undersökning där tekniska alternativ valdes för områdena: klientplattform, dataformat och protokoll. Den slutliga prototypen använder sig av CityGML och WFS och visar att det är fullt möjligt att visualisera tredimensionella byggnader i en webbläsare med hjälp av öppna standarder och öppen källkod. Abstract Geospatial visualization in 3D using open standards and open source In a historical point of view, the field of Geographic Information Systems lacked common standards which resulted in a large number of incompatible systems. The creation of Open Geospatial Consortium in conjunction with the increased popularity of the open source movement has resulted in a more open environment where different systems can communicate and share data with each other more easily. In this study the author examined available open standards and open source tools. The goal was to develop a three dimensional webbased GIS prototype. To decide which standards to use the author performed an evaluation where client platform, data format and communication protocol were chosen. The final prototype was developed using CityGML and WFS and it showed that open source tools and open standards can successfully be used to visualize three-dimensional buildings in a web browser context.

Förord Denna studie är ett examensarbete inom datalogi på CSC, Kungliga Tekniska Högskolan i Stockholm, med uppdragsgivaren Decerno AB. Jag skulle vilja tacka mina handledare Kjell Lindqvist och Torsten Hökby för deras hjälp och stöd under arbetets gång samt Lina Ståhl, Per-Olof Norén, Mats Norén och Hans-Peter Aineskog för deras medverkande i undersökningen samt de diskussioner och den kunskapsöverföring som dessa personer har erbjudit. Jag vill också vilja passa på att tacka alla de personer som jag träffat vid olika konferenser under våren, och som har visat intresse för mitt examensarbete. Ett extra stort tack vill jag ge Anders Pikkuniemi från Helsingborgs kommun som har försett examensarbetets prototyp med testdata. Slutligen vill jag rikta ett extra stort tack till Jan-Fredrik Bergliden för hans hjälp med korrekturläsning av rapporten och till Cecilia Bergliden för hennes ständiga stöd.

Innehåll Ordlista 1 Introduktion 1 1.1 Bakgrund................................. 1 1.2 Mittbygge.se............................... 2 1.3 Gismo................................... 2 1.4 Problem.................................. 2 1.5 Begränsningar............................... 3 2 Teori 5 2.1 Öppen källkod.............................. 5 2.2 Öppna standarder............................ 5 2.3 Geografiska informationssystem..................... 6 2.3.1 Lagring av geospatial data i databas.............. 8 2.3.2 WebbGIS............................. 9 2.4 Visualisering............................... 11 2.4.1 Visualisering i två och tre dimensioner............. 11 2.4.2 Viktiga framsteg inom tredimensionell visualisering...... 13 2.5 Data och filformat............................ 14 2.5.1 VRML / GeoVRML....................... 14 2.5.2 X3D................................ 15 2.5.3 GML................................ 16 2.5.4 KML................................ 16 2.5.5 CityGML............................. 16 2.6 OGC:s webbtjänster........................... 18 2.6.1 WMS Web Map Service.................... 19 2.6.2 WFS/WFS-T Web Feature Service............. 19 2.6.3 WTS Web Terrain Service.................. 21 2.6.4 W3DS Web 3D Service.................... 21 2.7 Modellering av byggnader i 3D..................... 24 2.7.1 Manuell modellering....................... 24 2.7.2 Automatisk modellering..................... 25

3 Metod 29 3.1 Val av tekniska alternativ........................ 29 3.2 Undersökning............................... 30 3.2.1 Multikriterieanalys........................ 30 3.3 Utvecklingsmetodik............................ 33 4 Genomförande 35 4.1 Utförd undersökning........................... 35 4.1.1 Utförd multikriterieanalys.................... 35 4.1.2 Resultat.............................. 40 4.2 Prototyp.................................. 41 4.2.1 Planering............................. 42 4.2.2 Testdata.............................. 42 4.2.3 Arbetsgång............................ 43 5 Slutsatser och rekommendationer 51 5.1 Stadsmodeller och format........................ 51 5.2 Datainsamling.............................. 52 5.3 Modellering................................ 52 Litteratur 53 Övriga referenser 57 Bilagor 59 A Underlag undersökning 61

Ordlista CityGML Dataformat, 16 Geografisk data Data som är förknippad med en position på jordens yta, 6 Geospatial data Data som är förknippad med en position i en geografisk rymd, 6 GIS Geografiska informationssystem; Samlingsnamn för datasystem avsedda för att samla in, analysera och presentera lägesbunden information, 1 OGC Proprietär Scengraf Sprint Open Geospatial Consortium, Branschorganisation som tar fram och underhåller öppna standarder för geospatial datahantering, 1 Någonting som ägs av en leverantör och som begränsas av denna. Kan exempelvis vara en standard eller ett system som enbart kontrolleras av en kommersiell leverantör, 1 Hierarkisk datarepresentation av en tredimensionell scen, 12 Kortare utvecklingsfas under iterativ utveckling. Inför varje sprint planeras vad som ska utföras under sprinten, 33 WebbGIS Webbaserat GIS där användargränssnittet finns tillgängligt direkt i användarens webbläsare, 1 XSLT Deklarativt språk som används för att förändra XML-dokument enligt en viss mall, 43

Öppen källkod Öppen källkod, en. Open Source, är datorprogram där källkoden är tillgänglig att använda, läsa, modifiera och vidaredistribuera för den som vill. Användaren kan därmed försäkra sig om att programmet gör vad det ska, eller anpassa det till sina behov, 1

Kapitel 1 Introduktion 1.1 Bakgrund Historiskt sett har marknaden för geografiska informationssystem, GIS (kapitel 2.3) dominerats av proprietära lösningar från leverantörer såsom Autodesk och ESRI. Affärsmodellen hos dessa leverantörer har varit att kunna leverera en komplett lösning innehållande alla komponenter som deras kunder kan tänkas efterfråga. På så sätt låser man kunden i ett leverantörsberoende och därmed också till att fortsätta köpa produkter ur leverantörens produktportfölj. På senare år har kunderna efterfrågat mer öppenhet samt möjlighet att koppla samman olika system för att bättre kunna nyttja den samlade informationen. Samtidigt har kartprodukter såsom hitta.se, Google Earth/Maps och Open Streetmap bidragit till att acceptansnivån för karttjänster hos allmänheten har ökat, vilket i sin tur har bidragit till att marknaden för webbgis växt. För att möta de nya behoven av öppenhet och interoperabilitet mellan olika GIS har Decerno AB tillsammans med företaget Mogul AB tagit fram en plattform för webbgis. Denna är byggd på komponenter som är öppen källkod och som följer öppna standarder framtagna av Open Geospatial Consortium OGC. Plattformen erbjuder idag möjligheten att konstruera system med kartor i två dimensioner. Under senare år har tjänster som Google Earth och hitta.se 3D fått ett positivt mottagande och används nu av ett stort antal vanliga användare. Detta tillsammans med att fler och fler kommuner runt om i Sverige börjat hantera sina kartor i tre dimensioner har gjort att även efterfrågan för tredimensionell visualisering har ökat. I Sverige har fyra kommuner (Stockholm, Göteborg, Helsingborg och Malmö) gått samman i projekt 3D4Stad, för att utarbeta en arbetsstandard för lagring och hantering av kommunala 3D-stadsmodeller (Jeansson, 2008). Dessutom har ett pilotprojekt med C3-Technologies genomförts och idag finns alla de fyra städerna i hitta.se 3D. 1

KAPITEL 1. INTRODUKTION 1.2 Mittbygge.se Mittbygge.se är en webbportal där en kommuns invånare själva kan tillgodogöra sig regler och föreskrifter rörande byggnation. Portalen erbjuder även invånarna i 14 olika kommuner att digitalt göra sin bygglovansökan. Företaget bakom portalen ser åtminstone två användningsområden med att kunna erbjuda tredimensionell visualisering över internet: Kommunen kan presentera nuvarade byggnadsplaner i en tredimensionell klient och på så sätt ge invånarna ett komplement till tvådimensionella plankartor och skalenliga modeller. Användarna av portalen kan själva konstruera sina husmodeller och skicka med dessa tillsammans med ansökan om bygglov. Detta gör att missförstånd vid handläggningen kan undvikas samtidigt som grannar och andra intressenter på ett mycket tidigt stadium kan få en uppfattning om hur byggnationen kommer att påverka omgivningen. För att göra dessa tjänster lätttillgängliga för invånarna måste det vara möjligt att visualisera tredimensionell data över internet. Då det i det andra användninsområdet inte går att förutsätta att användarna besitter någon kompetens inom husmodellering krävs det att verktyget som används för att skapa och editera husmodeller är enkelt och intuitivt. 1.3 Gismo Gismo är en demonstrator för att visa upp den plattform för webbgis som har tagits fram i samarbete mellan företagen Decerno AB och Mogul AB. Plattformen använder en typ av karttjänst WMS (kapitel 2.6.1) för att visa en tvådimensionell kartbild. Informationen som bilden byggs upp av finns lagrad i en PostgreSQL/PostGISdatabas och bilden genereras av kartservern GeoServer. Webbklienten är baserad på OpenLayers, ett kartramverk skrivet i Javascript. 1.4 Problem För att bearbeta och visualisera tredimensionella vyer och objekt krävs en kraftigare klient och om möjligt även tillgång till klientdatorns grafikkort. Därför är de flesta tredimensionella lösningarna inte webbaserade utan byggda som fristående applikationer eller insticksprogram till webbläsaren, vilka måste laddas ner och installeras innan de kan användas. Ett undantag är hitta.se 3D, som har implementerats i form 2

1.5. BEGRÄNSNINGAR av en Java-applet och därmed kan startas direkt i webbläsaren, men samtidigt ändå kan använda sig av datorns grafikkort. För att lösningen ska vara attraktiv i ett framtida affärsprojekt måste den kunna dra nytta av existerande data som exempelvis en kommun redan besitter. Därför är det viktigt att man hanterar de vanliga format och lagringsmodeller för 3D-data som används. För att underlätta integration och interoperabilitet är det också viktigt att man kommunicerar med hjälp av öppna standarder och format. Målet för denna studie var: Att utvärdera tekniska lösningar baserade på öppen mjukvara, som möjliggör visualisering och editering av lägesbunden data i tre dimensioner. Som en följd av denna utvärdering togs även en prototyp fram. För att uppfylla målet har följande punkter undersökts: Vilka standarder finns för att transportera och visualisera objekt i 3D? Hur väl hanterar PostgreSQL/PostGIS data i tre dimensioner? Finns det några begränsningar? Vilken forskning finns och hur har andra projekt närmat sig problemställningen? Vilka för/nackdelar har olika tekniska lösningar? Hur ska byggnader hanteras och vilken detaljnivå är intressant på dem? Hur ser datamodeller och lagringmetoder ut för kartor som levereras i 3D? 1.5 Begränsningar I denna studie har följande begränsningar gjorts: Inte lägga stor vikt vid utseende/texturer. Inte lägga stor vikt på prestanda och stöd för multipla användare. I lösningen endast stödja datarepresentationen från en leverantör/ett format. Då faktisk utvecklingstid för prototypen var begränsad har en prioritetslista för denna tagits fram. Listan visar basfunktionalitet samt funktionalitet som skulle läggas till i mån av tid. 1. Visualisera 3D-data i en webbläsare över öppna standarder och öppna format. 2. Säkerställa ett komplett flöde mellan en spatial databas och en webbklient. 3. Erbjuda enkel manipulation och skapande av 3D-objekt. 3

Kapitel 2 Teori 2.1 Öppen källkod Fri och öppen programvara är två begrepp som ofta behandlas som samma sak och då går under beteckningen öppen källkod, Open source. Fri mjukvara under ledning av The free software foundation, FSF är en idealistisk rörelse grundad av Richard Stallman där ordet fri används med betydelsen frihet. Alla människor har friheten att sprida, studera och framförallt modifiera fri programvara (Scacchi, 2007). Bruce Perens och Eric S. Raymond grundade 1995 The Open Source Initiative, OSI med syftet att skapa en mer företagsvänlig och mindre ideologiskt laddad organisation. De två rörelserna har mycket gemensamt och delar framförallt den grundläggande utvecklingsmetodiken i vilken vem som helst kan bidra till utvecklingen av ett projekt, var i världen man än finns. Det kan ibland vara svårt att avgöra om ett specifikt projekt är fritt, öppet eller både och, då detta i grunden är en fråga om vilka mjukvarulicenser som projektet använder. Enkelt kan man säga att fri mjukvara alltid är öppen, medan öppen mjukvara inte alltid behöver vara fri (Scacchi, 2007). 2.2 Öppna standarder En standard är en specifikation för hur en lösning ska fungera, alternativt en instruktion för hur någonting ska utföras. Om alla gör någonting på samma sätt innebär det att deras individuella lösningar kommer att vara kompatibla med varandra vilket i sin tur kan bidra till ökad nytta för den aktuella teknologin (Kesan och Shah, 2008). Exempelvis är det tack vare nätverksstandarden TCP/IP som det idag finns ett globalt datanätverk kallat Internet, som är uppbyggt av ett stort antal leverantörer där mer eller mindre alla datorer och mobiltelefoner fritt kan kommunicera. Vid en tillbakablick finner man att många av de framsteg som gjorts inom data- och informationsteknik under de senaste 20-30 åren har skett tack vare just standarder (Kesan och Shah, 2008). Det finns många olika typer av standarder, exempelvis informella de facto- 5

KAPITEL 2. TEORI standarder som uppkommer genom att majoriteten anammar ett visst sätt att arbeta, eller industristandarder som administreras formellt av exempelvis International Organization for Standardization, ISO. Begreppet öppna standarder har framförallt på senare år fått stor spridning och det finns många olika definitioner för vad som egentligen kännetecknar en sådan. (Kesan och Shah, 2008) har valt att definiera öppna standarder genom att ange tre kriterier som ska vara uppfyllda (tabell 2.1). 1. Standarden ska vara publikt tillgänglig till en minimal kostnad. 2. Ingen ensam aktör kontrollerar standarden. Om så ändå är fallet ska standarden vara tillgänglig för alla aktörer utan diskriminering. 3. Utvecklingsarbetet av standarden bedrivs öppet och involverar publika intressenter. Tabell 2.1: Kriterier för öppna standarder enligt (Kesan och Shah, 2008) 2.3 Geografiska informationssystem Allmost everything that happens, happens somewhere. Knowing where something happens is critically important (Longley, Goodchild, Maguire och Rhind, 2001) Definition 1. Med geografisk data menas lägesbestämd data som är förknippad med jordens yta, och där position ofta anges med en longitud/latitud angivelse. Spatial data betecknar lägesbestämd data i någon rymd, exempelvis rymden, en människas kropp eller en annan planet. Geospatial data betecknar lägesbestämd data på jordens yta och bestämmer även positionens höjd. Definition 2. Ett raster är en datarepresentation i två dimensioner. Informationen lagrad i ett raster motsvarar antingen en bildpixel eller någon form av värde. Exempel på rasterdata är satellit- och flygfoton där varje cell har en viss färg, men det finns många andra typer av data som kan lagras i ett raster, exempelvis höjdkartor där varje cell har ett höjdvärde, eller markanvändning där varje cell indikerar vad marken används till. Definition 3. En vektor är en representation av punkter, linjer, kurvor och ytor som representeras genom att lagra koordinatpar (eller tripplar i en 3D-rymd). I fallet med punkter räcker det med ett par och i fallet med linjer lagrar man par för start, slut- och brytpunkter på linjen. Är målet att visualisera en linje eller kurva baserat på ett antal punkter dras en rak linje mellan varje närliggande par. Antalet punkter styr då hur exakt linjen avbildas. Om önskan istället är att visa en mjukare kurva kan denna istället approximeras genom att interpolera den med ett flergradigt 6

2.3. GEOGRAFISKA INFORMATIONSSYSTEM polynom genom punkterna. Det är dock viktigt att komma ihåg att interpolation i och för sig ger mjuka kurvor men att kurvorna riskerar att bli väldigt förvrängda (Runges fenomen), speciellt vid hög grad på polynomet (Eklundh, Arneberg, Arnborg, Eklundh, Harrie, Hauska, Olsson, Pilesjö, Rystedt och Sandgren, 1999). I CAD och illustrationsprogram används ofta Bezierkurvor som är en variant av polynominterpolation av grad två eller tre med en eller två ankarpunkter. Geografiska Informationssystem definieras av (Eklundh m.fl., 1999) som: Ett datoriserat informationssystem för hantering och analys av geografiska data. Den mest grundläggande egenskapen för ett GIS är att det hanterar lägesbunden information i någon form samt att rumsliga analyser och urval kan utföras på detta data. I lista 1 ses ett exempel på en frågeställning som kan besvaras med hjälp av ett GIS. Det är viktigt att komma ihåg att resultatet av en analys är helt beroende på kvalitén på det data som används i analysen. Detta är speciellt viktigt vid längd- och ariaberäkningar, då data alltid generaliseras mer eller mindre vid digitaliseringen (Eklundh m.fl., 1999). Mål: Kartlägga hur stor del av befolkningen som är i riskzonen för att drabbas av giftiga utsläpp efter en bilolycka. Frågeställning: Hur många personer bor i bostäder som förses med dricksvatten från brunnar som är grundare än tre meter och grävda i lättgenomsläppliga jordar samt ligger inom 1km nedströms från en väg som trafikeras av tunga fordon bärande miljöfarlig last? Denna frågeställning är fullt möjlig att besvara om man har tillgång till följande datamängder över det aktuella området: befolkningsregister fastighetsregister trafikstatistik vägdatabas brunnsregister jordartskarta höjdmodell Lista 1: Exempel på möjlig sökning i ett GIS (Eklundh m.fl., 1999) Geospatial information används inom de mest skilda områden såsom kartframställning, väg- och fastighetsplanering, skogshantering, miljöbevarande och framförallt i militära tillämpningar (Eklundh m.fl., 1999). Det militära användandet har bidragit mycket till utvecklingen inom området och speciellt under kalla kriget gjordes många framsteg (Longley m.fl., 2001). Det första GIS:et Canada Geografic Information System togs fram redan på 1960-talet men utvecklingen begränsades av tillgång på och kostnad för datorer och annan hårdvara. Detta medförde att utvecklingen tog fart först när priserna under 1980-talet sjönk till rimliga nivåer (Longley m.fl., 2001). Utvecklingen drevs av enskilda företag, militär och universitet men gemensamt för dem alla var att de tog fram sina egna helhetslösningar. Dessa lösningar hade problemet att de inte 7

KAPITEL 2. TEORI hade något gemensamt sätt att kommunicera, vilket innebar att man tvingades till mödosamma konverteringar för att överföra data mellan systemen (OGC, 2006a). I början av 1980-talet togs ett rastergis, Geographic Resources Analysis Support System GRASS, fram av amerikanska armén. Systemet användes på universitet runt om i världen och då källkoden gjordes tillgänglig blev GRASS ett av de första globalt utvecklade öppen källkodsprojekten. Trots att GRASS hade ett öppet dataformat och utvecklades av frivilliga användare var inte projektet inflytelserikt nog för att kunna influera de kommersiella leverantörerna (OGC, 2006a). Open Geospatial Consortium OGC grundades 1994 med tanken att fortsätta på den väg som GRASS hade påbörjat och målet var att ta fram öppna standarder för geospatiala system och tjänster. Det finns idag 381 olika intressenter involverade i OGC och ett stort antal standarder har tagits fram, exempelvis standarder för databaslagring, webbtjänstprotokoll och filformat. I dag använder framförallt många öppen källkodsprojekt inom GIS-området OGC:s standarder men även proprietära system får allt bättre stöd för dem. 2.3.1 Lagring av geospatial data i databas Definition 4. En feature definieras av OGC som ett objekt som associerats med en position relativ till jorden. Objektet är en abstraktion av ett verkligt objekt exempelvis ett träd. Flera individuella instanser av en feature med samma karaktär och egenskaper sägs tillhöra en feature-type. Som programmerare kan man betrakta en feature som ett objekt med ett antal egenskaper varav en geometrisk representation. Databassystem har under lång tid utvecklats till att kunna hantera stora mängder data och det som gör dem så kraftfulla är möjligheten att med god prestanda utföra sökningar och beräkningar i stora datamängder vilka kan vara uppbyggda av flera kombinerade tabeller. Då många operationer i GIS handlar just om att söka efter, och utföra olika typer av mängdberäkningar på data insågs tidigt att en databas skulle kunna utnyttjas som lagringsplats. Oavsett vilken typ av data som ska modelleras i en databas är det långtifrån självklart hur detta ska göras (Eklundh m.fl., 1999) och då geospatial data består av geometriska element såsom punkter, linjer och ytor som saknar motsvarighet i databasen, (denna hanterar i första hand endast enklare datatyper exempelvis textsträngar, numeriska värden och datum), är det än mindre självklart. Detta resulterade i att många GIS-leverantörer gjorde sina egen databastillägg för att lägga till stöd för geometrier vilket resulterade i ett stort antal databassystem (Longley m.fl., 2001). Simple Feature För att ena GIS-världen på databasnivån tog OGC fram standarden Simple Feature SQL (OGC, 2006b), en standard för hur geospatial data ska lagras samt hur de spatiala funktioner som databasen ska tillhandahålla ska anropas och fungera. I 8

2.3. GEOGRAFISKA INFORMATIONSSYSTEM standarden definieras ett antal geometriska typer (figur 2.1) samt ett stort antal funktioner, (exempel tabell 2.2). Figur 2.1: Tillgängliga typer i OGC Simple Feature (OGC, 2006b) GeomFromText(in String) IsEmpty(g Geometry) Length(c Curve) Contains(g1 Geometry, g2 Geometry) Intersects(g1 Geometry,g2 Geometry) Union(g1 Geometry, 2 Geometry) Översätter WKT (figur2.2b) till Geometri Avgör om geometrin är tom Längden av en kurva Sann om g2 ligger helt i g1 Sann om g1 skär g2 Ger unionen mellan g1 och g2 Tabell 2.2: Exempel på funktioner definierade i OGC Simple Feature Geometrin ses som en del av en feature och när en ny feature-type, exempelvis byggnad ska skapas görs detta genom att skapa en feature-tabell innehållande alla icke-spatiala attribut för byggnader. En eller flera geometriska kolumner kan sedan skapas och bindas till denna tabell. När en faktisk byggnad sätts in i tabellen lagras den tillhörande geometrin i form av en Well Known Binary-sträng, WKB (figur 2.2a) i den geometriska kolumnen. Då WKB inte är speciellt användarvänlig används ofta Well Known Text, WKT (figur 2.2b) vid arbete mot databasen. Denna sträng kan översättas till en geometri med funktionen GeomFromText. Även den omvända konverteringen från geometri till WKT är möjlig. 2.3.2 WebbGIS Acquiring, visualizing and distributing geographical information are essential for GIS. A Web based desktop VR system will be best suitable for this purpose. Shan (1998) Internet har sedan det blev publikt tillgängligt i början 1990-talet växt explosionsartat och är i dag den i särklass största kommunikationskanalen i världen. Till 9

KAPITEL 2. TEORI 0105000020C30B0000010000000102000 000040000588825CA5B2D04410AFC8AA4 5E0E5941812E14373D2D0441D68754125 F0E59412B395716002D0441559EE7735F 0E5941B78E9E08BD2C0441280F70D95E0 E5941 (a) WKB representation MULTILINESTRING(( 165291.4737044 6568314.57098294, 165287.651893962 6568316.28640934, 165280.010908553 6568317.81101187, 165271.629208674 6568315.39746455 )) (b) WKT representation (c) Visuell representation Figur 2.2: Olika sätt att representera en väglänk skillnad från när internet introducerades har dagens användare vant sig vid att internetbaserade tjänster är snabbladdade och responsiva, och redan en fördröjning på några fåtal sekunder räcker för att vara störande. Därför säger (Giannopoulos, Hatzi, Nikolaidou och Anagnostopoulos, 2007) att det är viktigt att hålla ner laddningstiden även för mer avancerade tjänster som användaren trots allt kan tänka sig att vänta på. Exempelvis bör laddningstiden av en tredimensionell visualisering inte överstiga 60-80 sekunder. För att lyckas med detta mål belyser de vikten av att hålla ner den överförda datans storlek, och påpekar även att man alltid måste väga egenskaperna: laddningstid, filstorlek och detaljnivån, mot varandra. Lösningen de presenterar är att förenkla data genom polygonreduktion och sammanslagning av geometrierna. (Beard, 2006) löser istället problemet med att överföra stora datamängder genom att initialt låta alla datalager vara avslagna. Detta gör att den initiala inladdningen endast är på 400kB. Användaren får sedan göra ett aktivt val för att aktivera varje nytt datalager och blir då presenterad med en ungefärlig tid för nerladdningen av detta lager. Historiskt sett har GIS implementerats som tunga desktopapplikationer och det är därför intressant att notera att (Shan, 1998) redan 1998 pekar ut webbaserade GIS som framtidens plattform för att samla in, visualisera och distribuera geografisk data. 10

2.4. VISUALISERING 2.4 Visualisering När informationen som finns lagrad i ett GIS ska visualiseras är syftet att göra det lättare för en människa att förstå. Anledningen till detta är att de flesta människor har lättare att förstå hur vägen som illustreras i figur 2.2c ser ut än samma väg i figur 2.2a eller figur 2.2b. 2.4.1 Visualisering i två och tre dimensioner Historiskt har geografisk data nästan uteslutande representerats i två dimensioner, till exempel i form av kartor. Begreppet karta kan beskrivas som: En representation av miljön som används som ett hjälpmedel för att få en mental bild av de rumsliga relationer som existerar i det aktuella området (Nurminen, 2006). Enligt denna definition kan alltså även en tredimensionell representation ses som en karta. En karta kan tillföra ytterligare värde än den verkliga värld den avbildar då den kan innehålla ytterligare element, exempelvis gatunamn och symboler (Nurminen, 2006). Hur kartor skapas och ser ut varierar i olika delar av världen och för att tillgodogöra sig materialet i en karta måste denna först tolkas. Detta gör att en person som vill läsa en karta måste ha kunskap och förståelse för hur den aktuella karttypen är uppbyggd (Nurminen, 2006). (Nurminen, 2006) presenterar även en hypotes att ju mer en karta liknar den värld som betraktaren lever i desto mer lättförstådd är den. Då människor lever och rör sig i en tredimensionell värld bör därför en tredimensionell karta vara lättare att förstå än en tvådimensionell. Detta blir tydligt i figur 2.3a. I den tvådimensionella kartan måste betraktaren dels ha förståelse för begreppet höjdkurvor, dels kunna tolka dessa för att få en uppfattning av hur terrängen ser ut, medan han/hon intuitivt förstår detta direkt i den tredimensionella bilden. Tvådimensionella representationer såsom kartor och ritningar är mycket lämpliga för att klargöra precisa relationer och mått (Brooks och Whalley, 2005). De ger ofta en god översikt över större områden och det är exempelvis enklare att på en platt karta planera en resa, jämfört med en tredimensionell karta där vägar kan vara dolda av dalgångar och berg. I tredimensionella stadsmiljöer kan man direkt se hur byggandet av en ny byggnad påverkar stadsbilden, samt visa vilka skuggor den kommer att kasta genom att utföra skugganalyser där solens gång simuleras (Jeansson, 2008). Båda representationerna har alltså både för- och nackdelar (Brooks och Whalley, 2005) och det är syftet med visualiseringen som ska avgöra vilken som används. GIS och 3D-visualisering GIS och 3D-visualisering är två separata områden som har utvecklats parallellt sedan slutat av 1980-talet. Inom GIS-världen skapades många proprietära system som var och ett hade ett eget sätt att lagra och hantera spatial data. Inmatning 11

KAPITEL 2. TEORI (a) Tidig visualisering av terräng i 2D och 3D i AVS-ARC (1995) (b) Stadsmiljö i GeoVRML (2000) Figur 2.3: Exempel på historiska visualiseringar i 3D (Rhyne m.fl., 2004) och visualisering skedde antingen i CAD-program eller i leverantörsspecifika lösningar och utvecklingen fokuserades inte i första hand på visualiseringen. I visualiseringsvärlden låg fokus istället på visualisering och tankar om topologi, geografiska koordinatsystem och relationer mellan objekten var en underordnad fråga. När GIS-leverantörerna fick förfrågan om att inkludera tredimensionell visualisering i sina system blev lösningen oftast att en tredimensionell vy lades vid sidan om den vanliga tvådimensionella vyn (figur 2.3a) (Brooks och Whalley, 2005). När visualiseringstekniken började mogna under 1990-talet började fler och fler kartografer och geografer intressera sig för denna och fokusgrupper skapades med syfte att undersöka frågor rörande visualiseringen av geospatial data (Rhyne, MacEachren och Rhyne, 2004). VRML Consortium skapades 1996 av den grupp som hade tagit fram version 1.0 av filformatet VRML (kapitel 2.5.1). Organisationen bytte 1998 namn till Web3D Consortium, en organisation med syftet att ta fram format och standarder för tredimensionell visualisering över internet. Man tog fram version 2.0 av VRML och senare även GeoVRML (kapitel 2.5.1) för att bättre kunna använda VRML till att visualisera geospatiala objekt (figur 2.3b). Nästa version av VRML, X3D (kapitel 2.5.2) presenterades 2001. Alla tre filformaten är framtagna med generell visualisering i åtanke, men både GeoVRML och X3D har visst stöd för geospatial data. Vanligtvis används filformaten genom att en fil representerande en tredimensionell scen i form av en scengraf läggs upp på en webbsida och sedan visas med hjälp av ett passande insticksprogram för webbläsaren. OGC presenterade 2001 respektive 2005 två diskussionsartiklar rörande Web 12

2.4. VISUALISERING Terrain Service, WTS (kapitel 2.6.3) och Web 3D Service, W3DS (kaptitel 2.6.4). WTS beskrivs som tjänst liknande Web Map Service, WMS (kapitel 2.6.1) där resultatet av ett anrop är en bild av en tredimensionell vy. W3DS är en tjänst som returnerar en hel eller delar av en navigerbar tredimensionell scen i något av formaten (VRML, GeoVRML eller X3D). Filformatet CityGML (kapitel 2.5.5) antogs 2008 som en OGC-standard med syftet att bära geospatial data innehållande geografiska miljöer och i synnerhet stadsmiljöer. CityGML skiljer sig från Web3D-formaten då det inte i första hand är ett visualiseringsformat utan definierar en stadsmodell med semantiska och topologiska samband för byggnader och den övriga miljön, till exempel vattendrag och träd. 2.4.2 Viktiga framsteg inom tredimensionell visualisering De senaste åren har användandet av GIS bland gemene man ökat dramatiskt. Utvecklingen började med att olika karttjänster, exempelvis eniro.se lanserades under slutet av 1990-talet och sedan följdes av bland annat hitta.se och Google Maps. Tjänsterna gav användarna kostnadsfri tillgång till sökbara kartor och färdplanering. Under de år som har gått har dessa tjänster kommit att bli vardagliga verktyg för de flesta internetanvändare. På senare år har en liknande utveckling påbörjats inom tredimensionell visualisering. Virtuella glober Google köpte 2004 upp företaget Keyhole Inc. som hade tagit fram en applikation kallad Earth Viewer. Denna döptes om till Google Earth (figur 2.4a) och den första versionen som släpptes i Googles regi var Google Earth 3.0 vilken släpptes till Windows i juni 2005. Under de första 15 månaderna laddades Google Earth ner över 100 miljoner gånger (Schöning, Hecht, Raubal, Krüger, Marsh och Rohs, 2008). Det primära filformatet som används i Google Earth heter Keyhole Markup Language, KML (kapitel 2.5.4), men Google Earth klarar även att importera data från olika OGC-tjänster (kapitel 2.6). Sedan Google Earth lanserades har ett antal liknande lösningar presenterats, däribland Microsoft Virtual Earth och Nasa World Wind. Nasa World Wind fokuserar mer mot olika GIS-tillämpningar och inte bara visualisering. Dessutom har man valt att släppa programmet som öppen källkod. Även Web3D Consortium har en aktiv arbetsgrupp X3D Earth där man arbetar med att ta fram en virtuell glob som är öppen programvara och använder sig av öppna standarder. De virtuella globarna har blivit mycket populära och det finns i princip två typiska grupper av användare. Den vanliga medborgaren som fascineras av möjligheten att zooma in från rymden, ända ner till gatunivå och forskare som ser globerna dels som visualiseringssystem för spatial data, dels som ett sätt att få den stora massan mer intresserad av GIS (Schöning m.fl., 2008). 13

KAPITEL 2. TEORI (a) Google Earth (Softpedia.com, 2009) (b) Naturhistoriska riksmuseet i hitta.se 3D (Nyteknik.se, 2008) Figur 2.4 Hitta.se 3D hitta.se klår Google Earth med Saabs nya 3D-teknik NyTeknik 29 maj 2008 Den 29 maj 2008 lanserades en helt ny tjänst på hitta.se. Hela Storstockholm fanns tillgänglig i en navigerbar, tredimensionell webbapplikation (figur2.4b). Materialet var jämfört med existerande tjänster som Google Earth väldigt verklighetstroget, med fotografiska texturer draperade över en terrängmodell där till och med träden fanns med som 3D-objekt. Tjänsten var resultatet av ett samarbete mellan de tre företagen hitta.se, Agency 9 och C3-Technologies AB, ett dotterbolag till Saab AB. Agency 9 stod för den 3D-motor som klienten använder och C3-Technologies är ansvariga för att ta fram materialet. Det kanske mest förbluffande med lanseringen var att allt materialet är automatgenererat med flygfoton som grund. Att flygfotografera det 200 kvadratkilometer stora området hade tagit tre dagar och att från detta material generera 3D-modellen hade tagit ytterligare några dagar (Nyteknik.se, 2008). Tekniken bakom denna datainsamling beskrivs ytterligare i kapitel 2.7.2. 2.5 Data och filformat 2.5.1 VRML / GeoVRML Virtual Reality Modelling Language, VRML är ett filformat för att beskriva tredimensionell data. Tanken var redan från början att formatet skulle kunna användas för att utbyta denna typ av information över internet. Från början togs formatet 14

2.5. DATA OCH FILFORMAT fram av medlemmarna på en e-postlista och man släppte version 1.0 år 1994. År 1996 skapades VRML Consortium för att fortsätta driva utvecklingen och 1997 togs version 2.0 också känd som VRML97 upp som ISO/IEC 14772 (Web3D, 1997). De stora skillnaderna mellan de två versionerna är att den senare tillåter animeringar av objekt samt erbjuder ökad möjlighet att interagera med 3D-scenens olika objekt. En kub kan exempelvis direkt i filen ges egenskapen att förflytta sig fram och tillbaka över ett visst område i en viss hastighet (Carey och Bell, 1997). För att en VRML-fil ska kunna visas i en webbläsare krävs det att ett insticksprogram först installeras. Det finns flera sådana tillgängliga och många av dem klarar flera format som VRML, X3D och GeoVRML. (Shan, 1998) presenterade 1998 den då nya tekniken VRML97 och förespråkar formatet som databärare vid integration mellan CAD, WebbGIS och desktopgis. VRML Consortium bytte 1998 namn till Web3D Consortium och eftersom VRML hade dåligt stöd för geospatial visualisering skapade man samma år arbetsgruppen GeoVRML. Syftet med arbetsgruppen var att ta fram verktyg och rekommendationer för hantering av geospatial data med VRML. GeoVRML 1.0 antogs 5 juni 2000 som Web3D Consortium Recomended Practice, och den 15 juli 2002 släpptes specifikationen för GeoVRML 1.1. Denna version utvecklades parallellt med ett tillägg till VRML standarden (Amd. 1:2002) och de geografiska tillägg som gjordes till VRML är identiska med dem som är beskrivna i GeoVRML 1.1. 2.5.2 X3D Extensible 3D, X3D är ett standardformat (ISO/IEC 19775) för tredimensionell visualisering. Det är baserat på VRML97 och huvudmålet var att dela upp VRML i olika komponenter för att förbättra prestandan. Resultatet blev X3D Core, X3D Interchange, X3D Interactive, X3D CAD-Interchange, X3D Immersive, och X3D Full. Standarden fastslogs 2004 (Web3D, 2004) och ytterligare tillägg görs löpande. X3D har mer eller mindre ersatt VRML och är det av Web3D Consortium rekommenderade 3D-formatet. Följande fördelar av att använda X3D istället för VRML har identifierats av (Ming, 2008) och (Beard, 2006): X3D är modulärt, och man behöver endast ladda de komponenter som man använder. X3D har ett enhetligt API för att påverka scenen genom sitt Scene Authoring Interface, SAI. X3D kan lagras, i VRML-syntax, som XML-dokument eller i ett binärt format som lämpar sig bättre för komprimering. X3D är XML-kompatibelt vilket underlättar integration med övriga system. 15

KAPITEL 2. TEORI 2.5.3 GML Geography Markup Language, GML är ett XML-baserat filformat standardiserat av OGC (OGC, 2007b) för att representera geografisk information. I huvudsak används formatet som ett transportformat för webbtjänster. 2.5.4 KML Keyhole Markup Language, KML är ett XML-baserat format som ursprungligen togs fram av Keyhole Inc. för Earth Viewer, senare Google Earth (kapitel 2.4.2). När Google köpte Keyhole fick de rättigheterna till formatet och valde att föreslå formatet som en möjlig OGC-standard för geospatial visualisering. KML version 2.2 antogs 2007 (OGC, 2007c) och använder sig av geometriska element som är hämtade från GML 2.1.2 som ett steg i att harmonisera KML med GML och övriga OGC standarder. Dessa element är: point, line string, linear ring och polygon. 2.5.5 CityGML City Geography Markup Language, CityGML är ett XML-baserat filmformat, implementerat som ett applikationsschema för GML 3.1.1. Syftet med formatet är att kunna beskriva enskilda byggnader såväl som hela städer med tillhörande terräng, vegetation, vattendrag och stadsföremål såsom lyktstolpar, skyltar och brevlådor. Arbetet med CityGML påbörjades 2002 av Special Interest Group 3D, SIG 3D och den 12 juli 2007 antogs CityGML 0.4 som ett OGC Best Practices Paper (OGC, 2007a) och blev därmed OGC:s officiella val rörande stadsmodellering. CityGML 1.0.0 antogs sedan som en officiell OGC standard 20 augusti 2008 (OGC, 2008). I CityGML finns en visualiseringsmodell som är baserad på X3D och Collada genom vilken man kan definiera vilken färg eller vilka texturer som ska appliceras på en yta. Dessa gör att det är möjligt att visualisera CityGML komplett med texturer trots att det i första hand inte är ett visualiseringsformat. En egenskap som särskiljer CityGML mot andra 3D-format är att det inte bara hanterar utseende och geometrier utan även semantik och topologi (Kolbe, 2009). Till exempel kan en byggnad modelleras så att den består av ett antal delelement (figur2.5). Resultatet av denna modellering blir att man kan välja en vägg, ett fönster eller annan byggnadsdel och få information om vilken byggnad som byggnadselementet tillhör. I CityGML finns fem detaljnivåer, Level of Detail, LOD (figur 2.6a, tabell 2.3). Dessa gör det möjligt att definiera flera geometrier i olika detaljnivåer för varje feature. Klienten kan sedan välja att visa en enklare geometri då kameran befinner sig långt borta från denna feature för att sedan visa en mer detaljerad geometri när kameran närmar sig den (figur 2.6b). Under OGC:s test och demonstrationsprojekt OGC Web Services, Phase 4 genomfördes en fiktiv räddningsaktion där en radioaktiv bomb har exploderat i en amerikansk hamn. Situationen kräver att olika byggnader utvärderas för att finna en som lämpar sig som fältsjukhus. Genom hela scenariot kommunicerar olika sy- 16

2.5. DATA OCH FILFORMAT Figur 2.5: Exempel på hur en byggnad kan vara uppbyggd i CityGML (Capstick, 2008) LOD 1 LOD 2 LOD 3 LOD 4 LOD 5 Endast terrängmodell. Enkla boxbyggnader. Byggnader med takytor. Detaljerade byggnader med: fönster, dörrar, balkonger med mera. Byggnaders interiör, med rum och dörröppningar. Tabell 2.3: Detaljnivåer i CityGML stem med varandra över OGC:s webbstandarder. I processen att hitta en passande byggnad på säkert avstånd från den radioaktiva röken används en WFS-server (kapitel 2.6.2), GoPublisher, från Snowflake Software (Curtis, 2008) för att begära byggnader som ligger inom säkert avstånd och har en viss minimistorlek. Byggnaderna levereras i CityGML och fortsatt analys av byggnaderna utförs i ett grafiskt program kapabelt att visualisera CityGML. När en byggnad valts ut skickas dess Building Information Model, BIM till en sjukhusarkitekt som i ett CAD-program inreder byggnaden för dess nya syfte som sjukhus. Den modifierade BIM-filen skickas sedan vidare till de personer som ansvarar för att bygga upp fältsjukhuset. De tekniska problem som Snowflake ställdes inför när de skulle ta fram en WFSserver för att leverera CityGML var: CityGML använder sig mycket av komplexa feature-types. En byggnad består exempelvis av en eller flera byggnadsdelar. En byggnadsdel består i sin tur av en eller flera ytor (takytor, väggytor), som i sin tur kan innehålla fönster och dörrar. På detta sätt kan varje byggnad bestå av väldigt djupa hierarkier. Det normala vid den här tiden var dock att WFS-servrar endast klarade enkla 17

KAPITEL 2. TEORI (a) Detaljnivåerna tillgängliga i CityGML (b) Varierande detaljnivå beroende på avståndet till kameran Figur 2.6: Detaljnivå i CityGML (Kolbe och Bacharach, 2006) feature-types som mappar direkt mot en tabell i databasen. De datatyper som finns i databasen (i detta fallet Oracle Spatial) är mer begränsade än de som används i CityGML. Det finns till exempel ingen motsvarighet till 3D solid för att göra solida kroppar CityGML-filer som innerhåller mycket och detaljerad data tenderar att bli stora, med lång laddningstid som följd. Det data som användes under scenariot konverterades från ett CAD-program till CityGML genom ett specialskrivet program och laddades sedan in i en Oracle Spatial databas med Snowflakes GoLoader, ett program som läser GML och lagrar denna i en relationsdatabas. Vid anrop till servern körs motsvarande konvertering i andra riktningen för att generera CityGML till klienten. Man implementerade komprimering genom zip/gzip för att minska mängden faktisk data som måste överföras till klienten och tack var detta kunde laddningstiden för en väldigt detaljerad helikopter sänkas från 9 minuter till 20 sekunder genom att den överförda datamängden minskades från 24.5MB till 1.3MB (Curtis, 2008). (Wan och Bian, 2007) tycker att utvecklingen av Webb3DGIS har fokuserat för mycket på enbart visualisering och lyfter fram Google Earth och Microsoft Earth som exempel på detta. De anser att detta begränsar tjänsterna genom att omöjligöra analytiska undersökningar/beräkningar i klienten. Istället föreslår de att CityGML bör användas som bärare av både utseende och uppbyggnad i Webb3DGIS. 2.6 OGC:s webbtjänster OGC har specificerat ett 40-tal standarder däribland ett stort antal webbtjänster. Gemensamt för dessa är att de antingen kan anropas med Key value pairs KVP, där en vanligt webb-url med parametrar på formen parameter=värde används 18

2.6. OGC:S WEBBTJÄNSTER eller via ett webbtjänstprotokoll där anrop och svar förmedlas i form av XML. Trots att det i en applikation vore fullt möjligt att manuellt skapa alla anrop till tjänsterna genom att formatera dem som KVP- eller XML-strängar och manuellt hantera kommunikationen mot servern så är detta i större program inte effektivt. Därför används istället med fördel ett bibliotek som abstraherar tjänsterna till ett API för det programmeringsspråk som man använder för att bygga applikationen. För Javascript erbjuder till exempel OpenLayers ett sådant API. 2.6.1 WMS Web Map Service Web Map Service, WMS (OGC, 2004) definierar en tjänst genom vilken kartbilder i två dimensioner kan begäras. Kartbilderna sätts samman genom att kombinera de raster och vektorlager som användaren av tjänsten har begärt samt applicera eventuella ritmanér på dessa. De olika lagren slås samman till en bild som beskärs för att passa det område som efterfrågas och returneras till klienten som ett raster, exempelvis i form av en JPG-fil. 2.6.2 WFS/WFS-T Web Feature Service WMS (kapitel 2.6.1) erbjuder visualisering av geografisk data i form av ett raster, men i många applikationer behöver användarna även kunna manipulera den data som finns i databasen. Web Feaure Service, WFS (OGC, 2005b) erbjuder ett gränssnitt för att söka efter, editera och ta bort features som finns i databasen. För att söka efter de features som användaren är intresserad av har WFS ett väl utbyggt stöd för filtrering där man kan filtrera på en eller flera av följande egenskaper tillsammans med logiska operationer (och, eller, inte) samt jämförelseoperationer (< = >!): Icke-spatiala datafält exempelvis namn eller antal invånare. Spatiala jämförelser, exempelvis alla element innanför/utanför en viss polygon. Feature types, exempelvis ge mig alla features av feature-type väg. ID som direkt refererar en feature. Nedan följer ett antal exempel på hur anrop till en WFS-server kan se ut. Servern översätter anropet och eventuella filter till SQL-frågor som ställs mot databasen. Dessa exempel är något förenklade för att öka läsbarheten och de är helt eller delvis hämtade från implementationsspecifikationen av WFS (OGC, 2005b). 19

KAPITEL 2. TEORI För att få fram alla features som är av feature type inwatera_1m och som ligger inom området definierat av punkterna lowercorner och uppercorner kan följande KVP-anrop användas. h t t p : //www. someserver. com/ wfs. c g i& SERVICE=WFS& VERSION=1.1.0& REQUEST=GetFeature& TYPENAME=InWaterA_1M& FILTER= <F i l t e r> <Within> <PropertyName>InWaterA_1M/wkbGeom<PropertyName> <gml:envelope> <gml: lowercorner>10 10<gml: lowercorner> <gml:uppercorner>20 20</ gml:uppercorner> </ gml:envelope> </ Within> </ F i l t e r> eller motsvarande XML: <?xml version=" 1. 0 "?> <wfs:getfeature version=" 1. 1. 0 " s e r v i c e="wfs" ( xmlns... )> <wfs:query typename=" InWaterA_1M"> <o g c : F i l t e r> <ogc: Within> <ogc:propertyname>inwatera_1m/wkbgeom<ogc:propertyname> <gml:envelope> <gml: lowercorner>10 10<gml: lowercorner> <gml:uppercorner>20 20</ gml:uppercorner> </ gml:envelope> </ ogc: Within> </ o g c : F i l t e r> </ wfs:query> </ wfs: GetFeature> Genom att ändra REQUEST till Transaction och lägga till parametern Delete kommer de features som har hittats med filtret tas bort: <?xml version=" 1. 0 "?> <w f s : T r a n s a c t i o n version=" 1. 1. 0 " s e r v i c e="wfs" ( xmlns... )> <w f s : D e l e t e typename="inwatera_1m"> <o g c : F i l t e r> <ogc: Within> <ogc:propertyname>inwatera_1m/wkbgeom<ogc:propertyname> <gml:envelope> <gml: lowercorner>10 10<gml: lowercorner> <gml:uppercorner>20 20</ gml:uppercorner> </ gml:envelope> </ ogc: Within> </ o g c : F i l t e r> </ w f s : D e l e t e> </ w f s : T r a n s a c t i o n> På liknande sätt går editering till, med skillnaden att operation blir Update och att de nya värdena, tillsammans med information om vilken parameter som ska uppdateras skickas med. I detta fall har en specifik feature filtrerats ut genom GmlObjectId = BuiltUpA_1M.10131. <?xml version=" 1. 0 "?> <w f s : T r a n s a c t i o n version=" 1. 1. 0 " s e r v i c e="wfs" ( namespaces... )> <wfs:update typename=" BuiltUpA_1M "> <w f s : P r o p e r t y> <wfs:name>population</ wfs:name> <wfs: Value>4070000</ wfs: Value> </ w f s : P r o p e r t y> <o g c : F i l t e r> <ogc:gmlobjectid gml: id=" BuiltUpA_1M. 10131 " /> </ o g c : F i l t e r> 20

2.6. OGC:S WEBBTJÄNSTER </ wfs:update> </ w f s : T r a n s a c t i o n> Som sista exempel visas hur en ny feature skapas vars geometri är en LinearRing (en linje där start och slutpunkt är samma punkt och linjen aldrig korsar sig själv). <?xml version=" 1. 0 "?> <w f s : T r a n s a c t i o n version=" 1. 1. 0 " s e r v i c e="wfs" ( xmlns... )> <w f s : I n s e r t idgen=" UseExisting "> <InWaterA_1M g m l : i d="inw1"> <wkbgeom> <gml:polygon g m l : i d=" P1"> <g m l : e x t e r i o r> <gml: LinearRing> <g m l : p o s L i s t> 98.54 24.26.. 98,54 24.26</ g m l : p o s L i s t> </ gml: LinearRing> </ g m l : e x t e r i o r> </ gml:polygon> </wkbgeom> <id>150</ id> <f_code>abcde</ f_code> <hyc>152</ hyc> <t i l e I d>250</ t i l e I d> <f a c I d>111</ f a c I d> </InWaterA_1M> </ w f s : I n s e r t> </ w f s : T r a n s a c t i o n> 2.6.3 WTS Web Terrain Service Web Terrain Service, WTS är en föreslagen standard för att över en webbtjänst begära en bild av en tredimensionell scen. Tanken är att låta en kraftfull server generera ett foto av scenen, bestående av många ingående komponenter (figur 2.7), som sedan enkelt kan visas för användaren i dennes webbläsare. Protokollet finns för tillfället beskrivet i ett OGC-dokument av typen diskussionsartikel/förslag framtagen 2001 (OGC, 2001). Vid anrop används ett antal parametrar beskrivna i tabell 2.4 för att bestämma kamerans position i den tredimensionella världen. WTS kallas även ibland Web Perspective View Service, WPVS då detta namn bättre beskriver vad tjänsten egentligen erbjuder. POI Pitch Distance Yaw Angel of View Koordinater för en point of interest -punkt. Denna punkt bestämmer punkten i vilken kameran fokuserar. Vinkel mellan kameran och POI, 90 grader innebär att kameran ser rakt ner på POI. Avstånd från kameran och POI-punkten. Vinkeln runt den vertikala axeln av POI ( åt vilket håll är norr ). Bestämmer hur brett synfält kameran har. Tabell 2.4: Obligatoriska parametrar vid anrop av WTS-tjänst 2.6.4 W3DS Web 3D Service Web 3D Service, W3DS är en föreslagen standard där man över en webbtjänst kan begära en tredimensionell scen för rendering i klienten. Den stora skillnaden jämfört 21

KAPITEL 2. TEORI Figur 2.7: W3DS och WTS/WPVS använder flera olika komponenter för att sätta samman en tredimensionell scen (OGC, 2005a) med WTS/WPVS är att resultatet inte bara är en tredimensionell bild utan en scen som kan renderas i en 3D-kompatibel klient och som då tillåter användaren att röra sig runt i scenen. Protokollet är för tillfället beskrivet i ett OGC dokument av typen diskussionsartikel/förslag framtagen 2005 (OGC, 2005a) och beskriver hur tjänsten ska anropas samt hur resultatet från denna ska returneras. Parametrarna som krävs vid anropet är samma som i WTS (tabell 2.4) samt en boundingbox som definierar scenens område. W3DS samlar på samma sätt som WTS/WPVS in olika typer av data och genererar en scen av dessa (figur 2.7). Skillnaden är att W3DS inte renderar scenen så som WTS/WPVS gör utan returnerar denna som en scengraf i något av formaten X3D, VRML eller GeoVRML. Projekt som använt W3DS Trots att W3DS inte är någon antagen standard har protokollet implementerats i flera olika projekt och framförallt i Tyskland har mycket forskning bedrivits på Bonns universitets geografiska avdelning. Här har arbetet med att ta fram en komplett lösning för lagring och visualisering av stora städer pågått under lång tid och (Kulawik, Schilling och Zipf, 2009) förklarar att det finns två alternativ om man vill använda OGC-standarder för att skicka tredimensionell data, antingen CityGML över WFS eller VRML/X3D över W3DS. De anser att CityGML i första hand inte är lämpligt för visualisering då formatet bygger på XML och innebär att större datamängder måste överföras då semantik och topologi ska representeras. Av denna anledning har de valt att implementera en W3DS/VRML-tjänst med tillhörande Java-klient, som startas via Java Web Start, för att visualisera staden Heidelberg 22

2.6. OGC:S WEBBTJÄNSTER (Kulawik m.fl., 2009) och data från OpenStreetMap (OpenStreetMap 3D, 2009). (Kulawik m.fl., 2009) beskriver även den programvara som har tagits fram för att importera och förenkla CityGML-data för import i den geodatabas som används. För att hålla ner storleken på data reduceras byggnadernas alla delar till en eller ett fåtal geometrier som lämpar sig bättre för visualisering. För staden Bonn lyckas man därigenom reducera datamängden från 722MB till 136MB. Den 19 mars 2009 presenterades osm-3d.org där Heidelbergprojektet har använts för att visualisera en tredimensionell version av OpenStreetMap täckande hela Tyskland. Även företaget och OGC-medlemmen Con Terra har publicerat en W3DS genom vilken en terrängmodell kan begäras. (a) Illustration av problem som uppkommer vid sce-(bnerepresentation och utzoomning ka tiles som ska förberäknas QuadTree modell, samt metod att välja vil- Figur 2.8: (Misund m.fl., 2005) Kritik mot W3DS Trots att W3DS har använts med lyckat resultat i flera projekt ifrågasätter (Misund, Granlund och Kolås, 2005) varför det äldre filformatet VRML är obligatoriskt och föreslår istället att det bättre lämpade X3D bör vara det föredragna formatet. De anser även att modellen där klienten begär en scen genom att ange en boundingbox inte är optimal då användaren med denna får problem att zooma ut från området för att se vad som finns utanför detta (figur 2.8a). Istället tror de att användaren vill kunna zooma in och ut obegränsat och föreslår därför möjligheten att representera den visualiserade världen med en glob som den yttersta nivån (kapitel 2.4.2). Själva problemet med att inte kunna zooma ut anser de vara beroende på att VRML är vagt specificerat rörande hur LOD ska hanteras. Användaren skulle annars kunna begära en boundingbox som innehåller ett större område men som i utzoomat läge endast visar en enklare representation, för att sedan bli mer detaljerat när man zoomar in. (Misund m.fl., 2005) presenterar en lösning som använder sig av mindre scener som laddas individuellt för att sedan kombineras i den slutgiltiga scenen på samma sätt som tvådimensionella kartsystem brukar göra med kart-tiles. De visar 23

KAPITEL 2. TEORI att en enkel quadtreemodell (figur 2.8b) kan användas för att definiera hur dessa tiles kan hämtas hem, samt hur förhämtning av tiles kan gå till. Vidare säger de att det är av stor vikt att att alltid kunna begära en tile i ett högre lager än vad man befinner sig i. (Wan och Bian, 2007) anser att det är konstigt att W3DS endast definierats för tredimensionell visualisering och efterfrågar en standard där både visualisering och topologi kan hanteras. 2.7 Modellering av byggnader i 3D An intuitive and easy-to-use 3D modeling system has become more crucial with the rapid growth of computer graphics in our daily lives 2.7.1 Manuell modellering Sebe, You och Neumann (2005) Traditionellt har arbetet med att skapa tredimensionella modeller skötts av digitala konstnärer och brukar ta timmar av manuellt arbete i anspråk (Sebe, You och Neumann, 2005). Trots att manuell modellering möjliggör väldigt detaljerade modeller är det dock vanligt att dessa generaliseras av tidsskäl. De mest använda verktygen vid modellering idag är CAD och 3D-modelleringsprogram. Dessa är ofta byggda för professionella användare och har därför en hög inlärningströskel. Google köpte 2006 upp företaget @Last Software och fick därmed rättigheterna till programmet SketchUp, ett kraftfullt (figur 2.9a) men ändå relativt användarvänligt modelleringsprogram. En stor del av användarvänligheten kommer ifrån den patenterade Push/Pull tekniken, som tillåter användaren att först dimensionera ett objekt i två dimensioner för att sedan dra ut det i den tredje med endast en knapptryckning. Det finns många olika sätt för en applikation att underlätta för användaren att skapa 3D-modeller. Exempelvis ger (Zeleznik, 1998) ett exempel där ett rätblock skapas genom att rita tre vinkelräta linjer som möter varandra i samma punkt. Programmet hjälper sedan användaren genom att automatiskt skapa de resterande kanterna. Ett annat hjälpmedel som (Zeleznik, 1998) beskriver är att endast tillåta användaren att rita sådana former som är tillåtna i den aktuella applikationen. Om man exempelvis modellerar byggnader kan det vara en tanke att endast tillåta raka linjer och bågar. (Zeleznik, 1998) har även visat genom försök att det är svårt för användare att rita korrekta modeller med god precision i en tredimensionell vy. Modellera genom att kombinera Att modellera enklare geometrier och kroppar är för de flesta användare svårt på grund av att de verktyg som finns tillgängliga är svårhanterade. Om man dessutom vill modellera mer komplexa objekt exempelvis byggnader med balkonger, utsmyckningar, specialfönster och så vidare stöter man på ytterligare ett problem. De flesta 24

2.7. MODELLERING AV BYGGNADER I 3D användare är inte speciellt estetiskt lagda och kommer därför inte kunna bygga komplexa modeller som ser verklighetstrogna ut. Ikea har löst detta i sin kökseditor genom att alla Ikeas produkter finns tillgängliga som 3D-modeller. Det finns alltså inget behov av att modellera en diskho. Istället drar användaren in den diskho som han/hon vill använda och monterar denna i sin diskbänk. Denna lösning innebär dock att det inte är möjligt för användaren att inkludera en konkurents diskho i det kök som han/hon modellerat, då denna inte finns tillgänglig i Ikeas editor. (Funkhouser, Kazhdan, Shilane, Min, Kiefer, Tal, Rusinkiewicz och Dobkin, 2004) har istället tänkt sig problemet lite annorlunda. Även de erbjuder användaren en uppsjö olika 3D-modeller och användaren kan sedan välja de delar från varje modell som passar in i den vision som användaren vill bygga. Arbetsprocessen går ut på att man klipper ut de delar av en 3D-modell som man tycker om och använder dessa som byggklossar för att bygga upp en helt ny modell (figur 2.9b). Nackdelen med denna lösning är att det totala antalet möjliga modeller som kan konstrueras är beroende på antalet modeller som användaren tillåts välja bland. 2.7.2 Automatisk modellering Kan man utgå från en mänsklig tvådimensionell skiss och av denna skapa en tredimensionell modell? (Karpenko och Hughes, 2006) presenterar en lösning som klarar av att hitta dolda konturer och därmed göra kvalificerade gissningar av hur den tredimensionella kroppen som användaren avsåg ser ut (figur 2.9c). På så sätt kan ett objekt tas fram baserat endast på en tvådimensionell kontur. Metoden är dock väldigt begränsad och hanterar inte komplexa konturer speciellt väl. Resultatet är dessutom i första hand att betrakta som en utgångspunkt för vidare modellering då det är baserat på en oprecis skiss med vaga måttangivelser i djupled. Även (Cherlin, Samavati, Sousa och Jorge, 2005) har valt att ta fram en lösning för modellering baserat på enklare skisser. Denna är inspirerad av tre traditionella teckningstekniker som används för att införliva djup i bilder (figur 2.9d). Lösningen har flera faser där man först skapar en initial modell från skissen. Algoritmen känner igen vissa instruktioner i denna, där exempelvis en svängd båge över två parallella linjer innebär att man ritat en cylinder (se svärdet i figur 2.9d). I editeringsläget tillåts användaren sedan att deformera och utöka modellen tills en passande 3Dmodell är framtagen. I Sverige har alla kommuner i sina baskartor information som beskriver byggnadsytor, och ibland även byggnadshöjd och taktyp. Om sådan information finns tillgänglig föreslår (Misund m.fl., 2005) att man kan använda denna till att ta fram 2,5-dimensionella byggnadsmodeller. Detta görs genom att resa väggar från byggnadsytorna med den höjd som finns lagrad för byggnaden och lägga på en plan yta som tak. På så vis kan byggnader på ett ekonomiskt sätt förberedas för tredimensionell visualisering. Om man dessutom vet vilken typ av tak en byggnad har, valt från en fördefinierad mängd taktyper, kan huset lika enkelt modelleras med lägre vägghöjder och ett riktigt tak. 25

KAPITEL 2. TEORI (a) Bil modellerad i Google Sketchup (Wikipedia, 2008) (b) Två 3D-objekt skapade helt genom att kombinera delar från andra 3D-modeller (Funkhouser m.fl., 2004) (c) Exempel på hur skisser kan användas som grund(d) Exempel på hur skisser kan användas som grund till 3D-modellering (Karpenko och Hughes, 2006) till 3D-modellering (Cherlin m.fl., 2005) Figur 2.9 C3-Technologies Ett av de främsta exemplen på automatisk 3D-modellering är C3-Technologies teknik för att automatgenerera en terrängmodell. Ursprungligen kommer tekniken från Saab som tog fram den för digital navigering av robotar och andra vapensystem. År 2007 knoppades företaget C3-Technologies av från Saab med syftet att ta fram civila tillämpningar och man har sedan dess jobbat med att förfina tekniken. Målet är att kunna få fram en så realistisk tredimensionell modell som möjligt. Den tredimensionella terrängmodellen tas fram genom en helautomatisk process baserat enbart på flygbilder vilket ger en mycket ekonomisk modellering av städer som annars brukar modelleras manuellt för exempelvis Google Earth (Nyteknik.se, 2008). 26

2.7. MODELLERING AV BYGGNADER I 3D (a) Scen i Google Earth från Hamburg (b) Scen över Helsingborg från C3-Technologies Figur 2.10: Skillnader mellan Google Earth och C3 (C3-Technologies, 2008c) Data samlas in genom att man flyger på 600 meters höjd med flygplan som bär ett flertal högupplösta kameror samt en GPS. Kamerorna är noga kalibrerade mot varandra vilket gör att x, y och z-positionen för varje bildpixel i det resulterande materialet kan bestämmas med decimeterprecision (C3-Technologies, 2008b). När allt fotomaterial är insamlat automatgenereras höjdmodellen och de bästa bilderna för varje bildpixel i fotomaterialet kombineras till en bild som draperas ovanpå terrängen. Detta innebär att ett enda hus kan bestå av pixlar från upp till 25 olika bilder (Hitta.se, 2008). Det resulterande materialet är en tämligen verklighetstrogen tredimensionell modell (figur 2.4b, 2.10b). Då man baserar höjdmodellen på fotografier får man även bonuseffekten att vegetation, klippor och andra naturliga element inkluderas i modellen och de objekt som mer eller mindre saknar höjd, såsom båtbryggor, refuger med mera ändå blir igenkänningsbara i modellens fototextur, vilket ytterligare förstärker realismen. I fallet med manuella modelleringar väljer man oftast att fokusera på exempelvis byggnader och låta vegetation och andra element ligga kvar i terrängens textur vilket i jämförelse med C3:s modeller ger ett enklare intryck (figur 2.10). Det är också vanligt vid manuell modellering att man av tids- och kostnadsskäl fokuserar på intressanta områden såsom stadskärnor och välkända byggnader medan C3:s teknik tillåter att större områden flygs in. Exempelvis hade ett 200 kvadratkilometer stort område flugits när Stockholm släpptes på hitta.se (Hitta.se, 2008), och i dag finns bland annat städerna Stockholm, Göteborg, Malmö, Linköping, Helsingborg och Norrköping tillgängliga, vilket i praktiken vore omöjligt med manuell modellering. Problem och nackdelar Vid genereringen av terrängmodellen kan ibland byggnader tolkas felaktigt och exempelvis är både Kaknästornet och Mariahissen i Stockholm kraftigt deformerade på hitta.se 3D. Systemet har även svårt att få till räta vinklar och speciellt på lägre byggnader produceras ofta oregelbundna högar. Den största nackdelen med C3-Technologies är dock att det data som samlas in 27

KAPITEL 2. TEORI Figur 2.11: Texturens betydelse i C3-Technologies data (C3-Technologies, 2008a) enbart går att använda för visualisering då det i grunden bara är en terrängmodell i vilken semantiska begrepp för exempelvis byggnader helt saknas. Modellen är dessutom mycket beroende av texturen och utan denna är det i terrängmodellen mycket svårt att se var en byggnad börjar och nästa tar vid samt att särskilja småbyggnader från vegetation (figur 2.11). 28

Kapitel 3 Metod Arkitekturmässigt har författaren valt att använda samma grundläggande design som Gismo (kapitel 1.3). Detta innebär en webbaserad klient som begär 3D-data från en server, vilken i sin tur läser upp information från en PostgreSQL/PostGISdatabas, och levererar denna i det format som klienten förväntar sig (figur 3.1). I figuren är tre ord: Klient, Protokoll och Format markerade. Dessa komponenter är relativt fristående och det existerar ett antal olika alternativ för var och en av dem. I detta kapitel presenteras hur de olika alternativen har valts ut, den beslutsmodell som har använts i kapitel 4.1 för att bestämma kombinationen av dem samt den utvecklingsmetodik som har använts vid framtagandet av prototypen i kapitel 4.2. Figur 3.1: Översiktlig arkitektur av prototypen 3.1 Val av tekniska alternativ Urvalet av de tekniska alternativen utfördes av författaren och baserades på vetenskapliga artiklar, besök på konferenser, informella diskussioner med utvecklare, samt studier av tillgängliga programbibliotek och projekt publicerade på internet. 29

KAPITEL 3. METOD 3.2 Undersökning Mjukvaruutveckling i grunden är en osäker och oförutsägbar sysselsättning (Büuyüközkan och Ruan, 2007). Detta beror dels på interna och externa risker av olika typer, dels på att det oftast finns ett större antal intressenter i projektet i form av exempelvis projektmedarbetare, projektledare, beställare och styrgruppsrepresentanter. Var och en adderar sin kompetens, erfarenhet och egna synsätt till projektet, men har också ett eget mål, egna värderingar och egna sätt att vilja lösa problem på (Tonnquist, 2006). Av denna anledning når man sällan fram till beslut som alla intressenter anser vara optimala utan måste istället enas om en kompromiss. 3.2.1 Multikriterieanalys Vid komplexa beslut rörande många möjliga alternativ blir det allt svårare att nå en kompromiss då intressenterna har svårare att få översikt över de tillgängliga alternativen, och deras för- respektive nackdelar. Det samma gäller då många personer ska vara delaktiga i beslutprocessen speciellt om de kommer från skilda intressesområden (Mendoza, Macoun, Prabhu, Sukadri, Purnomo och Hartanto, 1999). En vanlig lösning är att tillsätta en mindre arbetsgrupp som sätter in sig i det aktuella problemet och själva väljer lösning. Detta kan resultera i ett väl underbyggt beslut men det kommer innebära att ett färre antal personer har varit involverade. Genom att låta arbetsgruppen förbereda ett antal alternativ kan ett majoritetsbeslut avgöra vilket av alternativen som ska väljas. Denna lösning innebär i och för sig att alla beslutande får vara delaktiga i beslutet men risken är dock stor att beslutet kommer att vara färgat av de personer som ingår i arbetsgruppen. Strukturerade beslutsmetoder är väl lämpade att användas vid beslut med många alternativ och/eller då antalet intressenter är stort. Beslutet nås genom att följa formella metoder som är väl definierade vilket innebär att alla intressenter kan sätta sig in i metoden och dess olika steg. Detta resulterar i ökad insyn vilket i sin tur kan resultera i större tillit till beslutsprocessen och det beslut som faller ut (Danielsson, Ekenberg, Ekengren, Hökby och Lidén, 2008). En vanlig form av strukturerade beslutstöd är multikriterieanalys, Multi Critera Decision Making, MCDM. Denna typ av beslutsstöd har utvecklats till ett eget forskningsområde med en intresseorganisation International Society on Multiple Criteria Decision Making med 1470 medlemmar i 96 länder. Organisationen definierar MCDM som: MCDM can be defined as the study of methods and procedures by which concerns about multiple conficting criteria can be formally incorporated into the management planning process International Society on Multiple Criteria Decision Making Det finns väldigt många olika beslutsmetoder som faller inom denna definition, exempelvis beskriver (Danielsson m.fl., 2008) en beslutsprocess i Nacka kommun 30

3.2. UNDERSÖKNING där tre oberoende beslut gällande avlopp, vägar samt en båthamn för båtpendlare ska fattas. Då frågan bland intressenterna hade blivit mycket laddad valde man att använda sig av en utökad form av MCDM, Analytic Decision Layer, ADL som är relativt formell, ger god insyn och kräver att intressenterna är nära involverade i flera olika faser av analysen. För denna studie har en mindre komplex metod valts ut (RFP Evaluation Centers Inc., 2009), vilken beskrivs i ett enkelt exempel under Metodbeskrivning. Anledningen till att denna metod valdes var att undersökningens syfte är att låta fyra intressenter tillföra sina åsikter och därmed vara delaktiga i beslutet om prototypens tekniska grund. Det finns inte speciellt många intressenter och det förekommer inte några konflikter mellan dessa och därför anser inte författaren att en formellare metod krävs. Det faktum att två av de fyra intressenterna under våren har haft väldigt lite tid tillgängligt, skulle även ha gjort att en mer formell metod hade varit omöjlig att genomföra då den hade krävt mer involvering av alla intressenter. Metodbeskrivning Detta exempel visar hur en enkel analys där två personer gemensamt ska välja transportmedel för en resa mellan Stockholm och Göteborg kan gå till. Författaren har valt att frångå (RFP Evaluation Centers Inc., 2009) sätt att skapa en ensam matris kallad Decision Matrix som innehåller alla parametrarna värdering, viktning och resultat och i stället skapa en matris för varje parameter. Anledningen till detta är att resultatet från flera analyser baserade på olika grupperingar av intressenterna tydligare kan presenteras. Lokalisera vilka alternativ som finns. På sträckan Stockholm-Göteborg finns följande tre alternativ: bil, tåg och flyg. Identifiera ett antal oberoende kriterier som alla intressenter är överens om. Det är viktigt att antalet kriterier inte är större än att intressenterna klarar av att avgöra deras vikt. I detta exempel väljs: låg kostnad, kort restid och miljövänlig resa. Ta nu fram en värderingsmatris med kriterierna längs en dimension och alternativen längs den andra. Matrisen fylls i genom att för varje alternativ välja ett värde från ett förutbestämt intervall som indikerar hur väl alternativet uppfyller de olika kriterierna. I detta exempel används intervallet [0..5] där 0 innebär att alternativet inte alls lever upp till kriteriet och 5 innebär att alternativet helt uppfyller kriteriet. Resultatet av värderingen finns i tabell 3.1a. Denna värdering kan antingen utföras tillsammans med intressenterna, som till exempel görs i ADL (Danielsson m.fl., 2008), eller av en person eller arbetsgrupp som står utanför beslutet och besitter expertkunskap rörande alternativen. 31

KAPITEL 3. METOD Bil Tåg Flyg Låg kostnad 3 4 1 Kort restid 1 3 5 Miljövänlig 2 4 0 (a) Värderingsmatris, varje värde indikerar hur väl ett attribut uppfyller ett kriterium Pers.A Pers.B Medel Låg kostnad 1 1 1 Kort restid 1 4 2,5 Miljövänlig 3 0 1,5 (b) Resultatet av beslutfattarnas viktning Tabell 3.1 Det är nu dags för intressenterna att bidra. Deras uppgift är att vikta de olika kriterierna, det vill säga, att ange hur viktigt varje kriterium är jämfört med de andra. I exemplet finns två intressenter och de har fått fem poäng var att placera ut på de tre kriterierna. Antalet poäng att placera är valt som Antalkriterier 1 för att undvika att intressenterna ger samma vikt till alla kriterier. Resultatet av Person A och Person B:s viktningar ses i tabell 3.1b. För att kunna ta fram ett beslut där båda personernas åsikter är sammanvägda har även medelvärdet av deras viktningar beräknats. Tydligt är att Person A i första hand vill vara miljövänlig, medan Person B i första hand vill ha en kort restid. I intressenternas medel kombineras dessa önskningar och fokus ligger där vid kort restid följt av att vara miljövänlig. I värderingsmatrisen 3.1a är det tydligt att flyget erbjuder den kortaste restiden men inte alls är miljövänligt. Bil Tåg Flyg Låg kostnad 3 4 1 Kort restid 2,5 7,5 12,5 Miljövänlig 3 6 0 Summa 8,5 17,5 13,5 (a) Medelvärde av Person A och B Bil Tåg Flyg Låg kostnad 3 4 1 Kort restid 4 12 20 Miljövänlig 0 0 0 Summa 7 16 21 (b) Person B Tabell 3.2: Slutgiltiga resultatmatriser I det sista steget multipliceras värdena från medelvärdeskolumnen i tabell 3.1b med värdena från tabell 3.1a vilket resulterar i tabell 3.2a. Genom att summera kolumnerna fås resultatet att intressenterna har valt tåget som sitt transportmedel till Göteborg. De båda personerna kan även vara överens att de har fått vara lika delaktiga i beslutet då de endast har angivit hur viktigt de anser att tre olika kriterier är. Figur 3.2b visar på ett överskådligt sätt hur de olika kriterierna har spelat in i beslutet, exempelvis hade bil och flyg lika höga poäng efter värderingen (figur 3.2a), men flyg får ett stort övertag över 32

3.3. UTVECKLINGSMETODIK bil när intressenternas viktning appliceras. Genom att göra samma beräkningar på Person B:s viktningar fås i tabell 3.2b resultatet att han istället hade valt att flyga, och det är tydligt att detta beslut nästan enbart är beroende på kriteriet kort resa (figur 3.2c). (a) Värdering av alternativ mot kriterierna (b) Resultat medel Figur 3.2 (c) Resultat person B 3.3 Utvecklingsmetodik Agila metoder är ett samlingsnamn för utvecklingsmetodiker som tagits fram som svar på vattenfallsmodellen och andra metoders tunga kravinsamling- och planeringsfaser samt deras problem med att hantera förändringar i kravbilden. De agila metoderna kännetecknas av kortare iterativa utvecklingsfaser, ofta kallade sprintar, att man har tät kontakt med beställaren och oftare gör mindre delleveranser istället för en stor leverans efter lång tids arbete (Ferreira och Cohen, 2008). Utvecklingen av prototypen kommer i denna studie bedrivas iterativt med många små delmål för att kunna hantera eventuella förändringar som kan ske, men då författaren är ensam utvecklare kommer ingen formell metodik att användas. 33

Kapitel 4 Genomförande 4.1 Utförd undersökning Då målet med denna studie är att begränsa sig till teknik som finns tillgänglig som öppen programvara eller som öppna standarder är det sådana alternativ som ska väljas ut. Undantag från denna regel gjordes dock när alternativ för 3D-klienten valdes ut. Detta motiveras med att proprietär teknik ur användarens synvinkel ibland kan vara så användarvänlig eller ha så god spridning att det är värt att välja denna över ett öppet alternativ. Därför finns förutom Java även Flash och Shockwave-3D från Adobe samt Silverlight och Windows Presentation Foundation/XAML Browser Application, WPF/XBAP från Microsoft med bland alternativen (tabell 4.1). Klient Dataformat Protokoll Java VRML WFS Flash GeoVRML W3DS Shockwave 3D X3D WPF / XBAP CityGML Silverlight Tabell 4.1: Tekniska möjligheter grupperade på områden 4.1.1 Utförd multikriterieanalys I tabell 4.2 visas de fyra personer som har använts i undersökningen som intressenter. Var och en av dessa har någon form av intresse i den lösning som denna studie syftar till att ta fram, antingen som möjlig kund eller som utvecklare. 35

KAPITEL 4. GENOMFÖRANDE Namn Organisation Befattning Hans-Peter Aineskog Mittbygge.se Potentiell kund Per-Olof Norén Mogul AB Utvecklare Mats Norén Mogul AB Utvecklare Lina Ståhl Decerno AB Utvecklare Tabell 4.2: Intressenter som har deltagit i undersökningen Steg 1 De tekniska alternativen har valts ut och det första steget i undersökningen var att utreda vilka kriterier som skulle användas för de tre komponenterna. Detta gjordes genom att egenskaper identifierades som anses positiva vid framtagandet av ett Webb3DGIS, eller som inte alla alternativen uppfyller. Med dessa egenskaper som grund togs ett antal frågor fram (tabell A.1) som skickades till intressenterna. Intressenterna svarade på frågorna och kompletterade ibland även med kortare kommentarer samt nya frågor som ansågs vara viktiga. Klient K1 Webbpluginer har god spridning och är enkla att få igång K2 Möjligt att visa både 2D/3D tillsammans med Gismo (Javascript intergration) K3 3D-visualisering med god prestanda K4 Open source K5 Väl använt, någon aktör står bakom (kommersiell eller organisation) K6 Plattform/webbläsaroberoende K7 Tillgång till färdiga bibliotek för aktuella standarder och format (inte återuppfinna hjulet) Dataformat K1 Kunna bära semantisk/topologisk-information till klienten (inte bara visualiseringsdata) K2 Hög mognadsgrad K3 Goda framtidsutsikter K4 Lämplighet för geografisk data och byggnader K5 God prestanda Protokoll K1 Hög mognadsgrad K2 Goda framtidsutsikter K3 Lämplighet för 3D K4 Möjligheten att stödja flera dataformat Tabell 4.3: Kriterier grupperade på de tre teknikområdena 36

4.1. UTFÖRD UNDERSÖKNING Steg 2 Baserat på de frågor och svar som intressenterna gav i steg 1 identifierades ett antal kriterier för varje komponent (tabell 4.3). Steg 3 Värderingen av de olika tekniska alternativen baserades på författarens insamlade kunskap om dessa och värderades på en skala mellan 0 och 4 (tabell 4.4). Teknik K1 K2 K3 K4 K5 K6 K7 Java 3 3 4 3 2 3 3 Flash 4 3 1 0 4 3 2 Shockwave 3d 2 3 4 0 3 2 1 WPF / XBAP 3 1 3 0 4 1 2 Silverlight 2 3 2 0 4 2 1 (a) Klient Teknik K1 K2 K3 K4 K5 VRML 0 4 1 1 3 GeoVRML 0 4 1 3 3 X3D 0 4 3 3 4 CityGML 3 3 3 4 2 (b) Dataformat Teknik K1 K2 K3 K4 WFS 3 4 2 3 W3DS 1 3 4 3 (c) Protokoll Tabell 4.4: Författarens värdering av alternativen mot de aktuella kriterierna Steg 4 Ett formulär (figur A.1) skickades ut till intressenterna där de ombads vikta kriterierna efter vad de ansåg vara viktigast. Denna viktning görs genom att placera ut 7, 9 respektive 15 poäng på de olika komponenterna. Resultatet av dessa viktningar finns i tabell 4.5. För att kunna jämföra utvecklarnas beslut mot kundens beräknades även ett medel över utvecklarnas viktningar. Genom att utföra beslutsprocessen en gång för kunden och en gång för de samlade utvecklarna ges kunden mer beslutsmakt. Steg 5 Slutligen beräknades resultatmatriserna fram och resultatet presenteras i figurerna 4.1, 4.2 och 4.3. 37

KAPITEL 4. GENOMFÖRANDE K1 K2 K3 K4 K5 K6 K7 Hans-Peter 2 3 4 0 2 3 1 15 Per-Olof 3 1 3 1 1 6 0 15 Mats 3 1 3 1 3 4 0 15 Lina 2 3 3 0 2 2 3 15 Medel Utv. 2,67 1,67 3 0,67 2 4 1 15 (a) Klient K1 K2 K3 K4 K5 Hans-Peter 2 0 1 3 3 9 Per-Olof 1 0 4 2 2 9 Mats 1 1 3 2 2 9 Lina 1 1 2 2 3 9 Medel Utv. 1 0,67 3 2 2,33 9 (b) Dataformat K1 K2 K3 K4 Hans-Peter 0 2 2 3 7 Per-Olof 2 2 2 1 7 Mats 1 2 3 1 7 Lina 2 1 2 2 7 Medel Utv. 1,67 1,67 2,33 1,33 7 (c) Protokoll Tabell 4.5: Intressenternas viktning av kriterierna Utfall Klient När det gäller klienten ser vi i figur 4.1 att både utvecklarna och kunden har valt Java. Intressant är att K4 (öppen källkod) inte har spelat speciellt stor roll i varför Java valts. Som andra alternativ har utvecklarna valt Adobe Flash som saknar hårdvaruaccelererad 3D-grafik samtidigt som kunden har valt Adobe Shockwave-3D som har stöd för detta. Kunden har alltså lagt större vikt vid 3Dvisualisering med god prestanda än vad utvecklarna har gjort men istället valt en teknologi som är mindre använd och med sämre framtidsutsikter. (a) Utvecklare (b) Hans-Peter Aineskog Figur 4.1: Resultat: klient 38

4.1. UTFÖRD UNDERSÖKNING Vid granskning av utvecklarnas individuella resultat framgår i figur A.2 att både Per-Olof och Mats Norén inte anser det vara speciellt viktigt med färdiga kodbibliotek och verktyg men istället lägger stor vikt vid att teknologin är plattformoch webbläsaroberoende. Lina Ståhl anser istället att färdiga verktyg tillsammans med god integration av Gismo är viktigt. Dataformat Det mest slående gällande resultatet i figur 4.2 är att utvecklarna och Hans-Peter Aineskog har värderat de olika kriterierna väldigt olika. Man är överens om att prestanda är viktigt men utvecklarna tycker att stöd för geografisk data och byggnader är underordnat att formatet är moget och har goda framtidsutsikter. Bland utvecklarna är det Lina Ståhl som har viktat prestanda högst (figur A.3), vilket bidragit till att hon som ensam utvecklare valt X3D som format. (a) Utvecklare (b) Hans-Peter Aineskog Figur 4.2: Resultat: format Protokoll Även när det gäller valet av protokoll noteras stora skillnader (figur 4.3). Hans-Peter Aineskog tycker inte heller här att mognadsgrad är viktigt för protokollet och värderar istället möjligheten till flera dataformat högre än utvecklarna. Både utvecklarna och Hans-Peter Aineskog tycker dock att lämplighet för tredimensionell data samt goda framtidsutsikter är viktigt. På utvecklarnas individuella resultat (figur A.4) ses även att Lina Ståhl värderar multipla dataformat högt och det är möjligt att både hon och Hans-Peter Aieneskog har missförstått vilken roll detta kriterium spelar för klienten. Värt att notera är att Mats Norén är den person som har lagt störst vikt vid att protokollet ska vara lämpligt för tredimensionell data med tre av nio poäng. 39

KAPITEL 4. GENOMFÖRANDE (a) Utvecklare (b) Hans-Peter Aineskog Figur 4.3: Resultat: protokoll 4.1.2 Resultat Klient För klientkomponenten valdes Java. Detta alternativ var från början relativt högt värderat då det klarar hårdvaruaccelererad 3D-grafik på i princip alla plattformar som har stöd för antingen OpenGL eller Direct3D. Dessutom är det väl spritt och installerat på ca 91% av världens datorer (Microsoft, 2008). I Sverige tros siffran vara än högre vilket framförallt kan bero på att den e-legitimationslösning som Sverige har använt sig av under de senaste åren kräver just Java på klienten. Framtiden för Java är dock för tillfället lite osäker. Sun Microsystem som står bakom språket och också leder mycket av dess utveckling, har haft ett antal svåra ekonomiska år (Realtid.se, 2009), och har precis blivit uppköpt av Oracle (e24.se, 2009) efter långa förhandlingar som till sist strandade med konkurrenten IBM. Format Rörande dataformat togs båda de moderna alternativen, X3D och CityGML fram. Hans-Peter Aineskog värderade CityGML:s unika möjligheter till semantik och topologi med två av nio poäng. Det finns både de som förespråkar CityGML för visualisering (Wan och Bian, 2007) och de som inte gör det (Kulawik m.fl., 2009) men då denna studie inte bara berör visualisering, utan även hantering av bygglov där en byggnad kan tänkas byggas om eller byggas till, och där semantisk modellering samt topologisk information därför kan vara önskvärt valdes Hans-Peter Aineskogs alternativ, CityGML som formatet att använda i prototypen. Protokoll Även i fallet med protokoll tävlade två alternativ. Utvecklarna valde med knapp marginal WFS framför W3DS medan Hans-Peter Aineskog valde W3DS. 40

4.2. PROTOTYP Det finns dock ett problem med W3DS, nämligen att W3DS inte är kompatibelt med CityGML. Vid tillfället för denna analys hade författaren inte fullt ut förstått att grundtanken med W3DS är att leverera en tredimensionell scen i form av en scengraf. Författaren såg istället ett protokoll som tillät en representation av ett tredimensionellt område att begäras och tänkte sig därför ta fram en modifierad W3DS-tjänst kapabel att leverera CityGML. Av denna anledning togs både CityGML och W3DS med i undersökningen trots att de inte är oberoende av varandra. Författaren ställde den 9 mars frågan om huruvida CityGML skulle komma att bli ett av de möjliga formaten som stödjs av W3DS på OGC:s forum (OGC Forum, 2009): I ve read the discussion paper concerning W3DS so I know that VRML is the only required format and that the optional formats are GeoVRML and X3D. Wouldn t it be suitable to support CityGML as well as there probably will be many applications using W3DS to model urban areas. For example every project I found so far, where a W3DS server has been implemented, have been visualizing a city or some other urban areas. What is the status of W3DS? och fick svaret av Carl Reed (PhD): Interesting point. I would guess from a workflow perspective, CityGML would be a data source encoding and not a rendering format. VRML and X3D are rendering/styling languages. CityGML is actually an application schema that incorporates X3D (and in the future COLLADA). Let me check. Regards Carl Då studien avser att i första hand använda öppna standarder, inte skapa egna eller modifiera existerande valde författaren till slut att använda det av utvecklarna valda protokollet WFS för att kunna använda det av kunden valda dataformatet CityGML. Vidare tänkte författaren eventuellt även bygga in enkelt stöd för W3DS om det fanns tid för detta och om en lämplig W3DS-tjänst gick att lokalisera. 4.2 Prototyp Då alternativen för de olika komponenterna hade utsetts var det dags för utvecklingen av en prototyp som använder CityGML över WFS. Denna kombination var även den som valdes vid OGC Web Services Phase 4 där en proprietär WFS-server samt 41

KAPITEL 4. GENOMFÖRANDE en desktopbaserad klient användes (Curtis, 2008). Målet med studiens prototyp var att istället ta fram en webbaserad klient enbart med hjälp av öppen programvara. 4.2.1 Planering Utvecklingen av prototypen planerades att utföras under fem sprintar. Tanken var att bedriva utvecklingen iterativt och börja med enkla lösningar för att sedan utöka med ytterligare funktionalitet. Innan utvecklingen påbörjades togs en översiktlig prioritetslista med grova delmål fram (tabell 4.6). 1. Importera och visualisera data lagrat i öppna format 2. Få Java3D att fungera i en Java-applet 3. Lagra data i PostgreSQL/PostGIS databas 4. Sätta upp en WFS-server för att leverera CityGML från databasen 5. Ge klienten stöd för WFS. 6. Eventuellt bygga in enkelt stöd för X3D över W3DS Tabell 4.6: Prioritetslista för utvecklingen 4.2.2 Testdata På konferensen ULI 3D-GIS den 10-11 mars träffade författaren Anders Pikkuniemi, IT/GIS-ansvarig på Helsingborgs kommun. Han erbjöd sig att leverera testdata för denna studie och den 2 april fick författaren tillgång till en stadsmodell över Helsingborgs tätort, bestående av en höjdmodell med tillhörande flygfoto samt byggnader. Detta data levererades i CityGML som enligt kommentarer i filerna hade skapats genom export från ODIN Scankort 3D-flex (Scankort, 2007). Vid inladdning av filerna i Aristoteles, en öppen källkodsapplikation med stöd för CityGML, kraschade applikationen och när en annan applikation, LandXplorer, användes var endast terrängen synlig. En analys av datafilerna visade att dessa saknade LOD angivelser på alla byggnader och klienten valde därför att inte visa upp dem. Genom att införa taggen <lod2multisurface> framför alla <gml:multisurface> visualiserades byggnaderna korrekt ovanpå terrängen (figur 4.4). Enligt Anders Pikkuniemi har det tidigare varit möjligt att använda filerna i LandXplorer. Han har dock inte använt filerna på en längre tid då kommunen primärt använder CADformatet DWG. En möjlig orsak kan därför vara att LandXplorer numera läser indata mer strikt än i äldre versioner. 42

4.2. PROTOTYP Figur 4.4: Orginaldata visat i LandXplorer 4.2.3 Arbetsgång Sprint 1 Mål: Läsa in data från ett eller flera öppna format och visualisera denna Som första aktivitet i sprinten undersöktes vilka bibliotek för inläsning som finns tillgängliga för de olika formaten. För att ha möjlighet att kunna bygga en W3DS-klient undersöktes både CityGML och X3D. För X3D finns öppen källkodsprojektet Xj3D som förutom ett insticksprogram för X3D också erbjuder en X3D-laddare som kan användas i fristående applikationer. Denna läser data i X3D och översätter det till en Java3D::Scene som kan läggas till direkt i Java3D:s scengraf. En Java-applet konstruerades där en X3D-modell av ett lejon lästes in. Modellen placerades på en Java3D::TransformGroup och sattes till att rotera runt den vertikala axeln. Appleten fungerade problemfritt i Javas lokala appletvisare (figur 4.5) men kunde inte startas när den distribuerades via en webbsida paketerad i form av en så kallad jarfil. För CityGML var det svårare att hitta någon laddare. Det finns ett projekt som heter citygml4j som erbjuder ett API för att läsa och skriva CityGML. Detta paket erbjuder dock inget sätt att översätta informationen till en scengraf för visualisering. Författaren valde att ladda ner källkoden till Aristoteles som kan visualisera ett stort antal filformat däribland CityGML. Det visade sig att de har valt att översätta alla de olika filformaten till GML vilken sedan översätts till en scengraf och visas med Java3D. Deegree är ett öppen källkodsprojekt mycket liknande GeoServer, där man har implementerat WMS, WFS, WCS, CSW, WPS samt en WTS-tjänst. Den stora 43

KAPITEL 4. GENOMFÖRANDE Figur 4.5: Applet med Java3D och X3D-modell skillnaden mellan GeoServer och Deegree är att GeoServer är mer användarvänligt där man har möjligheten att utföra den mesta konfigurationen i ett webbgränssnitt, medan man i Deegree själv skapar och underhåller konfigurationsfiler. Bland all källkod tillhörande Deegreeprojektet finns en demonstrationsfil för att visa shape, CityGML och VRML-filer. Även denna lösning har valt att transformera om CityGML till GML genom att applicera XSLT-filer. Resulterande GML läses in i Deegree:s interna representation och kan sedan visualiseras med Java3D. (a) Visualisering av byggnad i LOD4 (b) Delmängd av byggnadsdata från Helsingborg Figur 4.6 Författaren valde att utgå från Deegree:s lösning för att kunna dra nytta av den funktionalitet som finns i projektets ramverk. Den första versionen av prototypens klient kunde läsa CityGML från fil, och resultat av detta ses i figur 4.6a och 4.6b 44

4.2. PROTOTYP där en byggnad i LOD4 samt ett antal byggnader från testdatat visualiserats. Sprint 2 Mål: Ta reda på vad som krävs för att få Java3D att fungera i en applet som distribueras via webben När en applet distribueras över webben och startas i en webbläsare är den hårdare begränsad än när den körs lokalt i Javas appletvisare. Detta beror på att den körs i en sandlåda, för att begränsa den skada som den annars kan ställa till med på användarens dator. Säkerhetsmässigt är detta en mycket god idé då det annars skulle gå att ta fram mycket effektiv skadlig kod och starta denna genom att användaren besöker en viss webbsida. Denna begränsning innebär dock att en applikation som behöver komma åt de skyddade resurserna måste signeras kryptografiskt av utvecklaren samt godkännas av användaren. Att distribuera en hårdvaruaccelererad Java-applikation över internet innebär ett problem. För att denna ska fungera måste användarens dator ha Java3D installerat, och då Java3D inte ingår i de vanliga Java-distributionerna och dessutom kräver olika versioner baserat på klientens operativsystem är detta inte något man kan räkna med att alla användare har. Det finns dock en lösning på detta problem vid namn Java Network Launching Protocol, JNLP och är en del av Java Web Start ramverket. Istället för att i HTMLkoden direkt starta sin applet använder man JNLPAppletLoader och instruerar denna att läsa in applikationens applet. Den stora fördelen med JNLP är att denna kan ladda ner rätt version av Java3D, Java OpenGL och Java Open Audio Library till användarens dator. Ytterligare en fördel med JNLP är att alla paket som laddas från Suns servrar inte behöver godkännas separat utan ses som en del av inladdningen av applikationens applet. Därmed räcker det med att användaren godkänner den inladdade applikationens signerade jarfil och sedan hanterar JNLP övriga jarfiler som beroenden. Efter att ha satt upp en automatiserad bygg- och signeringsprocess med hjälp av verktyget Maven 2 samt fått JNLP att fungera så kunde X3D-appleten laddas in i en webbläsare (figur 4.7a). Sprint 3 Mål: Lagra data i PostgreSQL och sätt upp en WFS-tjänst för CityGML. Då Gismo använder sig av kartservern GeoServer skulle det vara att föredra om denna även kunde användas för att leverera tredimensionell data. Den ursprungliga tanken inför sprinten var att ta fram en ny insticksmodul till GeoServer för att konvertera GML-resultatet till CityGML. CityGML-standarden beskriver hur data ska beskrivas i form av XML-dialekten GML. Det finns dock ingen antagen standard för hur detta data ska modelleras om man vill lagra det i en relationsdatas. Inom projekt 3D4stad arbetar man dock med 45

KAPITEL 4. GENOMFÖRANDE (a) Applet med Java3D och X3D-modell inladdad (b) Deformerat data läst genom GeoServers WFS Figur 4.7 att ta fram en kommunal standard för lagring av tredimensionella stadsmodeller (Jeansson, 2008). Författaren har flera gånger både personligen på konferenser och via e-post kontaktat stadsbyggnadskontoret i Göteborg med en förfrågan om att få tillgång till mer information om detta arbete. Personalen har dock haft ont om tid och författaren har därför inte fått tillgång till någon information. I Deegrees källkodsbibliotek finns exempelkod för att sätta upp en WFS-tjänst för CityGML. Exemplet innehåller förutom konfigurationsfiler även en databasmodell för lagring i PostgreSQL och enligt de knapphändiga instruktionerna var detta exempel i första hand tänkt att användas för import till Deegree:s WTS-tjänst. Då målet med sprinten är att importera CityGML-data till databasen verkade det vara en god idé att sätta upp denna exempeltjänst och använda den till att importera datat till databasen. När informationen väl var inläst kunde GeoServers WFS-server sedan användas för att leverera CityGML till klienten. Efter att ha lagt mycket tid på att läsa, konfigurera och felsöka Deegree:s källkod insåg författaren att han hade kört fast och tog ett steg tillbaka. Då testdatat över Helsingborg endast innehåller byggnader som består av tak och väggytor samt en terräng som även den består av ytor, valde författaren att i första hand hantera den delmängd av CityGML som verkligen används. En enklare datamodell samt ett eget importprogram togs fram och slutligen importerades byggnaderna till de olika tabellerna. Det var sedan tidigare känt att det inte går att använda komplexa feature-types i GeoServer och den ursprungliga tanken hade varit att lägga till stöd för detta i den nya instickmodulen. Innan detta arbetet påbörjades ville författare först kontrollera att ytorna gick att läsa upp ur databasen. En WFS-tjänst sattes upp i GeoServer och konfigurerades för att läsa data från tabellen innehållande alla ytor. Sedan anslöts Aristoteles till denna och visualiserade de efterfrågade ytorna, vilka dock 46

4.2. PROTOTYP var kraftigt deformerade (figur 4.7b). Det visade sig att GeoServer i nuläget endast hanterar data i två dimensioner, och vid alla hämtningar från databasen tolkar om tredimensionella geometrier som tvådimensionella. Enligt utvecklarna insatta i området är det inte heller helt okomplicerat att ändra detta i det nuvarande versionsträdet (nabble.com, 2008) men det ser ut som att GeoServer 2.0, planerad att släppas hösten 2009, kommer stödja detta fullt ut. Sprint 4 Mål: Utred om det finns något alternativ till GeoServer, om inte modifiera Geo- Server så att WFS-tjänsten är möjlig. Bygg in stöd i webbklienten för WFS Att hinna med att komplettera GeoServer med både komplexa feature-types, tredimensionell data och CityGML-export under resterande utvecklingstid verkade inte realistiskt. Vid en översikt av alternativen framstod Deegreeprojektets WFSserver åter som ett alternativ. Denna hanterar både komplexa feature-types och tredimensionellt data. Dessutom har den möjligheten att applicera XSLT-filer på in- och utgående data, vilket möjliggör transformering av GML till CityGML. Därför påbörjades återigen försök att få Deegree:s WFS-server att fungera. Den stora skillnaden mot sprint tre var att konfigurationen nu inte berörde CityGMLexemplet utan den datamodell som författaren själv hade satt upp. Därför gick det nu relativt fort att få en fungerande WFS-tjänst och en komplex feature-type för byggnader sattes upp innehållande tak och väggytor. En XSLT-fil skapades och valdes som utfilter. Därmed fungerar denna lösning på liknande sätt som Snowflakes proprietära motsvarighet (Curtis, 2008). (a) Visualisering av CityGML utläst genom Deegree:s(b) Version av prototypen som körs i en webbläsare WFS och läser CityGML över WFS Figur 4.8: Skärmdumpar Prototyputveckling 47

KAPITEL 4. GENOMFÖRANDE När tjänsten var konfigurerad begärdes alla byggnaderna genom tjänsten och visualiserades i LandXplorer (figur 4.8a) och för att uppfylla målet med studien togs även en WFS-klient fram till webbklienten så att även denna kunde begära byggnadsdatan över internet (figur 4.8b). Sprint 5 Mål: Finputs av klienten. Tag fram stöd i WFS-klienten för att göra enklare urval, förbättra navigationen och utforma webbsidan som laddar appleten. Undersök även om det finns några W3DS-servrar som kan användas för att bygga enkelt stöd för detta protokoll i klienten. Under denna sprint gjordes prototypen mer användarvänlig genom förbättrad 3D-navigering. WFS-klienten kompletterades med enklare filtrering som möjliggör urval baserat på en boundingbox, eller baserat på det cirkulära område som definieras av en mittpunkt och en radie. Webbsidan som laddar Java-appleten utformades och resultatet kan ses i figur 4.8b och 4.9. Figur 4.9: Slutgiltig prototyp med terräng, byggnader och en planerad byggnad 48

4.2. PROTOTYP Författaren kontaktade geografiska avdelningen på Bonns universitet med en förfrågan om att få tillgång till någon av de W3DS-tjänster som har tagits fram för Heidelberg och OSM3D-projektet. Författaren fick ett svar där tillgång till data i VRML genom OSM3D:s W3DS-tjänster föreslogs. Det visade sig dock att det skulle dröja en längre tid innan författaren kunde få tillgång till tjänsterna och istället lades stöd för för multipla datalager till i prototypen. Även terrängen importerades till databasen och en parameter: class bands till byggnaderna i databasmodellen för att indikera om en byggnad existerar eller endast är planerad. I den slutgiltiga prototypen (figur 4.9) laddas tre lager in: existerande byggnader, planerade byggnader och terräng. Som sista aktivitet i sprinten lades en knapp till i HTML-koden som genom ett Javascriptanrop kan visa eller dölja lagret med planerade byggnader. 49

Kapitel 5 Slutsatser och rekommendationer Den prototyp som har tagits fram har visat att det är möjligt att i en webbläsare visualisera tredimensionella stadsmiljöer, lagrade i en spatial databas, med hjälp av öppen källkodskomponenter och över öppna standarder. Värt att notera är att ingen av de ingående komponenterna har modifierats utan används i det skick som de erbjuds från respektive projektwebbplats. 5.1 Stadsmodeller och format Den prototyp som har tagits fram har visat att det är möjligt att i en webbläsare med hjälp av öppna standarder och öppen källkodskomponenter visualisera tredimensionella data lagrad i en spatial databas. Den största fördelen med CityGML är att formatet bär semantisk och topologisk information, vilket också är formatets stora nackdel då detta innebär att datamängden ökar och prestandan därmed sjunker jämfört med enbart visualiserande format. Detta blir extra tydligt då större områden och/eller detaljerade modeller ska överföras. X3D och andra visualiseringsformat är istället mycket effektivare och möjliggör därför visualisering av större områden. När man vill modifiera byggnader är det troligt att man arbetar med en byggnad åt gången, resterande byggnader är i huvudsak där för att ge känsla och rymd för omgivningarna på samma sätt som terrängen. Företaget Sightline som arbetar med att ta fram verklighetstrogna visualiseringar av framtida byggprojekt informerade på konferensen 3D-GIS att de har ingått samarbete med C3-Technologies för att använda deras data som underlag. På så sätt får de hela stadsbilden i visualiseringen men behöver själva bara lägga kraft på de nya byggnaderna. På liknande sätt skulle man kunna tänka sig att använda X3D genom W3DS för att läsa in omgivande byggnader och terräng och bara läsa in CityGML-modeller över WFS av de byggnader som man vill modifiera. På samma sätt skulle även BIM-modeller kunna integreras i systemet för att även visualisera och modellera insidan av byggnader. 51

KAPITEL 5. SLUTSATSER OCH REKOMMENDATIONER 5.2 Datainsamling För att samla in och bygga upp en initial tredimensionell stadsmodell kan man utgå från existerande tvådimensionell data och komplettera denna med höjdmätningar för att lyfta upp huskropparna. Det är dock viktigt att man inte skapar huskroppen som en ensam geometri utan ser till att den består av väggar, tak och deras respektive ytor. På så sätt kan modellen senare modifieras och ytterligare förfinas med bland annat dörrar och fönster. Har kommunen dessutom tillgång till elektroniska byggnadsritningar eller BIMmodeller så kan dessa användas för att med automatik generera byggnader som är både detaljrika och korrekta. På senare år har frågan om huruvida det ska vara lagkrav på att alla nya byggnader som uppförs ska vara representerade i någon form av byggnadsmodell, exempelvis BIM och våra nordiska grannländer Norge och Danmark har kommit långt på detta område. 5.3 Modellering För att en tredimensionell byggnadsmodell framtagen av en vanlig användare ska vara användbar bör man kräva att den åtminstone har rätt dimensioner, och kanske även ett korrekt grundläggande utseende med taktyp, fönster, balkonger osv. För att en användare utan modelleringskunskaper själv ska kunna ta fram en så pass god tredimensionell modell kräver det ett mycket användarvänligt modelleringsprogram. En fördel med att modellera byggnader är att de i grunden oftast är uppbyggda av enkla geometrier och man kan komma väldigt långt genom att få måtten på de grundläggande boxarna korrekta. Författaren föreslår därför ett hybridsystem där man kan växla mellan två och tredimensionell visualisering. I två dimensioner är det lättare att placera hörn och få längden/bredden på ett område rätt. När detta område är valt väljer man sedan höjd på rummet som då lyfts ur ytan. För att placera ut fönster, dörrar och liknande kan den tredimensionella vyn innebära att man lättare ser vad som ser rätt ut medan användaren i den tvådimensionella vyn lätt kan se till att fönstren är jämt fördelade över en vägg. Dörrar, fönster, balkonger, skorstenar med mera kan tillhandahållas som byggelement i form av 3D-modeller men för att inte begränsa utbudet skulle författaren gärna se att en lösning som den beskriven av (Funkhouser m.fl., 2004) används för att låta användaren skära ut delar av 3D-modeller. Dessa modeller kan exempelvis laddas ner från Google 3D Warehouse (Google, 2009) i det öppna formatet KML. På så sätt öppnas möjligheterna, inte bara till att använda Google Sketchup som modelleringsverktyg utan även för att använda sig av delar från 3D-modeller framtagna av användare runt om i världen. 52

Litteratur Beard, David. Using VRML to share large volumes of complex 3D geoscientific information via the Web. I: Web3D 06: Proceedings of the eleventh international conference on 3D web technology, ss 163 167, New York, NY, USA, 2006. ACM. ISBN 1-59593-336-0. Brooks, Stephen och Whalley, Jacqueline L. A 2D/3D hybrid geographical information system. I: GRAPHITE 05: Proceedings of the 3rd international conference on Computer graphics and interactive techniques in Australasia and South East Asia, ss 323 330, New York, NY, USA, 2005. ACM. ISBN 1-59593-201-1. Büuyüközkan, Gülcin och Ruan, Da. Evaluation of software development projects using fuzzy multi-criteria decision approach. Mathematics and Computers in Simulation, 2007. Carey, Rikk och Bell, Gavin. The annotated VRML 2.0 reference manual. Addison- Wesley Longman Ltd., Essex, UK, UK, 1997. ISBN 0-201-41974-2. Cherlin, Joseph Jacob, Samavati, Faramarz, Sousa, Mario Costa, och Jorge, Joaquim A. Sketch-based modeling with few strokes. I: SCCG 05: Proceedings of the 21st spring conference on Computer graphics, ss 137 145, New York, NY, USA, 2005. ACM. ISBN 1-59593-203-6. Curtis, Eddie. Advances in 3D Geoinformation Systems, kapitel Serving CityGML via Web Feature Services in the OGC Web Services - Phase 4 Testbed, ss 331 340. Springer Berlin Heidelberg, 2008. ISBN 978-3-540-72134-5. Danielsson, Mats, Ekenberg, Love, Ekengren, Anders, Hökby, Torsten, och Lidén, Jan. Decision Process Support for Participatory Democracy. Journal of Multi- Criteria Decision Analysis, 15:15 30, 2008. Eklundh, Lars, Arneberg, Wolter, Arnborg, Stefan, Eklundh, Lars, Harrie, Lars, Hauska, Hans, Olsson, Lennart, Pilesjö, Petter, Rystedt, Bength, och Sandgren, Ulf. Geografisk Informationsbehandling Metoder och tillämpningar. Byggforskningsrådet, 1999. ISBN 91-540-5841-4. Ferreira, Carlos och Cohen, Jason. Agile systems development and stakeholder satisfaction: a South African empirical study. I: SAICSIT 08: Proceedings of 53

LITTERATUR the 2008 annual research conference of the South African Institute of Computer Scientists and Information Technologists on IT research in developing countries, ss 48 55, New York, NY, USA, 2008. ACM. ISBN 978-1-60558-286-3. Funkhouser, Thomas, Kazhdan, Michael, Shilane, Philip, Min, Patrick, Kiefer, William, Tal, Ayellet, Rusinkiewicz, Szymon, och Dobkin, David. Modeling by example. I: SIGGRAPH 04: ACM SIGGRAPH 2004 Papers, ss 652 663, New York, NY, USA, 2004. ACM. Giannopoulos, Ioannis, Hatzi, Ourania, Nikolaidou, Mara, och Anagnostopoulos, Dimosthenis. Realistic virtual environments navigable over the www. I: SCSC: Proceedings of the 2007 summer computer simulation conference, ss 1 6, San Diego, CA, USA, 2007. Society for Computer Simulation International. ISBN 1-56555-316-0. Karpenko, Olga A. och Hughes, John F. SmoothSketch: 3D free-form shapes from complex sketches. I: SIGGRAPH 06: ACM SIGGRAPH 2006 Papers, ss 589 598, New York, NY, USA, 2006. ACM. ISBN 1-59593-364-6. Kesan, Jay och Shah, Rajiv. Open standards in electronic governance: promises and pitfalls. I: ICEGOV 08: Proceedings of the 2nd International Conference on Theory and Practice of Electronic Governance, ss 179 182, New York, NY, USA, 2008. ACM. ISBN 978-1-60558-386-0. Kolbe, Thomas H. 3D Geo-Information Sciences, kapitel Representing and Exchanging 3D City Models with CityGML, ss 15 31. Springer Berlin Heidelberg, 2009. ISBN 978-3-540-87394-5. Kulawik, Robert, Schilling, Arne, och Zipf, Alexander. Landesweite 3D- Stadtmodelle im Internet auf Basis offener Standards des Open Geospatial Consortiums (OGC) - das Beispiel Nordrhein-Westfalen-3D. I: 14th International Conference on Urban Planning and Regional Development in the Information Society GeoMultimedia (CORP 2009), 2009. Longley, Paul, Goodchild, Micael F., Maguire, David J., och Rhind, David W. Geographic Information Systems and Science. John Wiley & Sons, LTD, 2001. ISBN 0-471-89275-0. Mendoza, Guillermo A., Macoun, Phil, Prabhu, Ravi, Sukadri, Doddy, Purnomo, Herry, och Hartanto, Herlina. Guidelines for Applying Multi-Criteria Analysis to the Assessment of Criteria and Indicators. Mathematics and Computers in Simulation, 1999. Ming, Wang. A 3D Web GIS System Based on VRML and X3D. I: WGEC 08: Proceedings of the 2008 Second International Conference on Genetic and Evolutionary Computing, ss 197 200, Washington, DC, USA, 2008. IEEE Computer Society. ISBN 978-0-7695-3334-6. 54

Misund, G., Granlund, M., och Kolås, H. Global Models and the W3DS Specification - Challenges and Solutions. I: Proceedings of the First International Workshop on Next Generation 3D City Models, 2005. Nurminen, Antti. m-loma - a mobile 3D city map. I: Web3D 06: Proceedings of the eleventh international conference on 3D web technology, ss 7 18, New York, NY, USA, 2006. ACM. ISBN 1-59593-336-0. Rhyne, Theresa Marie, MacEachren, Alan, och Rhyne, Theresa-Marie. Visualizing geospatial data. I: SIGGRAPH 04: ACM SIGGRAPH 2004 Course Notes, s 31, New York, NY, USA, 2004. ACM. Scacchi, Walt. Free/open source software development. I: ESEC-FSE 07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, ss 459 468, New York, NY, USA, 2007. ACM. ISBN 978-1-59593-811-4. Schöning, Johannes, Hecht, Brent, Raubal, Martin, Krüger, Antonio, Marsh, Meredith, och Rohs, Michael. Improving interaction with virtual globes through spatial thinking: helping users ask why?. I: IUI 08: Proceedings of the 13th international conference on Intelligent user interfaces, ss 129 138, New York, NY, USA, 2008. ACM. ISBN 978-1-59593-987-6. Sebe, Ismail Oner, You, Suya, och Neumann, Ulrich. Rapid part-based 3D modeling. I: VRST 05: Proceedings of the ACM symposium on Virtual reality software and technology, ss 143 146, New York, NY, USA, 2005. ACM. ISBN 1-59593-098-1. Shan, J. Visualizing 3-D Geographical Data with VRML. I: CGI 98: Proceedings of the Computer Graphics International 1998, s 108, Washington, DC, USA, 1998. IEEE Computer Society. ISBN 0-8186-8445-3. Tonnquist, Bo. Projektledning, andra upplagan. Bonnier Utbildning, 2006. ISBN 978-91-622-8046-8. Wan, You och Bian, Fuling. A Extended Web Feature Service Based Web 3D GIS Architecture. I: Wireless Communications, Networking and Mobile Computing, WiCom 2007, ss 5947 5950, September 2007. Zeleznik, Robert. Sketching in 3D. SIGGRAPH Comput. Graph., 32(4):45 49, 1998. ISSN 0097-8930. 55

Övriga referenser C3-Technologies. C3 Short Presentation. http://www.c3technologies.com/pdf/c3 Short Presentation.pdf, 2008a. Läst under maj 2009. C3-Technologies. Datainsamling. http://www.c3technologies.com/en_data_acquisition.php, 2008b. Läst under maj 2009. C3-Technologies. Realistic vs Traditional maps. http://www.c3technologies.com/pdf/realistic vs Traditional maps.pdf, 2008c. Läst under maj 2009. Capstick, Dave. CityGML and 3D modelling. http://www.idee.es/resources/presentaciones/canarias_gtidee/citygml_ign.ppt, mars 2008. Läst under maj 2009. e24.se. Oracle köper Sun Microsystems. http://www.e24.se/branscher/ittelekom/artikel_1258873.e24, april 2009. Läst under maj 2009. Google. Google 3D Warehouse. http://sketchup.google.com/3dwarehouse, 2009. Läst under maj 2009. Hitta.se. Pressmeddelande. http://www.hitta.se/info/pressreleases/3d_stockholm_080529.pdf, maj 2008. Läst under april-maj 2009. Jeansson, Eric. 3D-Strategi Stadsbygnadskontoret Göteborgs Stad. http://www.skt.se/kurser/rapporter/sting2008/ STINGdagar_3D_strat_gbg_lowres.ppt, maj 2008. Läst under maj 2009. Kolbe, Thomas och Bacharach, Sam. CityGML: An Open Standard for 3D City Models. http://www.directionsmag.com/article.php?article_id=2209&trv=1, 2006. Läst under maj 2009. 57

ÖVRIGA REFERENSER Microsoft. Sun Microsystems to Distribute Microsoft Live Search-Powered Toolbar as Part of Java Runtime Environment. http://www.microsoft.com/presspass/press/2008/nov08/11 10LiveJREMPR.mspx, november 2008. Läst under april 2009. nabble.com. Does Geoserver use Z-values. http://www.nabble.com/does-geoserver-use-z-values-td21082436.html, december 2008. Läst under maj 2009. Nyteknik.se. Hitta.se klår Google Earth med Saabs nya 3D-teknik. http://www.nyteknik.se/nyheter/it_telekom/allmant/article361352.ece, maj 2008. Läst under maj 2009. OGC. WTS Specification. http://portal.opengeospatial.org/files/?artifact_id=1072, augusti 2001. Läst under feb-maj 2009. OGC. WMS Specification. http://portal.opengeospatial.org/files/?artifact_id=4756, januari 2004. Läst under jan-maj 2009. OGC. W3DS Specification. http://portal.opengeospatial.org/files/?artifact_id=8869, februari 2005a. Läst under feb-maj 2009. OGC. WFS Specification. http://portal.opengeospatial.org/files/?artifact_id=8339, maj 2005b. Läst under jan-maj 2009. OGC. History. http://www.opengeospatial.org/ogc/history, juli 2006a. Läst under jan 2009. OGC. Simple Feature SQL Specification. http://portal.opengeospatial.org/files/?artifact_id=18242, oktober 2006b. Läst under jan-maj 2009. OGC. CityGML Best Practices Document. http://portal.opengeospatial.org/files/?artifact_id=22120, juli 2007a. Läst under maj 2009. OGC. GML Specification. http://portal.opengeospatial.org/files/?artifact_id=27810, augusti 2007b. Läst under feb-maj 2009. OGC. KML Specification. http://portal.opengeospatial.org/files/?artifact_id=27810, april 2007c. Läst under mars-maj 2009. 58

OGC. CityGML Specification. http://portal.opengeospatial.org/files/?artifact_id=28802, augusti 2008. Läst under feb-maj 2009. OGC Forum. http://feature.opengeospatial.org/forumbb/viewtopic.php?t=1667, mars 2009. Läst under maj 2009. OpenStreetMap 3D. Projektets webbsida. http://www.osm-3d.org, mars 2009. Läst under april-maj 2009. Realtid.se. Sun: Vi vrider om kostymen. http://www.realtid.se/articlepages/200903/13/20090313150600_realtid657 /20090313150600_Realtid657.dbp.asp, mars 2009. Läst under maj 2009. RFP Evaluation Centers Inc. http://rfptemplates.technologyevaluation.com/multi-criteria-decision-making- MCDM.html http://rfptemplates.technologyevaluation.com/what-is-a-decision-matrix.html, april 2009. Läst under april 2009. Scankort. Produktblad. http://www.scankort.dk/6storage/827/2/scankort_produktark_3dstadflex_se.pdf, mars 2007. Läst under april 2009. Softpedia.com. Skärmbild: Google Earth. http://www.softpedia.com/progscreenshots/google Earth Screenshot 23512.html, 2009. Läst under maj 2009. Web3D. VRML97 Specification. http://www.web3d.org/x3d/specifications/vrml, 1997. Läst under feb-maj 2009. Web3D. X3D Specification. http://www.web3d.org/x3d/specifications/old/ ISO IEC 19775 X3DAbstractSpecification, 2004. Läst under feb-maj 2009. Wikipedia. Skärmbild: Google Sketchup. http://en.wikipedia.org/wiki/file:sketchupexample.png, 2008. Läst under maj 2009. 59

Bilaga A Underlag undersökning Nedan finns underlag för utvärderingen av de tekniska alternativ. Tabell A.1: Frågor som användes vid framtagandet av utvärderingens kriterier Är det viktigt att... klienten är plattformsoberoende servern är plattformsoberoende använda öppna standarder klienttekniken har stor spridning (andelen användare som inte behöver installera något ytterligare är låg) det är enkelt för användaren att använda systemet ha en riktigt navigerbar 3D miljö (alternativet är perspektivvyer i 3D ). man har god 3D prestanda ha hög detaljnivå eller räcker enkla byggklossar som byggnader. kunna zooma ut från den initiala 3d-scenen och hämta in fler delar av den tillgängliga världen eller är det ok att begränsa till ett avgränsat område kunna skicka med semantik & topologi information till klienten och inte bara visualiseringsdata kunna integrera systemet med nuvarande Gismostacken (deploya tillsammans) kunna visa både 2D/3D tillsammans med Gismo i 3D vyn kunna skapa geometrier för att geotagga eller för att bygga hus tekniken ligger i den tekniska framkanten kunna stödja flera olika format/standarder det finns färdiga bibliotek för aktuella (inte återuppfinna hjulet) komponenterna anses ha goda framtidsutsikter komponenterna anses vara mogna (används av många, anses vara beprövad) komponenterna anses vara stabil komponenterna har en aktiv utveckling komponenterna har ett lågt pris (0 kr vid opensource) komponenterna har en stabil kommersiell leverantör bakom sig 61

BILAGA A. UNDERLAG UNDERSÖKNING Tabell A.1: fortsättning Är det viktigt att... komponenterna har ett stabilt community bakom sig det finns möjlighet till att köpa support på komponenterna licenserna är liberala (man får utöka och förändra om man vill/behöver) hålla sig till Open Source 62

Figur A.1: Dokument skickat till intressenterna där de ombeds vikta kriterierna 63

BILAGA A. UNDERLAG UNDERSÖKNING (a) Per-Olof Norén (b) Mats Norén (c) Lina Ståhl Figur A.2: Resultat: klient 64

(a) Per-Olof Norén (b) Mats Norén (c) Lina Ståhl Figur A.3: Resultat: format (a) Per-Olof Norén (b) Mats Norén (c) Lina Ståhl Figur A.4: Resultat: protokoll 65