FältGIS. Utfört av Patrik Fundberg. Mälardalens Högskola, IDt. Handledare John Kessler, LandFocus IS AB Christer Norström, Mälardalens Högskola

Transkript

1 Examensarbete för magisterexamen i datateknik FältGIS Utfört av Patrik Fundberg Mälardalens Högskola, IDt Handledare John Kessler, LandFocus IS AB Christer Norström, Mälardalens Högskola

2 Sammanfattning LandFocus håller på att utveckla GIVAS, ett GIS-projekt för bl.a. presentation, redigering och lagring av geografiska data. I framtiden vill man kunna göra viss ajourhållning i en handdator med programmet ArcPad 6. I detta examensarbete har en utredning gjorts för att se om det är tekniskt möjligt att redan idag använda ArcPad 6 för ajourhållningen. För att det ska anses som tekniskt möjligt att använda ArcPad 6 måste det finnas möjlighet att checka ut data från en central server och överföra data till en fältenhet, skapa geoobjekt i fältenheten, för att till sist överföra de nya geoobjekten tillbaka till servern och där checka in dem. LandFocus har haft som önskemål att de nya geoobjekten skall föras över från fältenheten i ett kommunikationsprotokoll som är skrivet i XML. Ett flertal XML-vokabulär och standarder har gåtts igenom för att se om det finns något bra format för kommunikationsprotokollet. Alla krav som ställts på system är uppfyllda förutom den kanske viktigaste, att kunna skapa nya geoobjekt i fältenheten. ArcPad 6 är i dagens läge inte helt färdigutvecklat och därför måste det anses att det inte är tekniskt möjligt att sköta ajourhållningen med programmet. Abstract LandFocus is in the process to develop GIVAS, a GIS-project to present, edit and store geographical data. In the future one will be capable to do some of the work in a pocket computer with the program ArcPad 6. In this master thesis an investigation has been done to see if it is possible, in the technical point of view, to use ArcPad 6 in this work today. To be considering as possible one must be capable to check out data from a central server and to transfer it to the pocket computer, create new features in the pocket computer and at last, transfer the new features to the central server where they will be checked in. LandFocus had a request that the new features will be transferred from the pocket computer in a communication protocol that is written in XML. Many XML vocabularies and standards have been looked at to see if there is a good format for the protocol. All the demands are fulfilled apart from the one to create new features with ArcPad 6. ArcPad 6 is still in the developing process and therefore it must be considered to be not technical possible to the work with the program. 2

3 Innehållsförteckning 1 INTRODUKTION Bakgrund Syfte Begrepps- och ordförklaringar Läsanvisningar 6 2 PROBLEMBESKRIVNING Problemet Kravställning Avgränsningar 8 3 RELATERADE ARBETEN GIS XML Grunderna i XML XML vokabulär Tekniska försörjningssystem 27 4 PROBLEMANALYS Problemhierarki Analys Lösningsförslag 32 5 LÖSNING Införsel av data till fältenheten Skapa nya geoobjekt i fältenheten Utförsel av data från fältenheten 34 6 RESULTAT 44 7 SLUTSATSER Analys av resultat Rekommendationer Framtida arbete 46 8 SUMMERING 47 9 LITTERATURFÖRTECKNING 48 BILAGOR 49 Bilaga 1: Del av datamodellen för GIVAS 49 Bilaga 2: Förenklad begreppsmodell SS Bilaga 3: XML schema för kommunikationsprotokoll 50 Bilaga 4: Dokumentinstans av kommunikationsprotokollet 52 3

4 1 INTRODUKTION 1.1 Bakgrund LandFocus har ett uppdrag av Stockholms Vatten att utveckla GIVAS (Geografisk Information för Vatten och Avlopp i Stockholm) som ska användas för att presentera och analysera geografisk information. GIVAS är ett kraftfullt stöd för Stockholm Vatten vid hantering av ledningsnäten och för kundinformation i samband med driftstörningar av olika slag. I GIVAS kombineras information från olika källor i databaserna som sedan kan presenteras i kartbilder. Det finns tillämpningar i systemet för ajourhållning och nyproduktion av kartor, spårning av läckor och föroreningar liksom för driftstörningar, reparationer och underhåll. Miljödata integreras med information om vattenkvalitet i ledningsnätet och med data om sjöar och vattendrag. Man kan exempelvis i bild visa resultaten av provtagningar med flera miljoner provresultat. Informationen direkt till enskilda kunder i samband med t ex vattenläckor och andra driftstörningar underlättas och förbättras avsevärt genom GIVAS. I framtiden skulle man även vilja att viss ajourhållning kunde skötas mobilt med hjälp av en handdator. I denna handdator är det tänkt att man skall använda programmet ArcPad 6 som är integrerad med ArcGIS konceptet. 1.2 Syfte Syftet med detta arbete är att utreda om det är tekniskt möjligt att med ArcPad 6 sköta ajourhållningen från en mobil enhet. 1.3 Begrepps- och ordförklaringar I detta avsnitt förklaras de förkortningar och begrepp som används i rapporten Ordförklaringar COM Component Object Model DTD DokumentTyp Deklaration ESRI Environmental Systems Research Institute GIS Geographic Information System GPS Global Positioning System ISO International Organization for Standardization OGC OpenGIS Consortium SIS Standardiseringen i Sverige UML Unified Modeling Language W3C World Wide Web Consortium XML extensible Markup Language 4

5 1.3.2 Begrepp Ajourhållning ArcCatalog ArcIMS ArcObjects ArcMap ArcPad Feature Geodatabasen Geoobjekt Skapa nya geoobjekt eller ta bort eller ändra redan befintliga geoobjekt. GIS-programvara från ESRI Inc. Används för att läsa, skapa, behandla och organisera geografiska datatabeller. Ingår som en del av ESRIs ArcInfo 8. GIS-programvara från ESRI Inc som bl.a. kan generera webbsidor med kartor utifrån en geografisk databas. Samling av mjukvarukomponenter med GISfunktionalitet och programmerbara interface från ESRI Inc. GIS-programvara från ESRI Inc. Används för att presentera och redigera geografisk information. Ingår som en del av ESRIs ArcInfo 8. GIS-programvara från ESRI Inc. Används för att presentera och redigera geografisk information på både mobila handdatorer och vanliga PC. Engelska för objekt som har eller kan ha geografiska egenskaper. Databas som används i ArcInfo 8 för att spara ner den geografiska informationen som finns i datamodellen för GIVAS. Genom att använda ESRI Inc programvara ArcSDE kan den geografiska informationen sparas ner i samma relationsdatabas som verksamhets-databasen. Svenska översättningen av feature, dvs. ett objekt som har eller kan ha geografiska egenskaper. Kartlager Shape-fil Verksamhetsdatabasen Geodatabasen är indelad i tabeller som innehåller geoobjekt med gemensamma egenskaper. Dessa tabeller utgör även kartlager som användaren kan tända (visa), släcka och symbolisera. En shape-fil är ett filbaserat format för att spara vektordata som plats, geometri och attribut för geoobjekt som saknar topologi. Detta filformat används av bl.a. ArcPad. Databas innehållande den information som saknar geografiska egenskaper men ändå finns med i datamodellen för GIVAS. 5

