N O R K A R T G E O S E R V I C E A S. Datamodeller



Like dokumenter
NGIS-API og ny forvaltningsløsning for FKB-data. Teknologiforum for Norge digitalt Gardermoen 2014

NGIS-API. Teknisk gjennomgang av NGIS API 9/

Overordnet beskrivelse

Romlig datamanipulering

Sentral Felles Kartdatabase - Krav til dataene. Fagdag - Utveksling og forvaltning av geodata Nils Ivar Nes, 22.mai 2017

SOSI-forvaltning - logisk modell

Ajourhold av DMK i NGIS med FYSAK F2.6 Kokebok Norsk institutt for skog og landskap, Steinkjer

Krav til ferdigvegsdata fra entreprenør.

AJOURHOLD AV AR5 I QMS

Dokumentasjon/introduksjon til Arealis_db

Oblig 4Hybelhus litt mer tips enn i oppgaven

Workshop NGIS API. Lars Eggan, Norconsult Informasjonssystemer desember 2014

Denne notatet er laget for å forklare hvordan SOSI Ledning-modellen som nå snart er klar fra SOSI Ag7b, kan brukes.

Retningslinjer forholdet objektkatalog og produktspesifikasjon

SOSI generell objektkatalog og objektkatalogen i en produktspesifikasjon

1. Finn klassene (hvilke objekter er det i problemet) 1. Dataene som beskriver problemet (hvilke objekter har vi og hvor mange klasser er det?

SOSI standard - versjon Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

BOKMÅL Side 1 av 5. KONTERINGSEKSAMEN I FAG TDT4102 Prosedyre og objektorientert programmering. Onsdag 6. august 2008 Kl

Inf109 Programmering for realister Uke 5. I denne leksjonen skal vi se på hvordan vi kan lage våre egne vinduer og hvordan vi bruker disse.

Introduksjon til SOSI_db SOSI-standarden på database-format

Object interaction. Innhold. Abstraksjon Grunnleggende programmering i Java Monica Strand 3. september 2007.

1. Definisjoner Forholdet mellom SOSI fagområdestandard og SOSI produktspesifikasjon SOSI fagområdestandard... 4

Oppsummering fra arbeidet med tekniske avklaringer for implementering av GeoSynkronisering Nils Ivar Nes

INF1300 Introduksjon til databaser

SOSI-standard - versjon SOSI Del 3 Produktspesifikasjon for FKB Naturinfo Side 1 av 16

SENTRAL FELLES KARTDATABASE. Geir Heksem

Veileder for innføring av geosynkronisering av plandata

AJOURHOLD AV AR5 I QMS

Januar versjon

Ajourhold av DMK i FYSAK F2.6 Kokebok Norsk institutt for skog og landskap, Steinkjer

Noen ArcGIS-operasjoner

Figuren over viser en parallell linje hvor startpunkt og endepunkt ligger på innsiden av toleransen.

Harmonisering og kommunikasjon bygg/kart v/erling Onstein, Statens kartverk STEDSDATA - TIL NYTTE FOR SAMFUNNET

Brukerveiledning. & tips til feilsøking i sosi-data

Algoritmer og datastrukturer Kapittel 2 - Delkapittel 2.1

INF1000: Forelesning 7. Konstruktører Static

INF1000: Forelesning 7

Kapittel 1 En oversikt over C-språket

Modellering av data. Magnus Karge, Kartverket

Kort om meg. INF1000 Uke 2. Oversikt. Repetisjon - Introduksjon

AJOURFØRING AV DMK I FYSAK G 1.32

Geosynkronisering og GML: Implementasjon gjennom prosjektet Sentral lagring av FKB. Nils Ivar Nes,

JavaScriptbibliotek. Introduksjon MVVC. Informasjonsteknologi 2. Gløer Olav Langslet Sandvika VGS

HØGSKOLEN I SØR-TRØNDELAG

1 Kodegenerering fra Tau Suiten

9 FKB LedningVa (Vann og avløp)

EØS-tillegget til Den europeiske unions tidende. KOMMISJONSFORORDNING (EU) nr. 1088/2010. av 23. november 2010

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner

INF1000 HashMap. Marit Nybakken 2. november 2003

1. SQL datadefinisjon og manipulering

Sprettende ball Introduksjon Processing PDF

SOSI-modell i MSAccess (Uferdig notat)

Askeladden Release-logg 30. august 2012

Avdekke feil i AR5 i WinMap Skog og Landskap , Jørn Storholt

Velkommen til en liten demo av Novapoint DCM 19 basis

Transaksjonsstandard for virkesomsetningen i Norge. Transportoppdrag. Versjon 2.0. Desember 2007 SKOG-DATA AS

Lagring av objekt orienterte, infrastruktur informasjons-modeller med Quadri Modell Server (basert på modelleringsstandarden ISO TC 211)

To RDF or not to RDF Fagdag om Noark 5 og RDF

Quadri DCM Et system for modellbasert samhandling

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs

INF1000 Prøveeksamen Oppgave 7 og 9

TDT4105 Informasjonsteknologi, grunnkurs. Introduksjon til programmering i Matlab. Rune Sætre / Anders Christensen {satre, anders}@idi.ntnu.

Programmeringsspråket C Del 3

Hva er nytt i GeoGebra 3.0? Sigbjørn Hals

Programmeringsspråket C Del 3

Skredsikring, forbygning (ID=850)

FEILSØK I AR5 I WINMAP

Vi starter straks FME WEBINAR Sigbjørn Tillerli Herstad sigher@norkart.no

Kapittel 13 Advanced Hypertext Implementation. Martin Lie Ole Kristian Heggøy

Modelerings-prinsipper SOSI Ledning

Oppslagstavle for rutetabell (ID=766)

SQL Structured Query Language. Definere tabeller Skranker Fylle tabeller med data

Erfaringer fra Miljøgata i Sokna. Novapoint 19 DCM

INF2120 Prosjektoppgave i modellering. Del 1

Oversikt. Introduksjon Kildekode Kompilering Hello world Hello world med argumenter. 1 C programmering. 2 Funksjoner. 3 Datatyper. 4 Pekere og arrays

TDT4105 Informasjonsteknologi, grunnkurs. Introduksjon til programmering i Matlab. Rune Sætre / Anders Christensen {satre,

Produktspesifikasjon: KYV_Farled

Programmeringsspråket C Del 3

Datamodellering og databaser SQL, del 2

Beskrivelse av skjermbilder og funksjoner i PayBack SingelUser.

Kanter, kanter, mange mangekanter

EKSAMENSFORSIDE SKRIFTLIG EKSAMEN

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015

GraphQL. Hva, hvorfor, hvordan

Grunnlag og datakilder for Novapoint DCM

Beskrivelse av å lage en modell

Programmeringsspråket C Del 3

Fra SOSI- til GML-format likheter og forskjeller. X, Y og Z 2019 Geir Myhr Øien, Kartverket

From a table based Feature Catalogue to GML Application schemas

INF1010 UML. Marit Nybakken 26. januar 2004

SOSI standard - versjon DEL 1 SOSI-raster

Obligatorisk oppgave 4: Lege/Resept

Triangulering, bruk av knekklinjer, hull og sammensying av flater i

Transaksjonsstandard for virkesomsetningen i Norge. Transportert virke. Versjon 2.0. Desember 2007 SKOG-DATA AS

EKSAMENSOPPGAVE. : INF-1400 Objektorientert programmering. Oppgavesettet er på 5 sider inklusiv forside

TDT4102 Prosedyre og Objektorientert programmering Vår 2015

"Dette skjer når jeg trykker på denne knappen" "Når jeg skriver i dette feltet, ser jeg at det andre forandrer seg"

CORBA Component Model (CCM)

SQL Server guide til e-lector

Kvalitetskontroll av SOSI-filer. Med programvaren Fysak

Transkript:

N O R K A R T G E O S E R V I C E A S Datamodeller

INNHOLD: 1 INNLEDNING... 2 2 GEODATA-MODELLEN... 2 2.1 INNLEDNING... 2 2.2 FORMÅL... 2 2.3 OMFANG... 2 2.4 DEFINISJONER, AKRONYMER OG FORKORTELSER... 2 2.5 GEODATA-MODELLENS MÅL OG BEGRENSNINGER... 3 2.6 GENERELL INTRODUKSJON... 3 2.6.1 Datadelen... 3 2.6.2 Objektkatalog... 4 2.6.3 Avhengigheter... 4 2.6.4 Eksempel... 4 2.7 PAKKESTRUKTUR... 6 2.7.1 Sammenheng mellom noen sentrale pakker... 7 2.7.2 Forklaring til pakkene... 7 2.8 KLASSEDIAGRAMMER... 9 2.8.1 Geodatasett (samling av objekter)... 9 2.8.2 Objektkatalog... 10 2.8.3 Objekt... 10 2.8.4 SpatialObject pakken... 11 2.8.5 Objekttype... 16 2.8.6 Type pakken... 17 2.8.7 Baseklasser... 21 3 QUERYMODELLEN... 23 3.1 FORMÅL... 23 3.2 OMFANG... 23 3.3 DEFINISJONER, AKRONYMER OG FORKORTELSER... 23 3.4 QUERY-MODELLENS MÅL OG BEGRENSNINGER... 23 3.5 KLASSEDIAGRAMMER... 23 3.5.1 Query... 24 3.5.2 Request... 26 3.5.3 Result... 28 3.5.4 Conflict... 29 4 ACTIONMODELLEN... 30 4.1 FORMÅL... 30 4.2 OMFANG... 30 4.3 DEFINISJONER, AKRONYMER OG FORKORTELSER... 30 4.4 ACTIONMODELLENS MÅL OG BEGRENSNINGER... 30 4.5 KLASSEDIAGRAMMER... 30 4.5.1 Action... 31 4.5.2 SetAction (Create og Erase)... 32 4.5.3 FeatureAction (Replace, Unlock)... 34 5 REVISJONSLOGG... 35 Side : 1

Quadri Map Server Datamodeller 1 Innledning Dette dokumentet beskriver de tre sentrale datamodellene som ligger til grunn for implementasjonen av Quadri Map Server. Modellene dokumentet omhandler er geodata-modellen som benyttes for lagring av geografiske objekter i minnet, query-modellen som benyttes for å hente ut geografiske objekter fra systemet og action-modellen som benyttes for fysisk lagring og endring av geografiske objekter. 2 Geodata-modellen 2.1 Innledning 2.2 Formål Kapittelet gir en oversikt over QMS sin geodata-modell. Denne modellen ligger til grunn for implementasjonen av Quadri Map Server. Klienter som skal utvikles mot Quadri Map Server må forholde seg til denne modellen for lagring av geografiske objekter i minnet. 2.3 Omfang I dette kapittelet finnes en oversiktlig presentasjon av geodata-modellens oppbygging. En detaljert beskrivelse av modellene finnes som HTML-basert beskrivelse og som Rational Rose-modell. 2.4 Definisjoner, akronymer og forkortelser Uttrykk Attribute AttributeType Feature FeatureType FeatureTypeGroup Geometriobjekt Geografisk objekt SpatialProperty Beskrivelse Et objekt som inneholder data om en egenskap Et objekt som beskriver en Attribute, som navn, type osv. Et objekt som oftest finnes ute i naturen Et objekt som beskriver en Feature, som navn, type osv. Et objekt som grupperer FeatureType objekter Et objekt som inneholder geometridata, som punkt, linje, rektangel osv. Et objekt som inneholder et eller flere geometriobjekter for å definere ei linje, et område el. En feature sine geografiske egenskaper. Side : 2

2.5 Geodata-modellens mål og begrensninger Modellen bygger på en tidlig versjon ( 1998) av spesifikasjoner fra ISO TC211, men er utvidet for å tilfredsstille SOSI. I dag vil det være en del begreper i ISO-modellene som mangler i denne modellen. I NGIS prosjektet var det et krav at modellen skulle eksponeres gjennom alle lag i systemet. Modellen benyttes for å distribuere og instansiere data. Modellen eksponeres for klienten gjennom tilgangs-api et. 2.6 Generell introduksjon Grovt sett består modellen av to deler, en for definisjon av objekter, objektkatalogen, og en for objekter som inneholder data, datadelen. I modellen kalles objektkatalog-objektet TypeRegistry, og innenfor her ligger alle datadefinisjonene. 2.6.1 Datadelen Datadelen benyttes for å lagre data i minnet. Alle data-objekter som skal lagres må ha referanser til objektkatalogen. I figuren nedenfor ser vi bare ett data-objekt. Til høyre i figuren ser vi objektkatalogen, som i denne figuren også inneholder kun en objektdefinisjon. Det vanlige er at objektkatalogen inneholder mange objektdefinisjoner, og at innholdet i objektkatalogen er relativt statisk (endres kun når objektdefinisjonene endres, eller når det legges til nye objektdefinisjoner). Etter hvert som man lagrer objekter med data er det datadelen som endres. Datadelen Objektkatalog (TypeRegistry) Objekt med data Objekt definsjon Objekt ObjektType: Stolpe Egenskaper : 8899 23, 234234, 30.06.1993, 3 Egenskapstyper: Kode FabrikatNr : Heltall, F.nr.: Heltall, Installert : Dato, Antall lys : Heltall Geografiske egenskaper: 30234,6620004,0 Geo. egenskapsstyper: Plassering : Posisjon(x,y,z) Figur 1:Forholdet mellom objektkatalog og datadel I figuren er det benyttet begreper på norsk. I modellen benyttes engelske begreper for det samme. Det betyr at : Objekt er i modellen beskrevet som Feature. Objekttype er i modellen beskrevet som FeatureType. Egenskap er i modellen beskrevet som Attribute. Side : 3

Egensskapstype er i modellen beskrevet som AttributeType. Geografiske egenskaper er i modellen beskrevet som SpatialPropertyObject Geografisk egenskapstyper er i modellen beskrevet som SpatialPropertyObjectType. Datadelen kan inneholde mange objekter, som f. eks.: en vegkant, en høydekurve eller et hvilket som helst annet fysisk objekt som finnes ute i naturen. 2.6.2 Objektkatalog Objektkatalogen er delen for definisjon av objekter, dvs. at den inneholder opplysninger om objektene som finnes i datadelen. Datadefinisjonene i objektkatalogen kalles i modellen for typer. 2.6.3 Avhengigheter Alle objekter som ligger lagret i modellen har en peker til objektkatalogen. Det er et krav for at de i det hele tatt skal kunne lagres. I objektkatalogen finnes informasjon om hvordan de lagrede objekter skal opprettes når en bruker ber om data. Disse referansene fra objekter til objektkatalog binder objektkatalogen. Definisjoner i objektkatalogen kan ikke endres hvis det finnes objekter som refererer til dem uten at det benyttes et kontrollerbart regelverk som også endrer tilknyttede objekter. 2.6.4 Eksempel Anta at du har plassert ut en stolpe et sted og at du vil lagre informasjon om denne. De dataene du ønsker å lagre for dine stolper er høyde, farge, plasseringsdato og plassering. Du må da starte med å legge inn et FeatureType-objekt i objektkatalogen. FeatureType-objekter har to datafelter, navn og beskrivelse. Gi FeatureType-objektet navn "Stolpe" og beskrivelse "stolpe med farge". Stolpe Høyde Farge Plassert_Dato Plassering Deretter må du fortelle objektkatalogen hvilke egenskaper du ønsker å lagre for hver stolpe. Det gjør du ved å opprette AttributeType-objekter og kople disse til FeatureType-objektet. Når det gjelder høyde må du opprette en AttributeType som beskriver et desimaltall, RealAttributeType. Denne gir du navn "Høyde", beskrivelse "Stolpens høyde", kun Lesing "Nei" (false) og obligatorisk "Ja" (true). For farge oppretter du et StringAttributeType-objekt og gir inn følgende : "Farge", "Stolpens farge", "Nei", "Ja". For Plassert_Dato oppretter du et DateAttributeType-objekt og gir inn følgende :"Dato", "Utplasseringsdato", "Nei", "Ja". For plassering oppretter du et SinglePointType-objekt og setter navn til "Plassering" og beskrivelse til "Stolpens plassering i terrenget". I tillegg kan man sette beskrankninger (contraint) på egenskapstypene for å angi for eksempel hvilke intervaller egneskapsverdiene må ligge innenfor. I dette eksempelet ser vi bort fra beskrankninger. Du er nå ferdig med definisjonen for Stolpe i objektkatalogen og systemet er nå klar til å lagre Stolpedata. Side : 4

FeatureType Navn : stolpe Beskrivelse : stolpe med farge SpatialPropertyObjectType SinglePointType : navn "plassering" : beskrivelse "stolpens plassering i terrenget" AttributeType RealAttributeType : navn "høyde" : beskrivelse "stolpens høyde" : kunlesing "nei" : obligatorisk : "ja" IntegerAttributeType : navn "farge" : beskrivelse "stolpens farge" : kunlesing "nei" : obligatorisk "ja" DateAttributeType : navn "dato" : beskrivelse "Utplasseringsdato" : kunlesing "nei" : obligatorisk "ja" Figur 2:Objekttype som beskriver stolpe Neste skritt vil da være å koble dette til et faktisk objekt: Stolpen er 5 meter høy, grå og ble utplassert 5.juni 2001 ved koordinatene: 3422.34 2523.2534 23.533 (n ø h) Opprette et objekt ved navn stolpe koblet til objekttypen. Opprette egenskapene Høyde med verdi 5, Farge= grå og Dato=05.juni2001 med de gitte verdier og koble disse til henholdsvis RealAttribute høyde, IntegerType farge og DateType dato. Denne koblingen er obligatorisk og muliggjør validering, behandling og gjenkjenning av dataene. Opprette geografiske egenskaper via et SpatialProperty-objekt i objektet Stolpe. o Vi oppretter et SinglePoint-objekt av type SinglePointType o Oppretter et QdiPosition3D-objekt til SinglePoint-objektet fordi våre data er i 3D. Dette er et basis geometriobjekt (Shape). Da kan koordinatene 3422.34 2523.2534 23.533 legges inn. Side : 5

geodatasett composedtyperegistry featuretyperegistry attributetyperegistry SpatialPropertyObjectTypeRegistry coordinatereferencesystem featuretype - name = stolpe realattributetype integerattributetype dateattributetype singlepointtype - name = hoyde - name = farge - name = dato - name = plassering feature realattribute - value = 5 integerattribute - value = 1 dateattribute - value = 20010605 singlepoint position3d - x = 3422.34 - y = 2523.2534 - z = 23.533 Figur 3:Instansdiagram for eksemplet Figuren viser eksemplet som objekter. Pilene representerer pekere. For å forenkle figuren er det ikke lagt på tekst til pekerne. Dette er det som minimum skal til for å instansiere opp det gitte eksemplet. Geodatasettet må være med for å holde sammen datadefinisjonsdel og datadel. Datadefinisjonsdelen vil typisk være et uttrekk fra objektkatalogen (arkivets objektkatalog). Objektene Geodataset og de som ender med Registry er alle administrative objekter som kun benyttes i minnet og ikke i datalager. 2.7 Pakkestruktur Dette er pakker (packages) i UML. Hver pakke inneholder et klassediagram, som typisk henger sammen med klassediagrammer i andre pakker. De stiplede pilene viser avhengigheter mellom pakker. For eksempel er pakken spatialobject avhengig av strukturer i pakkene spatialpropertyobject og attribute. Det er vanlig å bruke pakkestrukturer til å dele opp store klassediagrammer for dermed å gjøre dem mer håndterlige. Side : 6

geodataset typeregistry spatialobject type spatialproperty Object attribute spatialproperty Type primitiveattribut etype shape primitiveattribute Figur 4:Pakkestruktur i geodatamodellen 2.7.1 Sammenheng mellom noen sentrale pakker Oversikten over modellen beskrives her forenklet. I den neste kapitlene beskrives dette i detalj. Dette er en forenklet oversikt over relasjonene som finnes. Mest markant er geodatasettets hoveddeler: geografiske objekter (spatialobject) og egenskaper som beskriver disse objektkatalogen (TypeRegistry) som definerer hvilke objekttyper som er lovlige (spatialpropertytype) og lovlige egenskaper 2.7.2 Forklaring til pakkene GeodataSet TypeRegistry SpatialObject Et samlingsobjekt som samler en mengde spatialobjects og et TypeRegistry. Det inneholder ulike typer objekter som er de objektene geodatasettet består av, men kan også inneholde metaobjects som er objekter som beskriver andre objekter eller en samling av objekter. Samtidig peker det altså på en objektkatalog med alle definisjonene for objekter og egenskaper. En objektkatalog for datadefinisjoner. Det vil si at her ligger definisjonene til objekter og egenskaper. Dette er en pakke som beskriver det geografiske objektet. I geodata-modellen er Side : 7

Type SpatialProperty Object SpatialProperty Type Shape Attribute AttributeType det Feature og SpatialPropertyObject som er geografiske objekter. Type er datadefinisjonen som ligger inne i objektkatalogen. Denne pakken er spesialisert i forskjellige klasser Holder på de geometriske egenskapene til et objekt. Disse settes sammen av primitive geometriobjekter. Hovedtypene er: SinglePoint (inneholder ett enkelt punkt, Position2D eller Position3D) MultiPoint (punktsverm, flere punkter, 2D eller 3D) CurveSegment (inneholder et primitivt kurve objekt, Position2D/3D, bue eller polygon Path (et eller flere CurveSegments i vilkårlig kombinasjon) GeometrySurface (inneholder et primitivt flateobjekt, Rectangle, Circle eller Polygon Boundary (et geografisk område med yttergrense definert av en vilkårlig blanding av CurveSegments og Paths) ComplexSurface (består av en Boundary som definerer et områdes yttergrense, og ingen eller flere Boundarys som definerer hull i området.) Definerer de lovlige geometriobjekter som er lov å legge inn i et geodatasett. Er gruppen av primitive geometriske objekter og er som følger Punkttyper o Position2D o Position3D o Position2D/3DWithAttributes Flate-former o Rektangel o Sirkel o Polygon Kurve-former o Polylinje (linje med flere punkt) o Bue (2 punkter med radius) o Klotoide (ikke med i denne implementasjonen) Egenskapene blir definert av AttributeTypes som ligger i objektkatalogen. Denne pakken gir datamodellen mulighet for å lagre en ubegrenset antall egenskaper for hvert objekt, det være seg en SpatialProperty eller Feature. Egenskapene kan være primitive eller sammensatte. Dette er definisjonen av egenskapene og beskriver hver enkelt egenskaptype. Prinsippet er at typedefinisjonene slik de her er, sier langt mer om en egenskap enn f.eks. char* ville gjort. Disse typedefinisjonene blir lagt inn for alle egenskaper og kobles til SpatialObjectTypes. Det blir da klart hvilke egenskaper som er tillatt brukt i et objekt Metadata der man med metadata mener objekter som har kunnskap om en samling av objekter, vil bli behandlet som vanlige objekter. Side : 8

2.8 Klassediagrammer I dette kapitlet blir sentrale klassediagram behandlet. Innholdet i klassediagrammene forklares for hvert delkapittel. Det finnes avhengigheter mellom klassediagrammene. Klasser vil derfor vises i flere klassediagrammer. Hvilken pakke denne klassen egentlig hører hjemme i vises i parentes under klassenavnet. Ser bort fra forstavelsene Qdi i forklaringene i kapitlet. 2.8.1 Geodatasett (samling av objekter) GeodataSet-pakken beskriver et geodatasett. Geodatasettet holder på en samling objekter og det henviser til hvilken objektkatalog (TypeRegistry)disse objektene følger. Objektkatalogen er helt nødvendig for å definere datasettet. Et geodatasett kan ha peker til et referansesystem. QdiGeodataSet -spatialreferencesystem 0..1 QdiSpatialReferenceSystem (from spatialpropertyobject) 0..1 -typeregistry QdiTypeRegistry (from typeregistry) Figur 5:GeodataSet pakken SpatialReferenceSystem, herunder CoordinateReferenceSystem, beskriver hvilket koordinatsystem som er i bruk. TypeRegistry inneholder datadefinisjonene. Side : 9

2.8.2 Objektkatalog Objektkatalogen holder på definisjonene til objektene. Denne må finnes før man kan instansiere objekter (Feature) under et geodatasett. En objektkatalog for et geodatasett kan være redusert i omfang i forhold til arkivets objektkatalog. F.eks. kan det være nok at de typer som er søk ut ved en spørring, er lastet opp. Figur 6:TypeRegistry pakken Objektkatalogen inneholder opplysninger om objektene som finnes i datadelen. Klassen TypeRegistry er en generalisering av følgende klasser: FeatureTypeRegistry omfatter hvilke objekttyper som er tillatt og hvilke grupper (FeatureTypeGroup) disse inngår i. o Hver FeatureTypeGroup må være enten en enkel gruppe (SingleFeatureTypeGroup) eller en gruppe sammensatt av flere enkle grupper (ComposedFeatureTypeGroup). o Hver FeatureType har et sett med forskjellige SpatialPropertyTypes AttributeTypeRegistry inneholder to sett av egenskapstyper (hvorav ett er for predefinerte typer). SpatialPropertyTypeRegistry omfatter de lovlige geometriske typene. ComposedTypeRegistry er sammensatt av de tre nevnt ovenfor. 2.8.3 Objekt Under dette kapitlet beskrives 3 viktige delpakker : SpatialObject pakken SpatialPropertyObject pakken Side : 10

Attribute pakken Videre beskrives 2 pakker som består av enkle data benyttet som basis for de to sist nevnte pakker : Shape pakken med primitiv geometri. PrimitiveAttribute pakken med primitive egenskaper. 2.8.4 SpatialObject pakken SpatialObject pakken er den mest sentrale pakken. Den inneholder beskrivelse av Features som er det mest sentrale objektet i modellen. -metaobjects QdiSpatialObject 0..1 -spatialobjecttype QdiSpatialOb jecttype (from type) {set} -associations QdiFeature {set} -spatials QdiSpatialProp ertyobject {set} -aggregations Figur 7:SpatialObject pakken 2.8.4.1 SpatialObject pakken beskriver : Forholdet mellom objekter (QdiSpatialObject) og objekttyper. Forholdet mellom instansen av objektet og den sammensatte geometrien (QdiSpatialPropertyObject). Hvordan objekter kan knyttes til hverandre enten ved å peke til hverandre (associations) eller ved at de eier andre objekter (aggregations). Et objekt kan være et metaobjekt. Det vil si at et objekt kan beskrive en samling objekter. Feature er et objekt som kan ha egenskapsdata. Egenskapsdata lagres i egenskapsobjekter og kalles for attribute i modellen. En feature kan også ha geografiske/geometriske egenskaper, som posisjon, grense osv. Disse egenskapene kalles SpatialProperties. Det er Feature som benyttes for å representere virkelige objekter i naturen. Alt er basert på at det er featureobjektene som holder alle data som lagres. Side : 11

SpatialProperties Feature Attributes SpatialProperties GeodataSet Feature Attributes SpatialProperties Feature Attributes Figur 8:Samling av mange features med egenskapsdata I tillegg til konstruksjonen som er vist i figuren ovenfor finnes det også endel andre koblinger en Feature kan ha til andre objekter. Verdt å nevne her er muligheten en Feature har til å referere til andre Features. Feature SpatialProperties Attributes Feature SpatialProperties SpatialProperties Attributes Feature Attributes SpatialProperties Feature Attributes SpatialProperties Feature Attributes Figur 9:Nettverk av features Et eksempel på bruk av en slik struktur kan være: land - fylke - kommune osv. 2.8.4.2 SpatialPropertyObject pakken Denne pakken beskriver den sammensatte geometrien. Denne bygges opp av primitive geometrier beskrevet i neste kapittel. Denne sammensatte geometrien kan ha peker til et geografisk referansesystem slik at dette til sammen blir en geografisk egenskap ( beskriver stedfesting). Pakken inneholder følgende: SinglePoint : inneholder et enkelt punkt, Position2D eller Position3D Side : 12

MultiPoint : punktsverm, flere punkter, Position2D eller Position3D CurveSegment : inneholder et primitivt kurve objekt, Position2D/3D, Arc eller Polyline Path : et eller flere CurveSegment i vilkårlig kombinasjon. GeometrySurface : inneholder et primitivt flateobjekt, Rectangle, Circle eller Polygon Boundary : et geografisk område med yttergrense definert av en vilkårlig blanding av CurveSegmen og Path. ComplexSurface : består av en Boundary som definerer et områdes yttergrense, og et eller flere Boundarys som definerer hull i ytterområdet. QdiSpatialPropertyObject (from spatialobject) +spatialref erencesy stem 0..1 QdiSpatialReferenceSystem QdiCoordinateRef erencesy stem - coordsy s : int NetRef erencesy stem (from ObjectType) + degree : DegreeOf Detail + lev el : Lev elof Detail QdiPoint QdiCurve QdiSurface QdiMultiPoint 1..n +points -position 0..1 -/startpoint QdiSinglePoint -/endpoint 0..1 1 QdiSimpleSurface -exterior QdiComplexSurf ace 1 {set} 0..1 -interiors QdiPosition (from shape) 1 QdiCurveSegment -curv e {sequence} QdiPath -shape QdiCurveShape (from shape) 1 QdiCurv edirection - Signed : bool -curv es 1..n 1..n -curv es {sequence} QdiBoundary QdiGeometry Surf ace -shape 1 QdiSurfaceShape (from shape) Figur 10: SpatialPropertyObject pakken 2.8.4.3 Shape pakken Denne pakken beskriver primitiv geometri. Legg også merke til muligheter for å knytte attributter til punkter. Dette er gjort blant annet for å løse behovet rundt KP i SOSI. I modellen deles den primitive geometrien i tre grupper : Position som er et enkelt punkt. CurveShape som er en linje eller kurve. SurfaceShape som er en flate. I Position gruppen finnes : Position2D : et enkelt 2D punkt Side : 13

Position3D : et enkelt 3D punkt Position2DWAttributes : et enkelt 2D punkt som kan ha attributter Position3DWAttributes : et enkelt 3D punkt som kan ha attributter I CurveShape gruppen finnes : Arc : et Position2D/3D startpunkt, et Position2D/3D sluttpunkt, radius og radiustype Polyline : linje bestående av flere Position2D/3D knekkpunkter Spline : Foreløpig ikke er i bruk. I SurfaceShape gruppen finnes : Rectangle : et Position2D/3D i nedre venstre hjørne, et Position2D/3D i øvre venstre hjørne Circle : et Position2D/3D i sentrum og radius Polygon : en mangekant definert av mange Position2D/3D QdiShape QdiCurveShape QdiSurface Shape QdiSpline QdiArc - radius : double = 0. - major : bool 1 QdiPolyline -boundary QdiCircle - radius : double QdiPolygon -positions QdiRectangle -center {sequence} 1 {sequence} 1 QdiPosition -/positions -startposition - x : double - y : double 1 -endposition -lowerleft -lowerright QdiPosition 3D - z : double 1 1 QdiPosition2D 1 1 -upperleft -upperright QdiPosition3DWAttributes QdiPosition2D WAttributes -KP 0..1 QdiKP - code : int 0..1 -KP -attributes +attributes QdiAttribute (from attribute) - name : char* Figur 11:Shape pakken Side : 14

2.8.4.4 Attribute pakken Denne pakken beskriver hvordan enkle egenskaper (PrimitiveAttribute) kan settes sammen til en sammensatt egenskap (Attribute). Dette er egenskaper som består av andre egenskaper. I modellen finnes følgende komplekse egenskaper : StructAttribute En samling av forskjellige egenskaper. Benyttes ofte til å sammenstille flere PrimitiveAttribute til en logisk enhet. ListAttribute En liste av (gjentatte) like egenskaper (primitive eller sammensatte) Anta at du ønsker å lagre følgende om kvaliteten for et punkt på et kart : målemetode, nøyaktighet, synbarhet. Disse tre egenskapene kan du legge inn i hver sin PrimitiveAttribute og så legges disse igjen inn i en StructAttribute. Objektet skal nå refererer direkte til denne StructAttribute i stedet for til hver enkelt PrimitiveAttribute. {set} 1..n QdiAttribute - name : char* 1 -attributetype QdiAttributeType (from type) QdiListAttr ibute -attributes {set} {All objects in a list instance must be of the same type} QdiSingleAttribute QdiUserDefin edattribute QdiPrimitive Attribute QdiStructAttribute QdiEnumAttribute Figur 12:Attribute pakken 2.8.4.5 PrimitiveAttribute pakken Denne pakken beskriver enkle egenskaper. PrimitiveAttribute er objekter som inneholder kun én verdi. Side : 15

I modellen finnes følgende PrimitiveAttribute : BoolAttribute - true/false IntegerAttribute - heltall Integer64Attrivute - heltall, 64 bit RealAttribute - flyttall CharAttribute - enkelttegn TimeAttribute - tidspunkt DateAttribute - dato DateTimeAttribute - datotid StringAttribute - tekststreng WStringAttribute gir støtte for internasjonale tegn (for eksempel japanske skrifttegn) BlobAttribute - Lagrer en stor binær datablokk. CodeListAttribute - kodeliste lovlige koder/verdier med forklaring Figur 13:PrimitiveAttribute Pakken En Feature i modellen kan inneholde et ubegrenset antall egenskaper. 2.8.5 Objekttype Dette kapitlet beskriver de 3 viktige pakkene som inngår i typedefinering. Dette er : Type pakken SpatialPropertyType pakken PrimitiveAttributeType pakken Oppbygging av objekttype er parallell til objektdelen, men det er noen forskjeller i pakkeinndeling. Det finnes ingen Shapepakke for typedelen og AttributeType er tatt inn i Typepakken. I tillegg beskrives en pakke som inneholder definisjon av beskrankning. Side : 16

2.8.6 Type pakken Type pakken inneholder definisjonen av de ulike typene. QdiType {set} QdiSpatialObjectType QdiAttributeType -attributety pes 1..n -attributety pes {set} -spatialty pes QdiFeatureTy pe {set} QdiSpatialPropertyType QdiListAttributeTy pe 1 -attributety pe QdiSingleAttributeType QdiUserDefinedAttributeType QdiPrimitiveAttributeType QdiEnumAttributeTy pe QdiStructAttributeTy pe Figur 14:Type pakken SpatialObjectType FeatureType SpatialPropertyType AttributeType PrimitiveAttributeType ListAttributeType SingleAttributeType Geografisk objektdefinisjon. Holder på en liste med egenskapstyper Featuretypen innholder definisjon for en Feature. Featuretype beskriver feature-objektene og inneholder et sett av egenskapstyper og et sett av geometrityper. Holder på definisjonen for den sammensatte geometrien. Merk at det ikke fins definisjoner av basisgeometri i objektkatalogen. Det er også naturlig da basisgeometri ikke har egenskaper knyttet til seg og er gitt de definisjoner som finnes i datamodellen. Egenskapsdefinisjoner. AttributteType kan være av sammensatt eller primitiv natur Definsjon for egenskaper med bare én verdi. En liste av én type SingleAttributeType. Angir at egenskapstypen kan gjentas flere ganger for et gitt objekt. Kan også inneholde en liste av structattribute-typer som igjen inneholder forskjellige egenskapstyper. Definisjon for selvstendige egenskaper ( i motsetning til en liste med egenskaper) Side : 17

EnumAttributeType StructAttributeType Definerer en liste av konstante verdier. Definerer en samling av forskjellige egenskapstyper (sammensatte eller primitive). 2.8.6.1 SpatialPropertyType pakken SpatialPropertyType pakken beskriver hvilke geometrityper det er lov å definere. QdiSpatialPropertyType (from type) QdiPointType QdiCurveType QdiSurfaceType QdiMultiPointType QdiSinglePointType QdiSimpleSurfaceType QdiComplexSurfaceType QdiCurveSegmentType QdiPathType QdiGeometrySurfaceType QdiBoundaryType Figur 15:SpatialPropertyType pakken Hovedinndeling går på punkt-, kurve- og flate-objekter. Punkttyper: o Flerpunktsliste: Multipoint o Enkeltpunkter: SinglePoint Kurvetyper: o Sammensatte kurver Path o Enkelt-kurver CurveSegment FlateTyper o Enkle flater GeometrySurface o Avgrensinger Boundary o Sammensatte flater ComplexSurface - har en yttergrense og flere enkle flater innenfor 2.8.6.2 PrimitiveAttributeType pakken PrimitiveAttributeType pakken beskriver hvilke primitive egenskaper som kan defineres. Primitive egenskaper er egenskaper som inneholder kun en verdi. Side : 18

Figur 16:PrimitiveAttributeType pakken AttributeType objektene har følgende datafelter: navn (name) beskrivelse (description) kunlesing (readonly) obligatorisk (mandatory) beskrankninger (constraints). I modellen finnes følgende primitive attributtyper: BoolAttributeType - true/false IntegerAttributeType - heltall Integer64AttributeType - heltall, 64-bit RealAttributeType - flyttall CharAttributeType - enkelttegn TimeAttributeType - tidspunkt DateAttributeType - dato DateTimeAttributeType - datotid StringAttributeType - tekststreng BlobAttributeType - Store binære data. CodeLiseAttributeType - kodeliste CodeType - kode med forklaring Side : 19

En FeatureType i modellen kan inneholde et ubegrenset antall AttributeType. 2.8.6.3 Constraint pakken Denne pakken beskriver hvordan beskrankninger knyttes til egenskapene. Beskrankningene forteller om lovlige verdier og/eller hvilke sekvenser av verdier som er tillatt. Eksempel: Du har en egenskaps-type Tykkelse av type Real. Du ønsker å begrense den til en nedre verdi på 2 og en øvre verdi på 10. Du oppretter da et objekt av type QdiAND. LeftChild settes til å peke på en QdiGreaterThan som peker på en RealAttribute med verdi 2. RightChild settes til å peke på en en QdiLessThan som peker på en RealAttribute med verdi 10. Figur 17:Constraint pakken Side : 20

2.8.7 Baseklasser Denne klassen har en systemteknisk funksjon. 2.8.7.1 Base pakken Base pakken beskriver hvordan klassene i modellen arver fra de systemtekniske klassene : Base PersistentObject Dette er en teknisk konstruksjon. QdiBase QdiAttribute (from attribute) ) -attributes QdiShape (from shape) QdiPersistentObject - persistentid : int {set} QdiGeoObject QdiType (from type) ) QdiTypeRegistry (from typeregistry) QdiSpatialReferenceSystem (from spatialpropertyobject) QdiFeatureTypeGroup (from typeregistry) QdiConstrainStruct (from constrain) QdiConstrain (from constrain) ) QdiCurveDirection (from spatialpropertyobject) ) QdiKP (from shape) ) -composites 1 QdiGeodataSet (from geodataset) 1 QdiTopologyObject (from topology) {set} QdiSpatialObject (from spatialobject) -metaobjects -metaobjects Figur 18:Base klassediagram I Base ligger det en del felles metoder. F.eks. New og Delete. Alle klasser i modellen arver fra denne. Her legges det systemtekniske operasjoner som er felles for alle klasser. Med PersistentObject menes at objekter herunder vil lagres med en unik lagringsidentifikasjon kalt: persistentid. Det vil si at Attributter (egenskaper) og Shapes (basisgeometri) ikke vil identifiseres med ID ved lagring, men tilhører objekter med lagrings ID. Side : 21