6 1.4 Läsanvisningar Kapitel 2, Problembeskrivning: I detta kapitel beskrivs problemet och målet för arbetet ges. Kapitel 3, Relaterade arbeten: I detta kapitel ges en presentation av den teori som arbetet bygger på. Kapitlet ger läsaren den basteori som behövs för att förstå lösningen. Kapitel 4, Problemanalys: I detta kapitel analyseras problemet och några lösningsförslag presenteras. Kapitel 5, Lösning: I detta kapitel ges en fullständig redogörelse för designen av de valda lösningsförslagen. Kapitel 6, Resultat: I detta kapitel presenteras resultatet. Kapitel 7, Slutsatser: I detta kapitel redovisas de slutsatser man kan dra av arbetet. Kapitel 8, Summering: I detta kapitel ges en kortfattad summering av arbetet. Kapital 9, Litteraturförteckning: I detta kapitel presenteras de referenser som använts. 6

7 2 PROBLEMBESKRIVNING I detta kapitel beskrivs problemet och målet för arbetet ges. 2.1 Problemet Det problem som LandFocus vill ha utrett är om det med morgondagens teknik går att uppdatera information om ett geoobjekt i fält och sedan skicka informationen till en central server som innehåller hela objektsmodellen. Med morgondagens teknik menas programmet ArcPad 6 som företaget ESRI Inc håller på att utveckla. ArcPad 6 är tänkt att användas för att bl.a. presentera, redigera och lagra geografisk information. ArcPad 6 består egentligen av två olika program, en för handdatorer och en för vanliga PC, men oavsett vilket av programmen som används så är funktionaliteten densamma. ArcPad 6 arbetar mot s.k. shape-filer. I en shape-fil lagras information om geoobjekt vilka har samma egenskaper och shape-filen presenteras i ArcPad 6 som ett eget kartlager. En shape-fil kan innehålla information om t.ex. avloppsledningar och en annan kan innehålla t.ex. översiktsinformation om gator och grönområden. Genom att kombinera olika kartlager i ArcPad 6 får man fram en karta. För att kunna uppdatera informationen i fält med ArcPad 6 måste man kunna hämta geoobjekt från en central server och överföra dessa till den mobila enheten där de lagras i sina respektive shape-filer. Dessutom måste man kunna skapa nya geoobjekt i fält och förutom geoobjektets geografi måste det finnas möjligheter att fylla i annan information om geoobjektet som t.ex. material, dimensioner mm. Till sist måste de nya och ändrade geoobjekten föras över till den centrala servern där de lagras Överföringen av de nyskapade geoobjekten från fältenheten är tänkt att ske med ett kommunikationsprotokoll som är skrivet i XML. Kommunikationsprotokoll skall vara så pass begränsat att det går att uppdatera ett ledningsnät mobilt, men ändå bibehålla nödvändig information. LandFocus har haft som önskemål att utredningen även skall titta närmare på om det finns några standarder för överföring av geografiska data som är skrivna i XML och om det är möjligt och lämpligt att kommunikationsprotokollet stödjer den svenska standarden för tekniska försörjningssystem, SS [SIS00]. 2.2 Kravställning Målet med detta arbete är att bestämma om det är tekniskt möjligt att med ArcPad 6 sköta ajourhållningen från en mobil enhet. För att kunna bedöma om det är tekniskt möjligt så måste vissa krav uppfyllas. Kraven är att det måste gå att: Checka ut data från geodatabasen. Överföra data från stationärenheten till fältenheten. Skapa nya geoobjekt i fältenheten. Överföra de nya geoobjekten från fältenheten till stationärenheten. Checka in data till geodatabasen. 7

8 2.3 Avgränsningar Endast en forskningsprototyp kommer att implementeras, detta för att visa att de föreslagna lösningarna fungerar och för att ge en bas för analys och tester. Forskningsprototypen kommer bara att kunna skapa nya geoobjekt i fält (inte göra ändringar av redan befintliga) och den kommer endast att klara av tre av geoobjekten i GIVAS och dessa är: Avloppsledningar ledningar för avlopp som representeras av linje på kartan. Vertikalledningar avloppsledningar som går vertikalt och representeras av en punkt på kartan. Avloppsserviser som avloppsledningar men med den begränsningen att den går till en kund. I bilaga 1 finns den del av datamodellen för GIVAS vilken motsvarar de tre geoobjekten. Valideringen av kommunikationsprotokollet gentemot en DTD eller XML schema ligger utanför detta examensarbete. Däremot skall det finnas en DTD eller XML schema som beskriver kommunikationsprotokollet. 8

9 3 RELATERADE ARBETEN I detta kapitel presenteras den teori som arbetet bygger på. 3.1 GIS Meningen med GIS är att tillhandahålla en spatial struktur för att stödja beslut för en intelligent användning av jordens resurser och för att hantera den mänskliga miljön [Zei99]. Oftast presenterar GIS information såsom kartor och symboler. Kartan ger oss kunskap om var olika saker finns, vad de är och hur man kan ta sig dit. GIS kan även sprida information genom en interaktiv session med en karta i en dator. Denna session avslöjar information som inte finns på en vanlig karta. Exempelvis kan man ställa frågor om kända attribut till ett geoobjekt, skapa en lista med alla geoobjekt som förbinder en punkt i ett nätverk med en annan punkt. Dessutom utföra simuleringar för att mäta olika egenskaper såsom vattenflöde, restid och utvidgning av föroreningar mm. [Zei99]. Ett geoobjekt kan modelleras på olika sätt beroende på hur användaren vill ha det. Floder kan t.ex. representeras av linjer som skapar ett nätverk där floderna har olika attribut såsom flödesriktning, volym mm. En linjär nätverksmodell kan sedan användas för att analysera vattenflöden eller fartygstrafik. Floder kan även representeras som en area med noggrann representation av stränder, öar mm. [Zei99]. 3.2 XML XML är ett språk som används för att strukturera formatet för ett dokument och påminner en hel del om HTML (Hyper Text Markup Language), vilken är en av de standarder som används på Internet. De största skillnaderna mellan HTML och XML är att det finns ett begränsat antal taggar för HTML i förhållande till XML och att HTML beskriver hur ett dokument skall se ut medan XML beskriver vad ett dokument betyder, se exempel 3.1. Exempel 3.1: Skillnader mellan XML och HTML. HTML-kod <p> FältGIS <br> Patrik Fundberg <br> XML-kod <examensarbete kurskod= CT2810> <titel> FältGIS </titel> <författare> Patrik Fundberg </författare> <datum> </datum> </examensarbete> Både HTML och XML härstammar från ett språk som heter SGML (Standard Generalized Markup Language) och XML är egentligen en förenklad delmängd av SGML. SGML kom till genom ett arbete som började i slutet på 60-talet när några forskare på IBM fick i uppdrag att skapa ett system så att företagets alla dokument fick en standardiserad format. Detta för att olika delar av företaget skulle kunna 9