Men legg merke til at GeoObject som objektene arver fra har peker til egenskapene (QdiAttribute). GeoObject er basis klasse for alle objekter, også de som måtte mangle knytning til geometri. Både Geodataset og SpatialObject er GeoObject. GeodataSet defineres ikke som type i TypeRegistry men peker til et TypeRegistry, mens SpatialObject peker til en type i et TypeRegistry. GeoObject har ikke kopling til Typeregistry, det er det SpatialObject som har. TopologyObject benyttes ikke i QMS. Side : 22

3 Querymodellen 3.1 Formål Kapittelet gir en oversikt over QMS sin query-modell. Denne modellen er en spørremodell og ligger til grunn for implementasjonen av Quadri Map Server sammen med geodata-modellen og action-modellen. Klienter som skal utvikles mot Quadri Map Server må benytte seg av querymodellen for å kunne hente ut geografiske objekter. 3.2 Omfang I dette kapittelet finnes en oversiktlig presentasjon av query-modellens oppbygging. En detaljert beskrivelse av modellene finnes som HTML-basert beskrivelse eller som Rational Rose-modell. 3.3 Definisjoner, akronymer og forkortelser Uttrykk Feature Beskrivelse Et objekt som beskriver en fysisk ting (for eksempel et hus, lysstope) 3.4 Query-modellens mål og begrensninger Modellen er en spørremodell som benyttes av klienten for å definere og begrense hvilke objekter som skal returneres når det hentes ut data fra en eller flere tjenere. Modellen definerer også klasser som inneholder reultatet av spørringene samt klasser for håndtering av eventuelle feilmeldinger som returneres av systemet. Klasser for håndtering av notifikasjon finnes også i modellen men er ikke implementert i systemet og vil derfor ikke beskrives i dette dokumentet. 3.5 Klassediagrammer I dette kapitlet blir de sentrale klassediagrammene i modellen beskrevet. Innholdet i klassediagrammene forklares for hvert delkapittel. Det finnes avhengigheter mellom klassediagrammene. Klasser vil derfor vises i flere klassediagrammer. Ser bort fra forstavelsene Qdi i forklaringene i kapitlet. Side : 23