10 kommunicera med varandra, vilket de vid den tidpunkten inte alltid kunde. De skapade GML (Generalized Markup Language) som sedan fortsatte att utvecklas och 1986 blev det en internationell standard (ISO 8879) som fick namnet SGML. Det finns både fördelar och nackdelar med XML. Några fördelar med XML dokument är att de är: enkla att skriva både för en dator och för en människa. otvetydiga. utbyggbara. plattformsoberoende. lätta för en dator att läsa. Några nackdelar med XML dokument är att: filerna blir nästan alltid större än dess binära motsvarighet. det finns i dagens läge inte så många applikationer som hanterar XML dokument. 3.3 Grunderna i XML Ett XML dokument är indelat i två delar: prologen och en dokument instans. Prologen beskriver dokumentets karakteristik och är i sig uppdelad i en XML deklaration och i dokumentets typ deklaration (DTD) eller en referens till ett eller flera XML scheman. En DTD och ett XML schema är två olika sätt att beskriva vilka taggar som kan finnas i dokumentet, vad taggarna har för attribut, i vilken ordning taggarna kan komma i och vilka typer innehållet i taggarna och attributen har. I dokument instansen beskrivs själva dokumentet. Det är viktigt att känna till att XML är skiftlägeskänsligt (eng. case sensitive) dvs. det spelar roll om ett ord skrivs med versaler och gemener. I detta kapitel kommer bara de absolut nödvändigaste begreppen att gås igenom. För vidare studier hänvisas till [Cos01], [GP98], [Sol99] och [LMÖ99] Välformade och giltiga dokument När man pratar om korrekta XML dokument brukar man titta på två saker och det är om de är välformade och giltiga. Ett dokument är välformat om det följer grammatiken för XML. För att ett dokument skall vara giltigt måste det finnas en DTD eller ett XML schema som dokumentet följer och följer den inte någon av dessa så är dokumentet ogiltigt. Ett dokument som saknar DTD eller XML schema är inte giltigt men inte heller ogiltigt XML deklarationen XML deklarationen är valfri men om den finns ska den alltid komma före DTD:n. Den beskriver vad det är för version av XML specifikationen dokumentet är gjort för (det finns bara version 1.0 för tillfället). Det finns fler attribut förutom version och den vanligaste är encoding som är valfri att använda. I exempel 3.2 så är den första raden en XML deklaration. encoding attributet beskriver vad för typ av teckenavkodning som används, i detta fall används Unicode. Använder man Unicode behöver inte attributet enconding användas eftersom alla XML processorer automatiskt kan upptäcka och använda Unicode. 10