3.5.1 Query Dette er modellen som beskriver det sentrale spørreobjektet Query. Et Query kan bygges opp av ett eller flere logiske uttrykk og geometriske former. Det er også definert enkelte forhåndsdefinerte spørringer (Extents) som tolkes spesielt av systemet. Figur 1 Query klassediagram Query Queryklassen benyttes for å spesifisere spørringen som skal utføres på en tjener. Klassen kan inneholde et referansesystem, et eller flere SpatialPropertyObjecter, et predikatuttrykk og ulike forhåndsdefinerte spørringer (extents). UserReferenceSystem angir hvilket koordinatsystem resultatet av spørringen skal transformeres til. SpatialPropertyObject beskriver en geometri som avgrenser spørringen geografisk. Geometrien må angi et lukket område og være av type SurfaceShape. Side : 24

Extents er som nevnt forhåndsdefinerte spørringer som gjør det enkelt å sette opp mye brukte spørringer. De definerte extents er heltall (definert i filen Interpreter.h) som er gitt en viss betydning og som tolkes spesielt av systemet. Se utviklerhåndboka for oversikt over aktuelle extents. Predicate Baseklassen for klassehierarkiet som benyttes for å beskrive det logiske uttrykket. BooleanExpression Benyttes for å bygge opp en logisk spørring med operatorene AND, OR eller NOT. Resultatet av en slik spørring vil alltid være TRUE eller FALSE. Klassens variabel first peker på det logiske uttrykket til venstre for operatoren mens second peker på uttrykket til høyre. Modellen er designet slik at man kan sette opp et ubegrenset antall av slike uttrykk. Statement Baseklassen for klassene som benyttes for å beskrive selve spørrekriteriene. Comparison Benyttes for å bygge opp et spørrekriterium med operatorene >, >=, <, <=, =,!=. Klassens variabel value1 peker på uttrykket til venstre for operatoren mens value1 peker på uttrykket til høyre. Slik modellen tolkes av systemet i dag må et logisk uttrykk alltid inneholde et objekt av type Comparison. Primitive Baseklassen for klassene som benyttes til å beskrive basiselementene i et logisk uttrykk. QueryAttributeType Benyttes for å definere søk etter en gitt egenskapstype som er definert for en gitt featuretype. QueryValue Benyttes for å angi en bestemt verdi som skal inngå i uttrykket. SpatialOperator, Relationship, QueryShape Disse klassene tolkes ikke av systemet og bør derfor ikke benyttes. Side : 25

3.5.2 Request Denne modellen inneholder klasser som benyttes for å angi hva slags type spørring man vil gjøre mot systemet. Skal man for eksempel hente ut objektkatalogen benyttes klassen TypeRegistryRequest, skal man hente ut geodata benyttes klassen GeodataRequest i kombinasjon med Query. Side : 26

TypeRegistryRequest Benyttes for å hente ut objektkatalogen fra en tjener. GeodataRequest Benyttes for å hente ut geodataset fra en tjener. Spørringen defineres ytterligere via GeodataRequest sitt Queryobjekt. Her defineres eventuelle geografiske begrensninger for søket, logiske uttrykk for egenskapsverdier som skal innfris etc. Se eget kapittel som omhandler Query. NotificationRequest, ShapeRequest, AttributeRequest Disse klassene håndteres ikke gjennom hele systemet og bør derfor ikke benyttes. Side : 27

3.5.3 Result Denne modellen inneholder klasser som benyttes for å returnere resultatet av en spørring tilbake til klienten. Result Baseklassen for de ulike result-klassene. Inneholder en peker til et ConflictSet som inneholder eventuelle meldinger og feil rapportert under systemets prosessering av spørringen. GeodataResult Inneholder resultatet av en spørring utført via et GeodataRequest. Har en peker til geodatasettet som inneholder de geografiske objektene som oppfylte spørrekriteriene. TypeRegistryResult Inneholder resultatet av en spørring utført via et TypeRegistryRequest. Har en peker til objektkatalogen som ble returnert. ErrorResult Inneholder en eventuell feilmelding dersom det har oppstått feil i systemet. Side : 28