11 3.3.3 DTD DTD:n är även den valfri men i förekommande fall ska den alltid komma efter XML deklarationen. I DTD:n beskrivs hur dokumentet skall vara uppbyggt för att vara giltigt. DTD:n kan vara extern, intern eller båda delarna. I exempel 3.2 visas en intern DTD. Exempel 3.2: Intern DTD för beskrivning av XML koden i exempel 3.1. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE examensarbete [ <!ELEMENT examensarbete (titel, författare+, datum)> <!ELEMENT titel (#PCDATA)> <!ELEMENT författare (#PCDATA)> <!ELEMENT datum (#PCDATA)> <!ATTLIST examensarbete kurskod CDATA #REQUIRED> ] > Elementtypsdeklaration. Elementtypsdeklarationerna (ETD) beskriver vilka element som finns och i vilken ordning de kan komma. Alla element i ett giltigt XML dokument måste finnas deklarerade i DTD:n. En ETD är uppdelad i två delar; först kommer namnet som elementet skall ha och efter namnet kommer innehållsmodellen (eng. content model). Innehållsmodellen beskriver vad som skall finnas mellan elementets start- och sluttaggar. Innehållsmodellen kan vara en av fyra typer: ANY beskriver att vad som helst kan komma mellan start- och sluttaggarna. EMPTY beskriver att inget får finnas mellan start- och sluttaggarna. Detta används när man har ett element enbart för sina attributs skull. Mixat innehåll beskriver att det kan förekomma text eller ett annat element mellan start- och sluttaggarna. Se de tre sista ETD:erna i exempel 3.2, där #PCDATA står för att det kan förekomma text mellan start- och sluttaggarna. Andra element beskriver att det förekommer andra element mellan start- och sluttaggarna. Se den första ETD:n i exempel 3.2, där komma- tecknet beskriver att de måste komma i den angivna ordningen. När man har ett mixat innehåll eller andra element mellan start- och sluttaggarna så skall innehållsmodellen stå mellan två parenteser. Det kan förutom #PCDATA och element förekomma andra tecken i dessa innehållsmodeller och de finns beskrivna i tabell 3.1. Tecken Betydelse, Bestämmer en strikt ordning mellan uttrycken. Antingen ett uttryck eller något annat uttryck. * Noll eller flera förekomster av uttrycket. + En eller flera förekomster av uttrycket.? Valfritt, antingen noll eller en förekomst av uttrycket. ( ) En grupp av uttryck som kan matchas ihop. Tabell 3.1: Tecken och dess betydelse i ett elements innehållsdeklaration. 11

12 Attributdeklarationer Om ett element har ett eller flera attribut och om XML dokumentet skall vara giltigt måste dessa attribut deklareras i DTD:n. Ett attribut deklareras i en s.k. attributlista, där alla attribut till ett element beskrivs. För varje attribut måste dess namn, attributtyp och defaultvärde anges. Det finns 10 olika attributtyper och dessa är: CDATA anger att attributet innehåller en sträng som kan bestå av alla sorters tecken. ID anger att attributet har ett unikt identifierare som det går att referera till. IDREF anger att attributet är en referens till ett element med ett unikt ID i samma dokument. IDREFS anger att attributet har potential att referera till flera element. ENTITY anger att attributet refererar till en extern oparsad entity, dvs. något som inte skall valideras som t.ex. bilder. ENTITIES som ENTITY men fler, där en applikation eller ett stylesheet bestämmer vilken ENTITY som gäller. Enumerated är en lista med de möjliga alternativ som finns t.ex. ( xl l m s ). NMTOKEN påminner om CDATA med den begränsningen att texten bara kan innehålla bokstäver, siffror samt punkter, bindestreck, kolon och understreck. NMTOKENS en sträng som består av flera NMTOKEN där dessa är separerade med mellanslag. NOTATION påminner om enumerated med den skillnaden att i en notation så kan man deklarera att ett elements innehåll har en redan deklarerad notation. Attribut kan ha defaultvärden och om det inte finns några specificerade defaultvärden så måste något av följande tre defaultvärden anges: #REQUIRED ett värde måste anges när XML dokumentet skrivs, annars blir detta dokument ogiltigt. #IMPLIED ett värde behövs ej skrivas i. #FIXED ett värde anges efter #FIXED och detta kan inte skrivas över XML schema Med XML schemats intåg har det kommit ett nytt sätt att beskriva hur ett giltigt dokument skall se ut. Det finns flera mer eller mindre stora förändringar med XML schemat mot DTD:n och här följer några: XML schemat är, till motsats till DTD:n, i sig själv välformat (följer grammatiken för XML) och med detta hoppas man att det skall bli lätt även för nybörjare att lära sig då de inte behöver lära sig två olika syntaxer. Man har utökat antalet datatyper med bl.a. integer, double, date, boolean för att bara nämna några. Användaren kan definiera egna datatyper, med vilka man t.ex. kan definiera flera element som har samma typ. Fullt stöd för namnrymder. 12

13 Referens av XML scheman Precis som DTD:n så är XML schemat valfritt men om det skall användas måste man referera till det från dokumentinstansen. Det finns två olika sätt att referera till XML schemat och dessa beror på om elementen tillhör en namnrymd, se exempel 3.3, eller inte. Exempel 3.3: Referens av ett XML schema där elementen tillhör en namnrymd. <examensarbete xmlns= xmlns:xsi= xsi:schemalocation= exjobb.xsd > </examensarbete> I exempel 3.3 börjar man på första raden med att ange den förvalda namnrymden, vilket berättar för schemavalidatorn att alla element i denna dokumentinstans kommer från namnrymden exjobb. Med den andra raden anger man att de attribut som har prefixet xsi tillhör namnrymden för schemainstanser. Den tredje raden anger till sist att namnrymden exjobb finns definierad i exjobb.xsd Schemadeklarationen Alla XML scheman börjar med rotelementet schema som har ett flertal attribut för att ange namnrymder mm., se exempel 3.4. Exempel 3.4: Schemadeklaration med förvald namnrymd. <?xml version= 1.0?> <schema xmlns:xsd= targetnamespace= xmlns= >... </schema> I exempel 3.4 börjar man på första raden med att ange att de element som används för att skapa XML schemat kommer från namnrymden och alla dessa element har prefixet xsd. Andra raden anger att alla element som deklareras i detta schema ska tillhöra namnrymden Den tredje raden anger till sist att den förvalda namnrymden är vilken är densamma som targetnamespace. Om man utelämnar de två sista raderna så finns ingen förvald namnrymd Globalt eller lokalt Det spelar en viss roll om en deklaration eller definition är global eller lokal. Det är bara globalt deklarerade element/attribut som man kan referera till och det är bara globalt definierade typer som man kan återanvända. En definition/deklaration sägs vara global om den är ett direkt barnelement till schema elementet Typer En av fördelarna med XML schemat om man jämför med en DTD är att användaren kan skapa egna typer. Det finns två olika typer: enkla och komplexa typer och där den enkla har taggen simpletype och den komplexa har taggen complextype. En komplex typ 13

14 används när man definierar en typ som beskriver ett element som har barnelement och/eller attribut och en enkel typ används när man vill derivera egna typer utifrån de inbyggda typerna som redan finns i XML schemat. En typ definition kan vara antingen namngiven eller anonym. Med namngiven menas att den är global och har ett namn och med anonym menas att den är nästlad (lokal) inne i en annan typdefinition. Anledningen till att man har anonym typdefinition är att vissa typer bara kommer att refereras en gång och innehåller väldigt få krav, och det anses att den namngivna typdefinitionen blir lite klumpig vid sådana tillfällen [Cos01]. De enkla typerna finns beskrivna i avsnitt och de komplexa typerna i avsnitt Elementdeklaration Med en elementdeklaration beskrivs vad en tagg har för namn och dess egenskaper. En elementdeklaration kan både vara global eller lokal (nästlad). Det finns ett flertal attribut till element taggen och de viktigaste är: name namnet på taggen. type namnet på typen, kan både vara enkla och komplexa typer. Används tillsammans med name attributet när typen är namngiven. ref kan användas istället för name och type attributen, men inte samtidigt. Man refererar till en globalt deklarerad element genom att ange elementets namn. minoccurs anger det minimala antalet förekomster av taggen. Skall vara ett heltal som är större än 0, anges inte detta attribut så används default värdet som är 1. maxoccurs anger det maximal antalet förekomster av taggen. Skall vara ett heltal större än 0 eller unbounded om antalet är obegränsad, anges inte detta attribut så används default värdet som är 1. substitutiongroup anger att elementet kan användas överallt där ett annat element (det som står som värde) ska finnas. Kräver att elementet är av samma typ eller deriverad från den typ som det utbytbara elementet är av. abstract anger om värdet är true att elementet inte får förekomma i dokumentet instansen, men att de element som kan byta ut det abstrakta elementet (med substitutiongroup) kan förekomma på dess plats. Av de attribut som beskrivits ovan så kan name och type användas både vid lokala och globala deklarationer. substitutiongroup och abstract kan endast användas vid globala deklarationer och de övriga endast vid lokala deklarationer Attributdeklaration Med en attributdeklaration beskriver man namnet och egenskaper för ett attribut. Precis som för elementdeklarationen kan ett attribut deklareras både globalt och lokalt. Om ett element har både attribut i sig och barnelement skall attributen alltid deklareras efter dess barnelement. Det finns ett flertal attribut till attribute elementet och de viktigaste är: name namnet på taggen, används tillsammans med type attributet. type namnet på typen, kan bara vara enkla typer. ref kan användas istället för name och type attributen, men inte samtidigt. Man refererar till ett globalt deklarerat attribut genom att ange attributets namn. use specificerar hur attributet skall användas. Det finns ett flertal olika alternativ och motsvarar defaultvärdet vid attributdeklarationen för DTD:s (se avsnitt 14

15 ) med den skillnaden att det finns flera alternativ. De olika alternativen beskrivs nedan. value används för att specificera ett värde om use attributet är fixed eller default. Av de attributen som beskrivits ovan så kan name och type användas både vid lokala och globala deklarationer. De övriga skall bara användas vid lokala deklarationer. use och value attributen kan nämligen användas globalt men man bör inte göra detta då dessa bara har betydelse inne i en elementdeklaration [Cos01]. Det finns flera olika alternativ för use attributet och dessa är de vanligaste: required attributet måste användas i dokumentinstansen. fixed ett värde anges i value attributet i XML schemat och detta värde kan ej skrivas över i dokumentinstansen. optional det är valfritt om attributet skall användas eller inte i dokumentinstansen. default ett värde anges i value attributet i XML schemat och detta värde används om användaren inte använder attributet i dokumentinstansen Enkla typer Det finns över 40 st olika typer som finns inbyggda i XML schemat, av dessa finns de tio attribut typerna för DTD:n som beskrevs i avsnitt Av alla dessa typer sägs 13 vara primitiva och de övriga är deriverade från de primitiva eller andra deriverade typer. Användaren kan dessutom definiera egna typer genom att derivera någon av de enkla typerna. I exempel 3.5 definieras en ny typ som heter minaheltal, där man utgår från typen integer och begränsar den så att heltalet måste vara mellan 0 och 10. Användaren kan dessutom definiera bl.a. egna listor, unioner, enumerations och mönster (eng. patterns) mm. Exempel 3.5: Definiera en egen heltalstyp. <xsd:simpletype name= minaheltal > <xsd:restriction base= integer > <xsd:minexclusive value= 0 /> <xsd:maxexclusive value= 10 /> </xsd:restriction> </xsd:simpletype> Komplexa typer Som förklarats i avsnitt , så används en komplex typ när man definierar typer som beskriver ett element som har barnelement och/eller attribut. Exempel 3.6: XML schema som beskriver XML koden i exempel 3.1. <schema > < xsd:element name= examensarbete type= exjobbstyp /> < xsd:completype name= exjobbstyp > < xsd:sequence> < xsd:element name= titel type= xsd:string /> < xsd:element name= författare type= xsd:string maxoccurs= unbounded /> < xsd:element name= datum type= xsd:date /> </ xsd:sequence> < xsd:attribute name= kurskod type= xsd:string use= required /> </ xsd:complextype> </schema> 15

16 I exempel 3.6 visas ett XML schema som innehåller en komplex typdefinition. sequence element är ett s.k. grupperingselement och med den specificeras den ordning som elementen måste ha i dokumentinstansen. Det finns flera användbara grupperingselement t.ex. choice eller any. Med choice menas att i normala fall endast ett av elementen kan användas i dokumentinstansen. Genom att använda attributen minoccurs och maxoccurs till choice elementet kan man dock specificera hur många gånger de olika elementen kan finnas i dokumentinstansen. Ordningen mellan elementen spelar ingen roll i detta fall. Med all elementet så måste alla elementen finnas med i dokumentinstansen om inte elementets minoccurs attribut är 0, men ordningen mellan elementen spelar ingen roll. Det är dock ett krav att element taggens attribut minoccurs är 0 eller 1 och att maxoccurs är 1 för att all elementet skall kunna användas. Precis som för element taggen kan complextype taggen ha attributet abstract. Om värdet på attributet är true så får element som är av denna typ inte förekomma i dokumentinstansen. Däremot får element som har en typ som är deriverad utifrån den abstrakta typen förekomma i dokumentinstansen Entiteter På ett enkelt sätt kan man säga att en entitet är en sorts fördefinierad text som kopplas till ett entitetsnamn och när entitetsnamnet refereras så skrivs den fördefinierade texten ut. Detta är dock inte hela sanningen då det finns flera olika typer av entiteter: fördefinierade, generella, parameter, oparsade, parsade, interna och externa, och de ska alla behandlas på olika sätt Element och attribut Det finns två olika typer av element, de som består av en start- och sluttagg, som de lokala elementdeklarationerna i exempel 3.6, och de som endast består av en tagg, som den globala elementdeklarationen i exempel 3.6. Ett element kan ha noll eller flera attribut. Varje attribut har ett namn och ett värde och värdet måste finnas i en sträng som begränsas med antingen två citattecken eller två apostroftecken Kommentarer En kommentar i XML ser precis likadan ut som i HTML, se exempel 3.7. En kommentar kan skrivas i princip var som helst förutom i deklarationer, taggar och i andra kommentarer. Exempel 3.7: Kommentar i XML. <!-- Detta är en kommentar i XML och i HTML --> 3.4 XML vokabulär Ett XML vokabulär är ett uppmärkningsspråk som bygger på XML, men där det har skapats taggar för en organisations eller ett företags speciella syfte. Bl.a. skapar flera organisationer rekommendationer om XML vokabulär för just deras område och några exempel är bl.a. CML (Chemical Markup Language) [MR01] och MathML (Mathematical Markup Language) [W3C01a] som beskriver kemiska respektive matematiska dokuments uppbyggnad. Vi skall titta närmare på ett par 16

17 uppmärkningsspråk för geografiska tillämpningar, GML som är en rekommendation från OGC och ArcXML som företaget ESRI använder som ett interface mellan flera av sina applikationer GML 1.0 GML (Geography Markup Language) 1.0 [OGC00] är en rekommendation för GIS som bygger på XML och är framtagen av OGC. Rekommendationen är tänkt att användas för transport och lagring av geografiska data och utgår från OGC specifikation för enkla geografiska objekt (eng. simply geography features). Rekommendationen innehåller två DTD:er, en för geometri och en för geoobjekt som bygger på de geometriska, samt en RDF (Resource Description Format) schemadefinition. Dessutom finns det ett flertal DTD:er som representerar olika sätt att beskriva spatiala referenssystem, men dessa är långt ifrån färdiga Enkla geografiska objekt I specifikationen för de enkla geografiska objekten så utgår man ifrån det 2- dimensionella planet, dvs. att alla koordinater har ett x- respektive ett y-värde. Det finns tre grundobjekt och dessa är punkter, linjer och polygoner. Dessa kan sedan kombineras till multi-punkter, multi-linjer, multi-polygoner eller till andra komplexa geografiska objekt GML profiler Det finns tre olika typer av profiler i GML rekommendationen. Profil 1 är tänkt att användas av dem som inte är villiga att utveckla egna specifika DTD s för sina applikationer. I detta fall måste man använda sig av både GML Feature och GML Geometry DTD:erna. Profil 2 i motsats till profil 1 är den tänkt att användas av dem som är villiga utveckla sin egen specifika DTD för sin applikation. Precis som i profil 1 använder man GML Geometry DTD:n men skapar en egen DTD för sina egna objekt som refererar till GML Geometry DTD:n. Profil 3 är tänkt att användas av dem som vill använda RDF (Resource Description Framework) och RDF scheman. Det krävs i detta fall att användaren skapar en applikationsspecifik RDF schema definition som använder sig av GML RDF schemadefinition. RDF är ett ramverk för metadata och används för utbyte av metadata mellan applikationer över Internet. Det är tänkt att inte använda RDF i detta arbete och gås därför inte igenom noggrannare här GML Geometry DTD Det finns över 30 element beskrivna i DTD:n för geometrin i GML 1.0. Av dessa kallas åtta geometriska klasser och dessa är: Point en punkt består av en koordinat. LineString en linje består av två eller flera koordinater, med räta linjer mellan koordinaterna. LinearRing en linjär ring består av fyra eller flera koordinater, med räta linjer mellan koordinaterna. Den första och sista koordinaten måste vara densamma. Polygon en polygon består av en yttre linjär ring och av noll eller flera inre linjära ringar. MultiPoint en multipunkt består av en eller flera pointmember, som i sin tur består av en punkt. 17

18 MultiLineString en multilinje består av en eller flera linestringmember, som i sin tur består av en linje. MultiPlygon en multipolygon består av en eller flera polygonmember, som i sin tur består av en polygon. GeometryCollection en komplex geometri består av en eller flera av geometrymember, som i sin tur består av någon de ovanstående klasserna (dock ej LinearRing). Alla dessa element har två attribut, nämligen ID och srsname (LinearRing saknar denna), och båda attributen är valfria. ID är objektets eventuella identifieringsnummer och srsname är namnet på det spatiala referenssystem i vilken mätningarna har gjorts. Grunden för de geometriska klasserna är elementet coordinates som består av lista av x- och y-koordinater. Oavsett hur många koordinater en klass skall ha så är det coordinates elementet som representerar själva geometrin. Elementet har tre attribut: decimal, cs och ts, och dessa är alla valfria. decimal anger vilket tecken som skall användas som decimalavskiljare och en punkt är förvald som tecken. cs anger vilket tecken som ska vara mellan x- och y-koordinaten och ett komma förvalt som tecken. ts anger vilka tecken som skall avgränsa två koordinatpar och de förvalda tecknen är mellanslag, return eller tab. Det finns förutom de geometriska klasserna och elementet coordinates ytterligare fyra element i DTD:n som behövs förklaras och dessa är: Box en box består av två koordinater och används för att visa utbredning och koordinaterna representerar det övre vänstra hörnet och det nedre högra hörnet av en rektangel. Har som de geometriska klasserna attributen ID och srsname med den skillnaden att det krävs att det finns ett värde för srsname. name används för att användaren kan namnge ett objekt. description används så att användaren skall kunna ge en beskrivning av objektet. boundedby används för att visa utbredningen för ett eller flera geometriska objekt och kräver i sin tur ett box element GML Feature DTD Feature DTD:n innehåller definitioner av fem olika element. DTD:n får tillgång till den geometriska DTD:n genom att referera till den som en parameterentitet. De fem elementen är: Feature är ett geoobjekt som innehåller de valfria barnelementen: description, name och boundedby samt noll eller flera förekomster av barnelementen: property och geometricproperty (se beskrivningar nedan). Har dessutom det valfria attributet identifier som skall användas inom en samling av geoobjekt. FeatureCollection är en samling av geoobjekt och har samma definition som Feature med den skillnaden att den kan även innehålla noll eller flera featuremember. featuremember innehåller antingen en Feature eller en FeatureCollection. geometricproperty används för att ge en geometri till ett geoobjekt och kräver i sin tur någon av de 8 geometriska klasserna mellan start- och sluttaggarna. property används för egenskaper som inte är geometriska. Har attributet type som anger typen för det data som finns mellan elementets start- och sluttaggar. 18

19 Typerna kan antingen vara boolean, integer, real eller string, där string är dess förvalda värde. Alla dessa element kräver attributet typename förutom de attribut som beskrivits ovan. typename anger namnet på geoobjektet/egenskapen/medlemmen. I exempel 3.8 så visas en dokumentinstans där man använt sig av de färdiga elementen för geoobjekt mm. enligt profil 1. Exempel 3.8: Liten beskrivning av Eskilstuna med avseende på lyktstolpar. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE FeatureCollection SYSTEM "C:\exjobb\GML\gmlfeature.dtd"> <FeatureCollection typename="kommunmodell"> <description>geometrisk beskrivning av Eskilstuna kommun</description> <name>eskilstuna</name> <boundedby> <Box srsname="epsg:4326"> <coordinates></coordinates> </Box> </boundedby> <property typename="datum" > </property> <featuremember typename="medlem"> <Feature typename="lyktstolpe"> <property typename="stolpnummer" type="integer">1</property> <property typename="stolpmaterial">järn</property> <geometricproperty typename="plats"> <Point> <coordinates></coordinates> </Point> </geometricproperty> </Feature> </featuremember> </FeatureCollection> Applikationsspecifik DTD Om en användare vill följa profil 2 och skapa en DTD som är specifik för sin applikation så finns det några regler som måste följas. Dessa regler säger egentligen att de element som skapas måste påminna om elementen Feature, FeatureCollection och featuremember från GML Feature DTD:n. Istället för att använda Feature elementet och dess attribut typename så döper man elementet till t.ex. värdet för typename. description, name, och boundedby elementen måste fortfarande kunna användas och en geometrisk egenskap måste fortfarande finnas med. Det fungerar på motsvarande sätt för FeatureCollection, featuremember, property och geometicproperty elementen. I exempel 3.9 visas hur dokumentinstansen skulle vara om man gjorde som i exempel 3.8 men använde sig av en applikationsspecifik DTD. I detta fall är DTD:n intern och man refererar till den geometriska DTD:n som en parameterentitet. För att påvisa vilka element som vi skapat så är dessa elementen i exemplet skrivna helt med versaler. 19

20 Exempel 3.9: Liten beskrivning av Eskilstuna med avseende på lyktstolpar igen. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE KOMMUNMODELL [ <!ENTITY % GMLGEOMETRYDTD SYSTEM "C:\exjobb\GML\gmlgeometry.dtd"> %GMLGEOMETRYDTD; <!ELEMENT KOMMUNMODELL (description?,name?,boundedby,datum,medlem*)> <!ELEMENT DATUM (#PCDATA) > <!ELEMENT MEDLEM (LYKTSTOLPE)> <!ELEMENT LYKTSTOLPE (description?,name?, boundedby?, STOLPNUMMER, STOLPMATERIAL, PLATS)> <!ELEMENT PLATS (Point)> <!ELEMENT STOLPNUMMER (#PCDATA)> <!ELEMENT STOLPMATERIAL (#PCDATA)> ]> <KOMMUNMODELL> <description>geometrisk beskrivning av Eskilstuna kommun</description> <name>eskilstuna</name> <boundedby> <Box srsname="epsg:4326"> <coordinates></coordinates> </Box> </boundedby> <DATUM> </DATUM> <MEDLEM> <LYKTSTOLPE> <STOLPNUMMER>1</STOLPNUMMER> <STOLPMATERIAL>järn</STOLPMATERIAL> <PLATS> <Point> <coordinates></coordinates> </Point> </PLATS> </LYKTSTOLPE> </MEDLEM> </KOMMUNMODELL> Utvärdering Om GML 1.0 skulle användas som protokoll för transport av data mellan handdator och stationär dator så skulle det vara profil 2 som skulle vara intressant i detta fall. Detta för att man kan skapa sina egna typer av geoobjekt och få dessa namnsatta på ett enkelt och beskrivande sätt. Det finns vissa tvetydigheter i geometri DTD:n samt i själva beskrivningen av den. Enligt kommentarer i DTD:n och i beskrivningen av den, skall MultiPoint, MultiLineString, MultiPolygon och GeometryCollection bestå av noll eller flera element av en viss typ, men i alla dessa fall så står det i själva DTD:n att de skall bestå av ett eller flera element av en viss typ. Har här utgått ifrån att det är DTD:n som är den rätta. GML 1.0 är i dagens läge inte moget för att användas för vårt ändamål. GML 1.0 är bara en rekommendation och är fortfarande ute på remiss hos OGC medlemmar. Detta medför att den inte är stabil än och kan komma att ändras. Men även om den godkänns och får status som teknisk specifikation, så anser jag att den inte är användbar. Detta för att den bygger på enkla geografiska objekt och dessa är 2- dimensionella i motsats till GIVAS-projektet som bygger på 3-dimensionella 20

21 geoobjekt. I framtiden skulle det kunna vara möjligt att använda GML, då det är tänkt att kommande versioner även skall kunna hantera andra geografiska modeller som OGC har. Det finns även en stor nackdel med syntaxen i GML 1.0 Geometry DTD:n. Det är att geoobjekt som består av två eller flera koordinater, som t.ex. linjer, bara har ett coordinates element i sig och att detta coordinates element innehåller en lista på alla koordinaterna. När man gör på detta sätt så kan ett geoobjekt vara giltigt (den följer strukturen som är beskriven i DTD:n) men ändå vara felaktig då endast en koordinat har angivets som innehåll inom koordinater taggen. Detta syns tydligt i exemplen 3.8 och 3.9 där coordinates elementet är tom på alla ställen, men ändå är dokumenten giltiga. Ett enkelt sätt att åtgärda problemet är att en koordinat tagg bara kan innehålla ett xy-par och linjer måste ha minst två koordinater i sig. GML 1.0 kommer aldrig att nå status som teknisk specifikation. Under examensarbetets gång kom en helt ny rekommendation ut som avhandlas i nästa avsnitt. Grunderna är dock desamma och utredningen om GML 1.0 hade kommit så långt att jag anser att denna del är en naturlig del av rapporten GML 2.0 GML 2.0 [OGC01] är en helt ny rekommendation av GML och kom ut den 20 februari Den bygger till stor del på GML 1.0 med den stora skillnaden att DTD:erna är utbytta mot XML scheman. Rekommendationen innehåller tre XML scheman; en för geometri och en för geoobjekt som bygger på de geometriska, samt en för s.k. XLinks. XLink (XML Linking Language) är en föreslagen rekommendation hos W3C och används för att länka samman element i interna och/eller externa dokument. XLinks schemat kommer inte att beskrivas i denna rapport. I GML 2.0 måste användaren skapa ett applikationsspecifikt schema. Det finns strikta regler för hur detta skall gå till för att det ska anses att man följer rekommendationen Geometry Schema Det finns inga större skillnader mellan den geometriska DTD:n i GML 1.0 och det geometriska schemat i GML 2.0 förutom det att man just använder XML schema istället för en DTD. Detta betyder att de typerna för attributen och elementen har ändrats, men dessa ändringar kommer inte att redovisas här. Elementen name och description finns inte längre kvar, de har i GML 2.0 flyttats till Feature schemat. Det finns även andra element som inte togs upp i beskrivningen av GML 1.0 som flyttats till Feature schemat. Namnen på klasserna och elementen är desamma förutom ett undantag och det är klassen GeometryCollection som bytt namn till MultiGeometry. Attributet Id som fanns för alla klasser i DTD:n är nu ersatt med attributet gid istället, men i övrigt är attributen desamma. Den största skillnaden är att det kommit till ännu ett element för att beskriva koordinater och att det är reglerat hur många förekomster de olika klasserna kan innehålla detta element. Elementet som heter coord har tre barnelement X, Y och Z där X 21

22 måste finnas medan de två övriga är valfria. Däremot finns även elementet coordinates kvar så att användaren kan välja hur man skall representera koordinaterna. Det har även tillkommit några abstrakta element som _Geometry och _GeometryCollection. Som regel har alla abstrakta element ett understreck tecken framför själva namnet och detta gäller genom hela rekommendationen. Det finns även tre abstrakta supertyper, från dessa härstammar alla element (även de abstrakta) utom de för koordinaterna Feature Schema Feature schemat har ändrats relativt mycket om man jämför med Feature DTD:n i GML 1.0. Förutom att vissa element har flyttats till Feature schemat så har elementen Feature, FeatureCollection, och property tagits bort helt, varför användaren nu måste skriva ett applikationsspecifikt schema för att kunna använda rekommendationen. För att användaren skall kunna skapa egna objekt, samlingar av objekt mm., har det skapats tre abstrakta element som man skall bygga vidare på och dessa är _Feature, _FeatureCollection och _geometricproperty. De icke geometriska egenskaperna för ett objekt måste användaren lägga till i applikationsschemat. De element som ska vara barnelement till featuremember måste nu härstamma från _Feature eller _FeatureCollection. Det finns även fem abstrakta supertyper, från vilka alla element (även de abstrakta) härstammar. Dessa används för att skapa egna objekt mm. i applikationsschemat Applikationsspecifikt schema Det finns vissa regler som ett applikationsschema måste följa för att det ska anses stödja rekommendationen och dessa är: 1. applikationsschemat måste följa de utvecklingsregler som finns beskrivna i avsnitt 5.2 i rekommendationen. 2. applikationsschemat får inte ändra namn, definition eller datatyper för obligatoriska element. 3. abstrakta typdefinitioner får utökas och begränsas fritt. 4. applikationsschemat måste göras tillgängligt för alla som tar emot filer som bygger på applikationsschemat. 5. relevanta scheman måste specificera en mål namnrymd (eng. target namespace) och denna får inte vara (namnrymden för GML). Utvecklare kan skapa sina egna typer för objekt eller för samlingar av objekt. Dessa typer måste i grund och botten vara deriverade från antingen gml:abstractfeaturetype eller gml:abstractfeaturecollectiontype. Genom att antingen utöka eller begränsa den abstrakta supertypen med egna attribut, geometriska element och/eller ickegeometriska element så skapar man en ny typ. Element av dessa typer kan sedan substitueras mot andra element som härstammar från den abstrakta supertypen. Utvecklaren kan även skapa egna associationstyper för objekt. Dessa måste vara deriverade från gml:featureassociationtype och används för att bestämma vilka objekt som kan ingå som medlemmar i en samling av objekt. I exempel 3.10 visas ett applikationsschema som motsvarar DTD:n i exempel 3.9. Som synes är schemat betydligt större än motsvarande DTD. 22

23 Exempel 3.10: Applikationsschema som motsvarar DTD:n i exempel 3.9. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace="exjobb" xmlns:ex="exjobb" xmlns:gml=" xmlns=" > <!-- konstruktioner från GML Feature och Geometry schemana importeras--> <import namespace=" schemalocation="c:\exjobb\gml\feature.xsd"/> <!-- Globala element deklarationer --> <element name="kommunmodell" type="ex:kommunmodelltyp" substitutiongroup="gml:_featurecollection"/> <element name="medlem" type="ex:medlemtyp" substitutiongroup="gml:featuremember"/> <element name="lyktstolpe" type="ex:lyktstolpetyp" substitutiongroup="ex:_kommunfeature"/> <!-- Restriktioner för vilka geoobjekt som får förekomma i kommunmodellen --> <element name="_kommunfeature" type="gml:abstractfeaturetype" abstract="true" substitutiongroup="gml:_feature"/> <!-- typ definitioner för kommunmodellen --> <complextype name="kommunmodelltyp"> <complexcontent> <extension base="gml:abstractfeaturecollectiontype"> <sequence> <element name="datum" type="date"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="medlemtyp"> <annotation> <documentation> Bara de geoobjekt eller samlingar av goeobjekt som är deklarerade med _KommunFeature kan vara medlemmar i kommunmodellen </documentation> </annotation> <complexcontent> <restriction base="gml:featureassociationtype"> <sequence minoccurs="0"> <element ref="ex:_kommunfeature"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> </restriction> </complexcontent> </complextype> <complextype name="lyktstolpetyp"> <complexcontent> <extension base="gml:abstractfeaturetype"> <sequence> <element name="stolpnummer" type="integer"/> <element name="stolpmaterial" type="string"/> <element name="plats" type="gml:pointpropertytype"/> </sequence> </extension> </complexcontent> </complextype> </schema> 23

24 I exempel 3.11 visas en dokumentinstans till applikationsschemat i exempel Det är några förändringar mot dokumentinstansen för motsvarande DTD. Dessa är att alla element som finns beskrivna i Feature- eller Geometry-schemana har namnrymden gml samt att DATUM elementet nu står sist efter alla medlemmar istället för före som i exempel 3.9. Exempel 3.11: Dokumentinstans till applikationsschemat i exempel <?xml version="1.0" encoding="utf-8"?> <KOMMUNMODELL xmlns="exjobb" xmlns:gml=" xmlns:xsi=" xsi:schemalocation="exjobb c:\exjobb\xmlexempel\kommun.xsd"> <gml:description>geometrisk beskrivning av Eskilstuna kommun</gml:description> <gml:name>eskilstuna</gml:name> <gml:boundedby> <gml:box srsname="epsg:4326"> <gml:coordinates/> </gml:box> </gml:boundedby> <MEDLEM> <LYKTSTOLPE> <STOLPNUMMER>1</STOLPNUMMER> <STOLPMATERIAL>järn</STOLPMATERIAL> <PLATS> <gml:point> <gml:coord> <gml:x>97982,50</gml:x> <gml:y>84742,47</gml:y> </gml:coord> </gml:point> </PLATS> </LYKTSTOLPE> </MEDLEM> <DATUM> </DATUM> </KOMMUNMODELL> Utvärdering Till skillnad till föregångaren GML 1.0 så är GML 2.0 bättre utrustat för framtida bruk. I och med att man frångått DTD:n till fördel för XML schema så kommer man att kunna utnyttja XML bättre. De stora nackdelarna med GML 1.0 är nu i princip lösta. Nu kan man använda sig av 3-dimensionella geoobjekt och syntaxen har ändrats så att t.ex. en linje måste innehålla minst två koordinater och inte en lista av koordinater som i GML 1.0. Anledningen till att det står i princip är att man fortfarande kan använda en lista av 2-dimensionella koordinater som i sig inte går att validera. GML 2.0 är dock väldigt trubbigt i vissa lägen. När man i framtiden skall importera objekt så är det önskvärt att man skulle kunna validera dessa samtidigt. Då GML 2.0 är mycket generellt så kan det uppstå problem när man använder det för GIVAS som är väldigt specialiserat. Ett exempel är att coord elementet bara kräver att det skall finnas en x-koordinat medan det för GIVAS krävs minst två koordinater. Detta skulle dock gå att lösa genom lite extra kod som ligger utanför själva valideringen. 24