3.5.4 Conflict Denne modellen inneholder klasser som benyttes for å gi informasjon og feilmeldinger om oppgaver (spørringer, actions osv) som er utført av systemet tilbake til klienten. ConflictSet Inneholder et sett av en eller flere Conflict-objekter. Conflict Klassen inneholder div. informasjon om statusen/feilen i ulike parametre, blant andre: Variabelen level angir alvorlighetsgraden av feilen som er oppstått. Kan ha en av følgende verdier: Level_Information meldingen er ren informasjon, ingen feilmelding Level_RequestProblem problemer under prosessering, men ferdig utført Level_RequestRejected prosesseringen kunne ikke utføres Level_Aborted feil oppsto under prosessering, prosessen avbrutt. Level_RequestAborted feil oppsto under forespørsel, prosessen avbrutt Level_ActionAborted feil oppsto under prosessering av action, prosessen avbrutt Variabelen ecode er en kode som angir hvor feilen oppsto. Kodene er definert og beskrevet i filen ConflictError_Code.h (enum ConflictError_Code). Side : 29

4 Actionmodellen 4.1 Formål Kapittelet gir en oversikt over QMS sin action-modell. Denne modellen er en dataoperasjonsmodell og ligger til grunn for implementasjonen av Quadri Map Server sammen med geodata-modellen og query-modellen. Klienter som skal utvikles mot Quadri Map Server må forholde seg til actionmodellen for fysisk lagring og endring av geografiske objekter. 4.2 Omfang I dette kapittelet finnes en oversiktlig presentasjon av actionmodellens oppbygging. En detaljert beskrivelse av modellene finnes som HTML-basert beskrivelse eller som Rational Rose-modell. 4.3 Definisjoner, akronymer og forkortelser Uttrykk Feature Action ActionSequence Beskrivelse Et objekt som beskriver en fysisk ting (for eksempel et hus, lysstope) Et gjøremål på tjeneren. Defineres som en Create-, Replace- eller Eraseaction. En (sekvensiell) serie av actions/gjøremål. Benyttes for å samle flere actions som skal utføres på samme tjener. 4.4 Actionmodellens mål og begrensninger Modellen er en dataoperasjonsmodell som benyttes av klienten for å lagre, slette og oppdatere objekter på en tjener. Dette vil i de fleste tilfeller være en arkivtjener. Modellen er nært knyttet til geodata-modellen. Action-modellen med de ønskede oppdateringer sendes fra klienten via tilgangs-apiet for utførelse på den aktuelle tjeneren. 4.5 Klassediagrammer I dette kapitlet blir de sentrale klassediagrammene i modellen beskrevet. Innholdet i klassediagrammene forklares for hvert delkapittel. Det finnes avhengigheter mellom klassediagrammene. Klasser vil derfor vises i flere klassediagrammer. Ser bort fra forstavelsene Qdi i forklaringene i kapitlet. Side : 30

4.5.1 Action I denne modellen finnes basisklasser for de ulike actions. Modellen beskriver også sammenhengen mellom en ActionSequence, Actions og geodatasettet. Figur 2 Action klassediagram ActionSequence ActionSequence er et objekt som holder flere actions i ei liste. Den benyttes for å sende flere actions til tjeneren i et enkelt kall. Det er ikke mulig å sende action-objekter direkte til tjeneren, de må samles i en ActionSequence. Man kan legge inn actions i den samme rekkefølge som en bruker arbeider, noe som da vil tilsvare en angre/hendelses-logg. En ActionSequence kan ha en peker til et GeodataSet. Dette geodatasettet skal inneholde alle data som de ulike actions i ActionSequencen refererer til. Action Dette er en virtuell klasse for de ulike actiontypene. Den kan inneholde en peker til et GeodataSet. Dersom ActionSequencen actionen er knyttet til også har en peker til et GeodataSet må denne peke til det samme GeodataSetett Det er altså ikke nødvendig å knytte et GeodataSet til hver Action dersom ActionSequencen inneholder en slik peker. Klassen har et stort arvehierarki under seg som kan deles i følgende hovedelementer: SetAction - manipulering av en samling av objekter FeatureAction - manipulering av enkeltobjekter ServerState - tilstanden til serveren ved gitt tidspunkt ExecuteAction - kjører en spesifisert kommando. Side : 31

4.5.2 SetAction (Create og Erase) I denne modellen finner vi klasser for actions som skal utføres for en samling av objekter. De mest benyttede klassene i denne modellen er Create som benyttes for å lagre nye objekter og Erase som benyttes for å slette eksisterende objekter. Figur 3 SetAction klassediagram Create Benyttes for å opprette nye objekter i databasen. En CreateAction kan inneholde et sett av objekter av alle typer som arver fra PersistentObject (se dokumentajon av geodatamodellen). Husk at objekter som legges til en CreateAction også må legges til GeodataSettet som ActionSequencen (evt. Actionobjektet) peker på. Implementasjonen støtter kun lagring av nye objekter (med negativ PersistentId). Alle andre objekter vil bli avvist. Erase Side : 32

Benyttes for å slette eksisterende objekter i databasen. Erase-klassen har en peker til et SelectionSet som inneholder en samling av Id ene (PersistenId) til objektene som skal slettes i basen. SelectionSet Dette er baseklassen til klassene FeatureSet, CompositeSelectionSet og QuerySet som alle benyttes for å definere en samling av objekter. FeatureSet Denne klassen holder på de unike Id ene (PersistentId) til et utvalg av objekter. I følge modellen kan utvalget bestå av alle typer objekter som arver fra PersistentObject, men i praksis er det kun objekter av typen Feature som kan legges inn i et FeatureSet. Se forøvrig beskrivelse av geodata-modellen. Husk at objekter som legges til et FeatureSet også må legges til geodatasettet som ActionSequencen (evt. Action-objektet) peker på. CompositeSelectionSet Denne klassen inneholder en samling av 2 eller flere SelectionSets. QdiQuerySet Brukes ikke pr. i dag. Side : 33

4.5.3 FeatureAction (Replace, Unlock) I denne modellen finner vi klasser for actions som benyttes til å endre eksisterende objekter i databasen. De mest benyttede klassene i denne modellen er Replace som benyttes for å endre objekter og Unlock som benyttes for å låse opp låste objekter. Replace Benyttes for å endre et eller flere eksisterende objekter i databasen. Kan holde på en samling av objekter som skal oppdateres. Objektene må være av typen Feature. De oppdaterte objektene må ha samme PersistenId som det objektene hadde i utgangspunktet. Husk at objekter som legges til en Replace-action også må legges til geodatasettet som ActionSequencen (evt. Action-objektet) peker på. Unlock Benyttes for å låse opp objekter som er låst i databasen. Klassen inneholder kun en UnlockKey av typen Integer. Denne UnlockKeyen blir i utgangspunktet opprettet når data hentes ut for oppdatering og returneres til klienten som et metaobjekt i geodatasettet som inneholder resultatet av spørringen. Se eget kapittel i Utviklerhåndboka som omhandler låsing av objekter. Modify Håndtering av denne klassen er ikke implementert i OracleMapperen. Klassen bør derfor ikke benyttes. Side : 34