N O R K A R T A S. Utviklerhåndbok

Transkript

1 N O R K A R T A S Utviklerhåndbok

2 INNHOLD: 1 FORORD ANNEN RELEVANT DOKUMENTASJON OVERORDNET BESKRIVELSE AV QUADRI MAP SERVER PRINSIPPER FOR UTHENTING AV DATA PRINSIPPER FOR OPPDATERING LÅSING KVALITETSKONTROLL OG HÅNDTERING AV FEILSITUASJONER MINNEBRUK SLETTING AV OBJEKTER SPØRRINGER Spesielle spørringer (extents) Spørring etter låste objekter Spørring etter objekt med gitt LOKALID/UUID Spørring etter objekter med gitte egenskapsverdier Spørring etter historiske data Transformasjon Vertikaldatum Navn på objektkatalog og versjonsinformasjon om arkivene Tegnsett SPESIELLE FORHOLD VED TILBAKELAGRING Lagring av SIRKEL Lagring av SIRKELP Lagring av TEKST og SYMBOL Lagring av FLATE Sletting av objekter Oppdateringsdato Metaobjekt låsenøkkel Metaobjekt arkivlogg Side : 1

3 10.9 Validering Hva valideres globalgeodatasetupdate og validering Håndtering av ID-er og UUID er PORSJONERING VED UTTREKK OG OPPDATERING Porsjonering ved uttrekk Porsjonering ved oppdatering ARKIVLOGG TILGANGS-API (QSACCESS) Innledning Aktuelle headerfiler og biblioteker Funksjonsbeskrivelser Initialisering tilgang Release getversion clientlogin directlogin readportalsfromnameservers, getnumportals, getportal logoff tasksetquery taskquery removearchivefromtask setarchivereadonly globalgeodatasetquery getclockinformation globalgeodatasetupdate Validate writetask readtask ClientProgressInfo setrequestprogressstate setrequestresultavailable Kodeeksempler Initiering, pålogging og avlogging Hente oppgave fra portalen Hente ut geodataset via en oppgave Hente antall porsjoner fra et arkiv i et uttrekk Traversere et geodataset Hente ut geometri fra en feature Legge inn en polyline i et geodataset Hente egenskapstypene til en objekttype Finne en unlockkey (låsenøkkel) Spørring etter objekter med gitte egenskapsverdier Spørring etter historiske data Lagring av nytt objekt via QdiCreate Sletting av objekt via QdiErase Endring av objekt via QdiReplace Oppdatere data via en oppgave Lagring av opplysninger i arkivlogg Traversering av konfliktsett Sjekke om objekter er låst av andre Låse opp objekter via QdiUnlock

4 14 KLIENT-INSTALLASJON AV NGIS-API ET REVISJONSLOGG... 50

5 Quadri Map Server Utviklerhåndbok 1 Forord Denne utviklerhåndboken er et av i alt tre dokumenter som utgjør dokumentasjon for Quadri Map Server systemet. Systemet er utviklet av Norkart Geoservice AS, i samarbeid med Statens Kartverk og Statens Vegvesen. Quadri Map Server leveres ikke med klientbrukergrensesnitt. Systemet tilbyr derimot et programmeringsgrensesnitt som klienter kan benytte for å få tilgang til data lagret i systemet og utføre tjenester på disse. Quadri NGIS API består i hovedsak av disse elementene: En geodatamodell (general feature model) som utvider geometrimodellen i Oracle. Denne benyttes for lagring av geometriske objekter og deres egenskaper i hukommelsen. En action-modell som er en dataoperasjonsmodell. Denne benyttes for å lagre og endre objekter fysisk. En query-modell som benyttes til å hente lagrede objekter til geodatamodellen. Et tilgangs-api over query- og action-modellene. Et distribuert kommunikasjonsrammeverk som innkapsler det hele. (I denne versjon brukes binær sockets kommunikasjon pga hastighet). Disse elementene blir beskrevet i egne kapitler og dokumenter. 2 Annen relevant dokumentasjon I tillegg til utviklerhåndboken er det utarbeidet en overordnet beskrivelse av systemet og datamodelldokumentasjon som dokumenterer de modellene som systemet bygger på (geodata-modell, actionmodell og query-modell). UML-diagrammene som illustrerer de ulike modellene er også tilgjengelig. Side : 4

6 3 Overordnet beskrivelse av Quadri Map Server Quadri Map Server er et grunnsystem for lagring og forvaltning av Stedfestede objekter. Med Quadri Map Server kan man knytte sammen geografiske datakilder og distribuere disse via et felles grensesnitt. Omvendt kan man fra flere applikasjoner lagre data til flere datalager via felles grensesnitt. Quadri Map Server er et klient-tjener system. Det finnes et sett med tjenere for å distribuere data og det finnes et tilhørende sett med administratorer for å administrere disse tjenerne. Tjenerne kan kjøres på en separat enbruker PC og/eller de kan kjøres på internett/intranett. Alle tjenerne kan knyttes sammen i et nett slik at klientene lett kan hente data fra flere kilder. Det betyr at systemet kan skaleres fra å være et enbrukersystem til å dekke et lands behov for å binde sammen geografiske data i en infrastruktur. QMS Klienter kan hente data og/eller utføre tjenester på data direkte på samme maskin, eller klienten kan kontakte en eller flere tjenere for å hente data og/eller utføre tjenester. For brukeren av Quadri Map Server er altså alle datasettene like lett tilgjengelig uansett hvor de ligger fysisk lagret. De forskjellige systemkomponentene kan også plasseres fritt geografisk. Den eneste forutsetningen er at det er IP-kommunikasjon mellom dem. For eksempel kan en bruker samtidig jobbe mot et arkiv plassert hos Kartverket og et annet arkiv plassert hos Statens Vegvesen. QMS er et meget fleksibelt system som kan tilfredsstille de fleste ønsker i forvaltningen av primærdata. Klient N G I S - A P I NGIS navnetjeneste QMS portal QMS objekt katalog QMS arkiv QMS arkiv QMS arkiv Figur. Arkitekturoversikt For en mer utfyllende beskrivelse av de enkelte komponentene i systemet vises det til dokumentet Quadri Map Server Overordnet beskrivelse.doc. Side : 5

7 4 Prinsipper for uthenting av data Portalen er klientenes inngangsport til Quadri Map Server. Her er lovlige brukere definert, og portalen inneholder et sett med oppgaver som brukerene gis tilgang til. En oppgave har en kobling til ett eller flere arkiver som data skal kunne hentes fra samt informasjon om data skal kunne hentes ut for lesing eller om data skal oppdateres og kunne tilbakelagres i arkivene. Hver oppgave kan i tillegg ha sitt eget oversiktskart som klienten kan hente hvis ønskelig. Når en bruker har valgt en oppgave kan han eventuelt innskrenke området denne dekker, objekttypene og arkivene som inngår. Klienten henter ut data via oppgaven som er valgt og får i retur et geodatasett pr. arkiv som er involvert i oppgaven. Det er så opp til klienten å prosessere dataene videre. I figuren under vises arbeidsflyten i prosessen beskrevet over: : Gen Bruker Klient Portal Arkiv Velg Portal Gi passord Hent oppgaver Vise oppgaveliste Velge oppgave Vise detaljer og oversiktskart Pålogging Status Hent oppgaver Retur oppgaveliste Hent detaljer om oppgave Returner detaljer Zoom Velg færre objekttyper Lage spørring Huske spørring i klient Sette igang søk Spør om data via oppgaven Returner et datasett pr. arkiv Vise data for brukeren Logge av systemet Logge av 5 Prinsipper for oppdatering Oppdatering av data via Quadri Map Server baserer seg på lange transaksjoner. Det vil si at objekter som skal oppdateres hentes ut fra arkivtjenerne via en valgt oppgave. Tilgang til oppdatering i et arkiv forutsetter at portalen er tildelt skriverettighet til arkivet og at oppgaven som benyttes ved uthenting også er satt opp med skrivetilgang mot samme arkiv. Når data hentes ut for oppdatering låses de objektene som hentes ut av klienten i arkivet. En annen bruker som prøver å hente ut de samme objektene vil ikke ha mulighet til å oppdatere disse før Side : 6

8 første bruker har sjekket objektene inn igjen eller objektene er låst opp på annen måte. Objekter som er låst kan imidlertid fritt hentes ut for lesing. Se for øvrig eget kapittel om låsing. Når klienten har hentet ut data via en oppgave vil oppdateringene utføres lokalt hos klienten. Når oppdateringene er avsluttet må klienten identifisere oppdaterte, slettede og nye objekter og sende disse tilbake til arkivene de opprinnelig ble hentet fra. 5.1 Håndtering av ID-er og UUID er Alle objekter (QdiFeature, QdiComplexSurface, QdiBoundary osv.) i et arkiv får ved lagring tildelt en en unik ID som kalles PersistentId og en UUID. UUID en er en unik referanse til objektet som vil være konstant hele objektets levetid. Et objekt som lagres i flere arkiver (f.eks i et tilbyder-arkiv og et abonnent-arkiv) vil ha samme UUID, men ulike ID er i de to arkivene. Før innsjekk av nye objekter kan klienten generere nye UUIDer for objektene som skal lagres. Dersom klienten ikke genererer UUID for objektene, vil dette gjøres automatisk av QMS ved lagring. For at QMS skal kunne gjenkjenne objekter som er oppdatert og slettet i et uttrekk og utføre tilsvarende endringer i arkivene er det helt nødvendig at objektene beholder enten PersistentId eller UUID på klientsiden. Dersom klienten mellomlagrer data på eget format må derfor lagring av disse Id ene også ivaretas. I tidligere versjoner av QMS var det kun PersistentID som ble benyttet for å identifisere objekter, men i QMS 11 ble UUID innført som identifikator. Vi anbefaler nå å identifisere oppdaterte objekter i klienter med UUID. Objektene som skal oppdateres eller slettes kan da ha vilkårlig positiv PersistentId, mens nye objekter kan ha en vilkårlig negativ PersistentId Egenskapen LOKALID Objekter med egenskapen LOKALID behandles spesielt i forhold til UUID. Ved lagring av nye objekter vil QMS alltid generere UUID basert på verdien i egenskapen LOKALID hvis denne finnes. 6 Låsing Når en bruker henter ut kartdata via en oppgave og det er gitt skrivetilgang til ett eller flere arkiver i oppgaven vil alle objekter som hentes ut av brukeren bli låst i arkivene som har skrivetilgang. En annen bruker som prøver å hente ut de samme objektene vil ikke ha mulighet til å oppdatere disse før første bruker har sjekket objektene inn igjen eller objektene er låst opp på annen måte. Objekter som er låst kan imidlertid fritt hentes ut for lesing. Objekter som er låst vil kun bli låst opp i følgende tilfeller: Klienten kaller globalgeodatasetupdate. Dersom oppdateringen går bra vil samtlige objekter som ble låst da uttrekket fant sted bli låst opp igjen. Klienten sender inn en UnlockAction uten å gjøre oppdateringer. Administrator fjerner låsene ved hjelp av ArkivAdministratoren. Når klienten henter ut et geodatasett via globalgeodatasetquery vil alle objekter ha en peker til et objekt som ligger i geodatasettets metaobjects-liste. Dette objektet inneholder en IntegerAttributt med navn UnLockKey. Verdien på denne egenskapen gir viktig informasjon: Verdien er positiv o Objektet ble låst i dette uttrekket. Klienten må ta vare på verdien for bruk ved tilbakelagring. Verdien er negativ o Objektet er allerede låst av andre. I tillegg til selve låsenøkkelen ligger det en StringAttributt med navn Username i metaobjektet. Verdien inneholder navnet på brukeren som har låst objektet. Verdien er -1 o Objektet er et randsone objekt som ikke kan oppdateres i dette uttrekket. Side : 7

9 7 Kvalitetskontroll og håndtering av feilsituasjoner Det kan oppstå ulike feilsituasjoner både ved uthenting og oppdatering av data. I Quadri Map Server er det gjennomført bruk av konfliktsett i alle moduler. Det vil si at enhver feilsituasjon som lar seg fange opp skal bli beskrevet i et slikt konfliktsett som returneres til klienten. Se forøvrig eget kapittel om håndtering av konfliktsett. Alle data som sendes fra klienten til Quadri Map Server via globalgeodatasetupdate vil automatisk bli kvalitetskontrollert av modulen QsValidation. Modulen sjekker at data ligger innenfor geografisk område for oppgaven samt at objektene er av lovlig type og har egenskaper og egenskapsverdier i henhold til definisjonen i objektkatalogen. Ved eventuelle feil vil oppdateringen avbrytes og klienten gis beskjed via konfliktsett. Feil som oppstår under lagring og oppdatering av objekter i arkivet vil ha ulik alvorlighetsgrad. Dersom feilen er alvorlig vil systemet umiddelbart avbryte oppdateringsprosessen. Det vil utføres en Rollback av samtlige transaksjoner som er utført i oppdateringsprosessen forut for feilsituasjonen. Rollback vil da utføres mot samtlige arkiver som inngår i oppdateringstransaksjonen/oppgaven. Dersom lagring og oppdatering derimot utføres uten alvorlige feil vil det utføres Commit av endringene i alle arkiver som er involvert. Dette sikrer at data i arkivene til enhver tid vil være konsistente. 8 Minnebruk sletting av objekter. Klienter som henter ut og oppdaterer data via Quadri Map Server vil i tillegg til tilgangsapi et også gjøre utstrakt bruk av bl.a. geodata-, query- og action-modellene. Det er viktig at klienten frigjør minne som allokeres ved bruk av disse modellene. Klienten har selv ansvar for all opprydding/sletting. Både objekter som mottas via tilgangs-api et og objekter som sendes inn som parametre til metoder i tilgangs-api et må slettes av klienten når de ikke lenger er i bruk. Det anbefales at UML-diagrammene for modellene studeres for å sikre at klienten sletter det som er nødvendig. 9 Spørringer Querymodellen benyttes av klienten for å definere og begrense hvilke objekter og evt tilleggsinformasjon som skal returneres når det hentes ut data fra et eller flere QMS-arkiver. 9.1 Spesielle spørringer (extents) En spørring kan inneholde en geografisk avgrensning som objektene skal ligge innenfor og eventuelt en beskrivelse av egenskaper og egenskapsverdier som objektene skal tilfredsstille. I tillegg er det definert et sett med extents som kan benyttes for å utføre helt spesielle spørringer. Mange av disse extentene kan benyttes i kombinasjon med geografisk avgrensning og angivelse av egenskapsverdier. Oversikt over tilgjengelige extents: Extent Beskrivelse Retur AllData_t Hente ut alle objekter i en oppgave. Dersom ikke oppgaven har geografisk avgrensning vil alle objektene i arkiv(ene) hentes ut. GetOracleAreaQuery Hente ut arkivets utstrekning. Geodatasettet som returneres vil ha et metaobjekt som inneholder en Side : 8

10 Arkivets utstrekning vil legges på som tilleggsinformasjon på geodatasettet som inneholder objektene som er hentet ut. GeometrySurface med et QdiRectangel som angir arkivets utstrekning. Metafeaturen har også en StringAttribute med navnet OracleArea og verdien In the rectangle". LockedFeatureInArea Sjekke om det er låste objekter i et arkiv eller innenfor et område i arkivet Dersom låste objekter returneres et geodataset med første låste objekt. Dersom ingen låste objekter er geodatasettet tomt. Log_t Hente arkivlog Se eget kapittel IsEmpty_t Sjekke om et arkiv er tomt Resultatet legges på et geodatasett som en metafeature. Metafeaturen har en BoolAttribute som heter IsArchiveEmpty og er positiv dersom arkivet er tomt og negativ hvis det ikke er tomt. TypesOnly_t Historic_t Parameters_t Hente ut features med featuretyper men uten geometri og egenskaper. Hente ut historiske data fra et arkiv. Må også legge dato og tidspunkt på spørringen (se egen beskrivelse) Hente diverse opplysning om arkiv, b.l.a. porsjonsstørrelse, versjonsinformasjon for arkivets objektkatalog, historikk av/på Geodatasettet som returneres inneholder objektene som var lagret i arkivet på angitt tidspunkt. Resultatet legges på et geodatasett som en metafeature. Metafeaturen har følgende attributter (navn/type): portionsize /QdiIntegerAttribute major /QdiIntegerAttribute minor /QdiIntegerAttribute history_enabled /QdiBoolAttribute GetLockedFeatures_t Henter ut informasjon om låste objekter Se beskrivelse i eget kapittel 9.2 Spørring etter låste objekter Det er mulig å hente ut oversikt over objekter som er låst innen en oppgave ved å benytte extent GetLockedFeatures_t. Informasjon om aktive uttrekk i oppgavens arkiv(er) returneres i et geodatasett per arkiv i oppgaven. Geodatasettet inneholder et metaobjekt for hvert uttrekk med følgende attributter (navn/type): o «UserName»/StringAttribute o Navnet på brukeren som har låst objektene o "UnLockKey"/ IntegerAttribute o Låsenøkkel som kan benyttes for å låse opp uttrekket. Returneres kun for uttrekk som er låst av pålogget bruker. o «Date»/DateAttribute o Dato for uttrekket o «Time»/TimeAttribute o Tidspunkt for uttrekket o «NumLockedFeatures»/Integerattribute o Antall låste objekter i uttrekket I tillegg returneres de låste featurene i geodatasettet uten geometri og egenskaper. Disse har peker til metaobjekt som kobler dem til riktig uttrekk og gir mulighet for videre uthenting av full informasjon om låste objekter ved ny spørring etter PersistentID eller UUID. Side : 9

11 9.3 Spørring etter objekt med gitt LOKALID/UUID Egenskapen LOKALID benyttes for å identifisere et gitt objekt via en unik UUID. For å spørre etter et objekt med en gitt LOKALID benyttes klassen QdiQueryUUID i Querymodellen. En eller flere UUID er kan angis via følgende metoder setstringvalues UUID er angis i kommaseparert streng setvalues UUID er angis i vektor med strenger Spørringen returnerer alle objekter med UUIDer fra spørringen, i tillegg til eventuelle objekter med delt geometri (jf. kapittel 9.6). Spørringen kan brukes når det er objekter med en bestemt UUID som er interessante å gjøre lese- eller oppdateringsuttrekk på, som et alternativ til uttrekk innenfor et geografisk område. 9.4 Spørring etter objekter med gitte egenskapsverdier Querymodellen er generell og kan benyttes for å definere spørringer etter gitte objekter for eksempel med bestemte egenskapsverdier eller kombinasjoner av verdier. En spørring kan begrenses til å gjelde en gitt objekttype eller settes opp til å spørre på tvers av alle objekttyper. Figuren under viser instansene som må opprettes i Query-modellen ved spørring etter Bygning med BYGGNR= Se også tilhørende kodeeksempel i kapittel for spørring etter objekter med gitte BYGGNR. QdiCompari son QdiQueryAttribut QdiQueryV QdiFeatureT ype QdiIntegerAt tribute QdiIntegerAttribute Type Side : 10

12 Figuren under viser hvordan man kan definere en spørring etter mange ulike BYGGNR. Dette er et alternativ til kodeeksempelet og vil være mer effektiv ved store spørringer. QdiComparis on QdiQueryAttributeTyp e QdiFeatureTy pe QdiQueryVal ue QdiListAttribute QdiListAttributeTy pe QdiIntegerAttributeTy pe QdiIntegerAttrib ute QdiIntegerAttrib ute 5678 Side : 11

13 Figuren under viser instansene som må opprettes i Query-modellen ved spørring etter GateAdresse med gitt GATENR= og HUSNR=222 tilhørende StructAttribute AID. QdiComparis on QdiQueryAttributeTyp e QdiFeatureTy pe QdiQueryVal ue QdiStructAttrib QdiStructAttributeT ype QdiIntegerAttributeTy pe QdiIntegerAttrib ute QdiIntegerAttrib ute 222 QdiIntegerAttributeT ype Side : 12

14 Figuren under viser hvordan man kan benytte Query-modellen for spørring etter alle objekter med OPPDATERINGSDATO nyere enn kl 10:00 QdiCompari son QdiQueryAttribut etype QdiQueryV QdiDateTime Attribute QdiDateTimeAttrib utetype 9.5 Spørring etter historiske data Dersom det er aktivisert lagring av historikk på et QMS-arkiv, vil det være mulig å hente ut data fra arkivet slik de var på en gitt dato og klokkeslett. Det er ikke mulig å kombinere uthenting av historiske data med oppdateringsuttrekk. For å hente ut historiske data må følgende angis på QdiQuery: Extent: Historic_t Tidspunkt angis i en QdiDateTime-attributt med navn HISTORIC_DATE som legges på den QdiSpatial som inneholder området som skal hentes ut. Dersom alt innen arkivet skal hentes ut og det ikke er lagt på en QdiSpatial, må det opprettes en tom, «dummy» spatial av type QdiPath som QDiDateTimeattributten legges på og som igjen legges til query et. Se eget kodeeksempel i kap Det er fra og med QMS 9.2 mulig å hente ut informasjon om arkivene i en oppgave har historikk skrudd på eller ikke. Det gjøres ved å sende inn et Query med extent Parameters_t. Resultatet vil ligge på returnert geodatasett som en metafeature med en QdiBoolAttributt med navn history_enabled. Verdien true/false gjenspeiler om historikk er slått på eller av. 9.6 Resultat av spørring etter objekter med delt geometri Spørring etter en flate vil også hente ut de tilhørende linjeobjektene som flaten avgrenses av. Dette gjelder både spørring etter enkeltobjekter og uttrekk innenfor et geografisk område. Spørring etter en linje vil også hente ut eventuelle flater som avgrenses av denne linjen. 9.7 Transformasjon Side : 13

15 Det er mulig å transformere data ved uttrekk ved å spesifisere hvilket koordinatsystem man ønsker i spørringen. Dersom koordinatsystemet er et annet enn arkivets koordinatsystem vil da dataene transformeres på QMStjeneren. Det er landsfylkesformelen i Statens Kartverks standard transformasjonsbibliotek (SKTRANS) som benyttes. Se kodeeksempel i kapittel Data som er transformert ved uttrekk vil inneholde informasjon om transformasjonen som er benyttet. Denne informasjonen er lagret i en metafeature på geodatasettet som inneholder de transformerte dataene. Metafeturen har følgende egenskaper: Attributtnavn Type Verdi TransformationDll StringAttribute Navn på transformasjonsdll som er benyttet TransformationVersion RealAttribute Versjonsnummer på transformasjons-dll PointFileVersion StringAttribute Versjon av fellespunktfil CoordinateSystemFrom IntegerAttribute Nummer på koordinatsystem for arkivet CoordinateSystemTo IntegerAttribute Nummer på koordinatsystem det er transformert til QMS er også tilrettelagt for å håndtere transformasjon ved oppdatering av data. Det spesifiseres ved definisjon av oppgavene i Portalen om det skal være lov å transformere data ved oppdatering og i tilfelle til hvilke koordinatsystemer. Obs! Det anbefales IKKE å bruke transformasjon ved oppdatering. Oppdatering bør gjøres i basens koordinatsystem. Hvis det er nødvendig med transformasjon av data bør dette gjøres før lagring til QMS. Årsaken til dette er at det i spesielle tilfeller kan bli inkonsistens i geometri på grunn av at sekvensen Uthenting med transformasjon Lagring lokalt med avrunding Tilbakelagring med transformasjon vil kunne gi endring av koordinat uten at naboobjekter som ikke har blitt oppdatert har fått tilsvarende endring. 9.8 Vertikaldatum Hvert QMS-arkiv inneholder informasjon om hvilket vertikaldatum som gjelder for data i arkivet. Når en klient henter data fra et arkiv, blir navn på vertikaldatum returnert i en metafeature på geodatasettet som inneholder dataene. Metafeaturen har følgende egenskaper: Attributtnavn Type Verdi verticaldatum StringAttribute Vertikaldatum som gjelder for arkivet data er hentet fra 9.9 Navn på objektkatalog og versjonsinformasjon om arkivene Hvert QMS-arkiv inneholder informasjon om hvilken standard og objektkatalog/produktspesifikasjon data i arkivet følger. Dette angis som navn på objektkatalog, evt navn på standard og versjonsnummer. Når en klient henter data fra et arkiv, ligger denne informasjonen knyttet til QdiComposedTypeRegistry som følger geodatasettet som returneres og kan hentes ut med følgende metoder på QdiTyperegistry: Metode Type Beskrivelse getname streng Navn på standard som følges, for eksempel SOSI getversion streng Navn på objektkatalog/produktspesifikasjon. Dersom data følger flere produktspesifikasjoner er navn på disse adskilt med semikolon, for eksempel: FKB-Bygning 4.01;FKB-BygnAnlegg 4.01 getmajor int Hovedversjonsnummer. For SOSI 4.0: 4 getminor int Underversjonsnummer. For SOSI 4.0: Tegnsett Tegnsett for alle tekststrenger i NGIS-APIet er ISO med norske tilpasninger, som beskrevet i SOSI v Side : 14

16 Side : 15

17 10 Spesielle forhold ved tilbakelagring 10.1 Lagring av SIRKEL SIRKEL lagres som QdiPolyline med 64 tilnærmet like lange linjebiter (65 punkt med likt start og slutt punkt), og geometritypenavn SIRKEL. Radius fjernes ved lagring i basen. Ved uthenting beregnes senterpunkt og radius fra polylinjen Lagring av SIRKELP SIRKELP lagres som QdiPolyline med 64 tilnærmet like lange linjebiter (65 punkt med likt start og slutt punkt), og geometritypenavn SIRKELP. De opprinnelige punktene blir ikke bevart. Ved uthenting gjørespolylinjen om til SIRKELP ved at punkt 1, (nko/3)+1 og ((nko*2)/3)+1 blir tatt vare på Lagring av TEKST og SYMBOL Hvis objektet har en koordinat, eller alle koordinater er like lagres det i QMS som QdiSinglePoint. Hvis objektet har flere ulike koordinater lagres det som QdiCurveSegment med QdiPolyline Lagring av FLATE FLATE lagres normalt med to geometrier. En for selve flaten, og en for representasjonspunktet. Begge geometriene skal peke til samme geometritype med navn FLATE. Representasjonspunktet lagres som QdiSinglePoint og flaten lagres som QdiComplexSurface. Det er alltid QdiComplexSurface med QdiBoundary som brukes, de enkle flategeometriene (eks.qdigeometrysurface) skal ikke brukes. Hovedprinsipp ved tilbakelagring av flater: - Geometrien til linjer referert fra endrede flater skal være med i datasettet. - Alle flater som refererer endrede linjer skal være med i datasettet Sletting av objekter Oppdatering gjøres ved at det sendes inn en QdiActionSequence. Når det skal slettes objekter legges det inn en QdiErsae action i sekvensen. QdiErase action har et QdiFeatureSet som viser hvilke objekt som skal slettes. Objektene som ligger i FeatureSettet er forenklede objekter. De brukes bare for å overføre ID og UnLockKey til tjeneren for sletting av feature. Den forenklede featuren legges også inn i geodatasettet for tilbakelagringen Oppdateringsdato Oppdateringsdato er en spesiell egenskap med spesiell håndtering. Den angir datasystemets siste endring på objektet. Alle objeker som er lagret i en tilbakelagring skal ha samme oppdateringsdato selv om tilbakelagringen skjer i flere porsjoner. Før versjon 8.2 var klienten ansvarlig for å legge på og oppdatere denne egenskapen hvis den var definert i objektkatalogen. F.o.m versjon 8.2 vil QMS automatisk sette egenskapen Oppdateringsdato ved lagring dersom egenskapen er definert i objektkatalogen for objekttypen. Tidspunktet settes da til starten av lagringen av første porsjon i hvert arkiv. NB - dersom klienten har lagt inn en verdi i Oppdateringsdato vil denne bli overskrevet. Tidspunktet som ble satt for Oppdateringsdato ved lagring vil returneres som informasjon til klienten via konfliktsettet som er koblet til QdiSingleTransaction som er opprettet av klienten. Informasjonen ligger i Description i et QdiConflict-objekt på formen OPPDATERINGSDATO YYYYMMDDHHMMSS Metaobjekt låsenøkkel Når data hentes ut for oppdatering vil alle objekter som er låst i forbindelse med uttrekket peke til et metaobjekt med låsenøkkel/unlockkey for uttrekket. Se beskrivelse i kap 6 Låsing. Side : 16

18 Når data skal tilbakelagres er det viktig at låsenøkkel fra uttrekket benyttes. Denne er nødvendig for oppdatering og opplåsing av låste objekter. Det opprettes et metaobjekt med UnLockKey med låsenøkkel fra uttrekket. Alle objekter som skal oppdateres må ha peker til dette metaobjektet Metaobjekt arkivlogg Det er mulig å sende med informasjon om tilbakelagringen som vil bli lagret i loggen til arkive(ne) som blir oppdatert. Denne informasjonen må lagres i et metaobjekt som legges på datasettet. Se egen beskrivelse i kap 12 Arkivlogg Validering Ved innsjekk av data i QMS kjøres datasettet som sjekkes inn gjennom en valideringsrutine. Dersom det avdekkes feil, vil datasettet avvises, og oversikt over feilene returneres til klienten. Disse må da rettes før laring kan utføres Hva valideres Følgende valideringer utføres ved lagring av data i QMS: Egenskaper Egenskapene må peke til lovlige egenskapstyper Ukjente egenskaper (uten peker til egenskapstype) tillates/avvises avhengig av innstilling for arkivet data skal lagres i Obligatoriske egenskaper må finnes på objektene Egenskapsverdier må være gyldig i forhold til eventuelle beskrankninger gitt i objektkatalogen Dato- og datotid-egenskaper må ha lovlige verdier Kodeliste-egenskaper må ha verdi som finnes i tilhørende kodeliste Egenskapen LOKALID kan være tom eller bestå av maks 36 av følgende tegn ^[a-fa-f0-9-]+$ Geometri Geomtritypen må være lovlig og i henhold til objektkatalogen Kurver o Må bestå av minst 2 punkter o Kan ikke inneholde dobbeltpunkter (benytter arkivets oppløsning som grenseverdi) o Vektorer i samme kurve kan ikke overlappe hverandre Flater o Det kan ikke være gap mellom linjene som avgrenser en flate (benytter arkivets oppløsning som grenseverdi) o Sentralpunkt i flate må ligger innenfor flatens avgrensning o Avgrensningen til en flate kan ikke krysse seg selv o Ytre avgrensning skal gå mot klokka, indre avgrensning skal gå med klokka o Hull/indre avgrensning Må ligge innenfor flatens ytre avgrensning Kan ikke overlappe andre hull i samme flate Kan kun tangere ytre avgrensning i ett punkt Buer må ha lovlig radius globalgeodatasetupdate og validering globalgeodatasetupdate har to funksjoner, validere data og lagre data tilbake til basen. Ved tilbakelagring av store datamengder som fordeles over flere porsjoner er det ønskelig å kjøre validering av hele datasettet før selve tilbakelagringen starter. globalgeodatasetupdate har to flagg som gjør dette mulig. Når bvalidateonly er true blir datasettet bare validert og ikke sendt videre til tjeneren. Hvis det er gjennomført en vellykket validering kan en sette flagget Side : 17

19 bskipvalidation til true når en kjører den endelige tilbakelagringen. Dette fører til at valideringen ikke blir utført på nytt. OBS! bskipvalidation må aldri settes til true uten at det er kjørt en vellykket validering på forhånd. Hvis dette gjøres vil en kunne ødelegge integriteten i basen. 11 Porsjonering ved uttrekk og oppdatering Ved uttrekk og oppdatering i QMS overføres data mellom klient og tjener via geodatamodellen. For å håndtere overføring av store datamengder uten bruk av for mye minne, er det lagt til rette for oppdeling av datasettene i porsjoner både ved uttrekk og oppdatering Porsjonering ved uttrekk Ved uttrekk styres størrelsen på porsjonene av en parameter for antall objekter per porsjon. Denne er definert på hvert arkiv og kan settes via Arkivadministratoren. Et arkiv som kun inneholder punktobjekter, for eksempel Adressepunkter, vil typisk kunne ha en langt større porsjonsstørrelse enn et arkiv med Høydekurver der hvert objekt opptar langt mer plass i minnet. Uthenting av antall porsjoner Dersom et datasett er delt opp i flere porsjoner vil det i første porsjon som kommer fra et arkiv ligge informasjon om hvor mange porsjoner datasettet er delt opp i. Antall porsjoner hentes ut fra en metafeature på geodatasettet. Metafeaturen har en QdiIntegerAttribute med navnet "portioncount" der totalt antall porsjoner er angitt. Se eget kodeeksempel. De påfølgende porsjonene har ingen informasjon om antall porsjoner, og det er opp til klienten å holde styr på hvor mange posjoner som er mottatt. Merk at dersom hele datasettet sendes i en porsjon vil det ikke ligge noen slik metafeature på datasettet. Porsjonering av datasett med flater. Dersom et datasett inneholder flater og datasettet er delt opp i flere porsjoner, vil alle linjeobjektene komme først i egne porsjoner. Deretter kommer flateobjektene i den/de siste porsjonene. Linjeobjektene vil inneholde full geometri. Flateobjektene vil peke til eksisterende linjeobjekter (QdiCurveSegment) men disse vil ikke ha peker til QdiShape (QdiPolyline/QdiArc) da geometrien er mottatt i tidligere porsjoner. Dette er gjort for å begrense datamengden og unngå å sende samme geometri flere ganger. Eksempel: Kurve i 1. porsjon med geometri. Flate i siste porsjon som refererer til kurve i første porsjon: Side : 18

20 11.2 Porsjonering ved oppdatering Ved oppdatering/innsjekk av større datamengder bør klienten dele opp datasettet i porsjoner. Størrelsen på porsjonene styres av klienten selv, men bør være satt slik at QMS-tjeneren ikke overbelastes ved mottak av data. En porsjonsstørrelse på ca objekter per porsjon vil i de fleste tilfeller være passende for data med relativt små objekt. For data med store objekt som for eksempel høydekurver bør porsjonsstørrelsen reduseres til 5000 eller Når oppdateringen deles i flere posrjoner er det noen forhold det må tas hensyn til. - Hver porsjon skal inneholde komplett informasjon for de objektene som overføres i denne porsjonen. - På grunn av dette vil det kunne være nødvendig å sende geometrier flere ganger. Dette vil kunne skje når det er delt geometri mellom linjer og flater, eller mellom flere flater. - Hvis samme geometri sendes i flere porsjoner skal den ha samme ID i alle porsjoner. o For objekter som er hentet ut for oppdatering er dette ID objektet hadde ved uthenting. o For nye objekter tildeler QMS midlertidig ID når objektet opprettes. Denne må det tas vare på, slik at den kan brukes i senere porsjoner i samme tilbakelagring. - En flate kan ikke sendes i en porsjon før geometrien som avgrenser flaten. Normalt sendes punkt- og linjeobjekter i de første porsjonene. I senere porsjoner sendes flater. 12 Arkivlogg Hver gang data sjekkes inn i et arkiv lagres følgende informasjon i arkivets logg: brukernavn, dato og klokkeslett, oppgavenavn, evt områdenavn, evt kommentar, omsluttende rektangel av geografisk område som er berørt og antall objekter som er opprettet, endret og slettet. Lagring av opplysninger i arkivlogg For at korrekt brukernavn skal lagres i arkivloggen må dette sendes inn fra klienten ved innsjekk. I tillegg kan klient/bruker legge inn et valgfritt områdenavn og en kommentar som vil lagres i arkivloggen. Informasjonen som skal lagres i loggen legges på en metafeature på geodatasettet som skal lagres. Se eget kodeeksempel. Uthenting av arkivlogg til klient En klient kan ved behov hente ut arkivloggen for et arkiv. Dette gjøres ved å opprette et Query med et eget extent (Log_t). Dersom man ønsker å hente ut loggen kun innenfor et bestemt geografisk område kan området defineres i et SpatialPropertyObject som kobles på Query et. Det returneres et tomt geodatasett med en metafeature for hver linje i loggen. Metafeaturene er sortert etter dato/klokkeslett. Hver metafeature har en StructAttribute som kan ha følgende innhold (avhengig av hva som er skrevet i loggen): Attributtnavn Type Verdi username StringAttribute Navn på bruker taskname StringAttribute Navn på oppgave logdate DateAttribute Dato for innsjekk logtime TimeAttribute Tidspunkt for innsjekk comment StringAttribute Kommenar gitt av bruker areaname StringAttribute Områdenavn gitt av bruker LLX RealAttribute Nord-koordinat for sørvestlig hjørne av omsluttende rektangel LLY RealAttribute Øst-koordinat for sørvestlig hjørne av omsluttende rektangel URX RealAttribute Nord-koordinat for nordøstlig hjørne av omsluttende rektangel URY RealAttribute Øst-koordinat for nordøstlig hjørne av omsluttende rektangel Created IntegerAttribute Antall nye objekter Replaced IntegerAttribute Antall endrede objekter Erased IntegerAttribute Antall slettede objekter Side : 19

21 13 Tilgangs-API (QsAccess) 13.1 Innledning Tilgangs-API et QsAccess benyttes av klienter for å få tilgang til Quadri Map Server. API et har funksjoner for å logge på en portal, hente ut oppgaver, hente ut data samt oppdatere og legge inn nye data via oppgavene. API et støtter programmeringsspråket C++ og kompilatorene Microsoft Visual C++ ver. 8.0 (VS2005) og ver 10.0 (VS2010) Aktuelle headerfiler og biblioteker For å utvikle klienter mot Quadri Map Server må headerfilen QsAccess.h inkluderes. Denne blir installert når utviklerversjonen av Quadri Map Server installeres. QsAccess.lib må inkluderes i prosjektet, denne har igjen referanser til QsAccess.DLL. QsAccess.lib og QsAccess.dll finnes både i release- og debug-versjon. Debug-versjonen har suffix D i filnavnet Funksjonsbeskrivelser I dette kapittelet beskrives funksjonene i tilgangs-api et Initialisering tilgang I QsAccess.h er det definert en abstrakt klasse med navn CQsAccess. Alle kall til API et gjøres via denne klassen. Klientprogrammet må derfor opprette en peker til en denne klassen. CQsAccess *paccess = NULL; For å sette denne pekeren til et objekt som har implementert den abstrakte klassen, må metoden getqsaccessinstance benyttes. Deklarasjon : extern "C" declspec(dllexport) CQsAccess * getqsaccessinstance(unsigned long itfid=2); Returverdi : Funksjonen returnerer adressen til et objekt som arver fra CQsAccess og har implementert alle metodene i klassen CQsAccess. Ved feil returneres verdien NULL. Dette objektet slettes fra maskinens hukommelse ved å kalle objektets Release-metode. Parametre : ItfID : Verdien i denne parameteren angir versjonsnummeret til klassen CQsAccess parameteren må i denne versjonen alltid ha verdi lik to (2). Settes automatisk til 2 dersom parameteren ikke angis. Kommentarer : Funksjonen returnerer en unik instans av klassen CQsAccess. Den kan kalles flere ganger hvis man ønsker flere instanser av klassen CQsAccess. Hver av disse instansene kan logge på hver sin separate tjener. På denne måten kan du lage en applikasjon som er logget på flere tjenere samtidig. Side : 20

22 Release Formål : Avslutte forbindelsen til API et. Deklarasjon : void CQsAccess::Release () Parametre : Ingen Kommentar: QsAccess-objektet skal ikke slettes via delete. Benytt objektets Release-metode i stedet getversion Formål : Hente ut internt versjonsnummer for tilgangsapi et. For at kommunikasjon med tjenerne skal fungere må dette nummeret stemme overens med tjenrernes interne versjonsnummer. Versjonsnummeret økes når det gjøres endringer som forutsetter nye versjoner både på klient- og tjernersiden. Deklarasjon : void CQsAccess::getVersion( int &clientversjon, std::string &strproductversion); Returverdi: Ingen Parametre : int &clientversjon API ets versjonsnummer som heltall. std::string &strproductversion API ets versjonsnummer som streng clientlogin Formål : Benyttes for å logge på en Quadri NGIS Portal. En bruker må være logget på en portal for å kunne hente ut oppgavene som er definert i portalen. Det vises en login-dialog hvor brukeren kan velge mellom portalene som er definert i tjenerlistene klienten har tilgang til. Disse listene på XML-format eksporteres fra TjenerAdministratoren. Brukeren må logge seg på portalen med gyldig brukernavn og passord. Det kan også via parametre gis mulighet for i dialogen å manipulere med tjenerlistene før pålogging. Side : 21

23 Deklarasjon : virtual QdiErrorResult* CQsAccess::clientLogin( const HWND hwndparent, const std::string strlanguage, unsigned int noptions, std::string &strserverid, std::string &strusername, std::string &strcommonserverfile std::string &strpersonalserverfile, std::string strresourcepath, std::string strresourcelanguage, std::string& strserverlogicalname, std::string& strpassword ); Returverdi: Metoden returnerer NULL dersom pålogging var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : const HWND hwndparent Peker til vinduet dialogen tilhører. Angis NULL settes pekeren til Windows-skrivebordet. const std::string strlanguage Språket meldinger fra portalen skal skrives i (for eksempel "eng", "nor"). Dersom angitt språk ikke støttes, skrives meldinger på engelsk. unsigned int noptions Variabel som benyttes for å angi hvilke muligheter brukeren skal gis til å manipulere med tjernerlistene. En eller en kombinasjon av kodene definert i enum EqsaOptions kan benyttes. Eksempel på kombinasjon: unsigned int noption = eqscommonserverlist eqsbuttonlocation; eqsnone_ : Ikke vis knappen Alternativer i dialogen. eqscommonserverlist_ : Vis innhold i felles tjenerliste eqspersonalserverlist_ : Vis innhold i privat tjenerliste eqsbuttonlocation_ : Brukeren kan velge en annen tjenerliste eqsbuttonmodify_ : Brukeren kan endre innholdet i en tjenerliste eqsbuttonall_ : Kombinerer eqsbuttonlocation_ og eqsbuttonmodify_ eqsmenuaddfromfile_ : Brukeren kan legge til tjenere fra valgt fil eqsmenuaddfromdialog_: Brukeren kan legge til tjenerinformasjon via en dialog eqsmenusaveas_ : Brukeren kan lagre tjenerlisten til et annet filnavn eqsmenuall_ : Kombinerer eqsmenuaddfromfile, eqsmenuaddfromdialog og eqsmenusaveas eqsall_ : Aktiviserer alle valgene std::string &strserverid, Inn: UUID til portal som skal vises som default (kan være tom). Ut: UUID til valgt portal etter vellykket login. std::string &strusername Inn: Navn på bruker. Ut: Navn på pålogget bruker. std::string &strcommonserverfile Inn: Navn på XML fil som inneholder felles tilgjengelige tjenere (for eksempel "d:\quadri\commonservers.xml"). Ut: Tilsvarende filnavn (kan være endret via Alternativer i dialogen.). std::string &strpersonalserverfile Inn: Navn på XML fil som inneholder private tjenere (for eksempel "d:\quadri\personalservers.xml"). Side : 22

24 Ut: Tilsvarende filnavn (kan være endret via Alternativer i dialogen.). std::string strresourcepath Inn: Sti til ressurs-dll en QsClientRC_*.DLL eller tom streng dersom Windows path skal gjennomsøkes for å finne DLL en. std::string strresourcelanguage Inn: Språket påloggingsdialogen skal vises i, nor eller eng. std::string &strserverlogicalname Logisk navn på portalen som er pålogget. std::string &strpassword Inn: Forslag til passord. Ut: Passordet som ble tastet inn ved pålogging. Kommentar: Det er kun nødvendig å logge seg på en portal for å hente ut oppgavene via tasksetquery. Det er ikke nødvendig å være pålogget for å benytte de øvrige metodene i API et directlogin Formål : Benyttes som et alternativ til clientlogin for å logge på en QMS Portal direkte uten å vise påloggingsdialogen. Kan for eksempel kalles dersom klienten ønsker å benytte en egen påloggingsdialog. En bruker må være logget på en portal for å kunne hente ut oppgavene som er definert i portalen. Brukeren må logge seg på portalen med gyldig brukernavn og passord. Deklarasjon : virtual QdiErrorResult *directlogin ( virtual QdiErrorResult *directlogin( virtual QdiErrorResult *directlogin( std::string strlanguage, std::string &strserverlist, std::string &strserverid, std::string &strusername, std::string &strpassword, std::string &strserverlogicalname ) const char *planguage, const char *pserverlist, const char *pserverid, const char *pusername, const char *ppassword, char *pserverlogicalname, int nmaxlength ) QdcNameObject *pnameobject, std::string strlanguage, std::string &strusername, std::string &strpassword) Returverdi: Metoden returnerer NULL dersom pålogging var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : Side : 23

25 strlanguage planguage Språket meldinger fra portalen skal skrives i ("eng" eller "nor"). Dersom angitt språk ikke støttes, skrives meldinger på engelsk. strserverlist pserverlist Navn på tjenerliste som inneholder valgt portal (for eksempel "c:\quadri\qsserverlist.xml"). Tjenerlistene eksporteres fra TjenerAdministratoren. strserverid pserverid UUID til portalen det skal logges på. strusername pusername Navn på bruker. strpassword ppassword Brukerens passord for pålogging. strserverlogicalname pserverlogicalname Returnerer logisk navn på portalen som er pålogget. nmaxlength Max antall karakterer som kan returneres i pserverlogicalname inkludert null-terminering. pnameobject Peker til objekt med informasjon om portalen det skal logges på. Objektet hentes ut via kall til readportalsfromnameservers og getportal. Kommentar: Det er kun nødvendig å logge seg på en portal for å hente ut oppgavene via tasksetquery og profilequery. Det er ikke nødvendig å være pålogget for å benytte de øvrige metodene i API et readportalsfromnameservers, getnumportals, getportal Formål : readportalsfromnameservers benyttes i forkant av pålogging på portal for å opprette intern liste over portaler som er registrert i en eller flere navnetjenester. Kalles flere ganger etter hverandre dersom portaler skal hentes fra flere navnetjenester. Antall portaler i lista hentes ut med kallet getnumportals. Portalene hentes ut via getportal. directlogin benyttes deretter til selve påloggingen readportalsfromnameservers Deklarasjon : virtual QdiErrorResult *readportalsfromnameservers ( std::string strserverlist, bool bclearlist) Returverdi: Metoden returnerer NULL hvis vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : Side : 24

26 std::string strserverlist Navn på tjenerliste som inneholder navnetjeneste (for eksempel "c:\quadri\qsserverlist.xml"). Tjenerlistene eksporteres fra TjenerAdministratoren. bool bclearlist Dersom portaler skal hentes fra flere tjenerlister (dvs flere kall til readportalsfromnameservers) benyttes bclearlist til å styre om portalene skal legges til tidligere liste eller om denne lista skal tømmes. Settes normalt til true ved første gangs kall og deretter til false getnumportals Deklarasjon : virtual QdiErrorResult * getnumportals ( int &nnumportals ) Returverdi: Metoden returnerer NULL hvis vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : int &nnumportals Returnerer antall portaler i liste opprettet med et eller flere kall til readportalsfromnameservers getportal Deklarasjon : virtual QdiErrorResult * getportal ( int nindex, QdcNameObject* &pnameobject) Returverdi: Metoden returnerer NULL hvis vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : int & nindex Null-basert indeks til portal som skal returnerers fra lista opprettet med readportalsfromnameservers. QdcNameObject* &pnameobject Retur-objekt med informasjon om portal. For pålogging sendes objektet inn som parameter til directlogin logoff Formål : Avslutte forbindelsen til en portal. Kalles etter clientlogin eller directlogin og etter at oppgavene er hentet ut med tastsetquery. Deklarasjon : QdiErrorResult * CQsAccess::logoff() Side : 25

27 Returverdi: Metoden returnerer NULL dersom avlogging var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : Ingen Kommentar: Det er kun nødvendig å logge seg på en portal for å hente ut oppgavene via tasksetquery. Det er ikke nødvendig å være pålogget for å benytte de øvrige metodene i API et tasksetquery Formål : Hente ut oppgavene som er definert i portalen brukeren er logget på. Kun oppgaver brukeren har rettigheter til blir returnert. Deklarasjon : QdiErrorResult * CQsAccess::taskSetQuery( QdpTaskSet *& taskset, QdiConflictSet *& pcs) Returverdi: Metoden returnerer NULL dersom uthenting av oppgavene var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : QdpTaskSet *& taskset Inneholder de oppgavene i portalen som pålogget bruker har tilgang til. QdiConflictSet *& pcs Konfliktsett som inneholder eventuelle meldinger fra tjener. NULL hvis ingen meldinger er returnert. Kommentarer: Man må være pålogget en portal for kunne kalle denne metoden. Metoden returnerer all informasjon om oppgavene unntatt informasjon om eventuelle oversiktskart som er koblet til oppgavene. For å hente ut komplett informasjon om valgt oppgave inkludert oversiktskart kalles taskquery. Når kall til tasksetquery er utført kan brukeren logges av portalen taskquery Formål : Hente komplett informasjon (inkludert overiktskart) om oppgave som er hentet ut via tasksetquery Deklarasjon : QdiErrorResult * CQsAccess::taskQuery ( const QdpSingleTask* singletask, QdpSingleTask*& osingletask, QdiConflictSet*& pcs ) Returverdi: Metoden returnerer NULL dersom uthenting av oppgaveinformasjon var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : Side : 26

28 const QdpSingleTask* singletask Oppgaven som det skal hentes komplett informasjon om. QdpSingleTask*& osingletask Returnerer den komplette informasjonen. QdiConflictSet *& pcs Konfliktsett som inneholder eventuelle meldinger fra tjener. NULL hvis ingen meldinger er returnert. Kommentarer: Denne funksjonen kan kalles etter tasksetquery dersom man ønsker full informasjon om, inkludert oversiktskart. Dersom klienten ikke benytter oversiktskart fra oppgaven/profilen, trenger denne funksjonen ikke benyttes removearchivefromtask Formål : Temporært fjerne arkiver som inngår i en gitt oppgave oppgave før uthenting av data. QdiErrorResult * removearchivefromtask ( std::string strarchivename, QdpSingleTask *psingletask) Returverdi: Metoden returnerer NULL dersom fjerning av arkiv fra oppgaven var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Parametre : std::string strarchivename Fullt navn på arkivet som skal fjernes fra oppgaven. QdpSingleTask *psingletask Inneholder oppgaven arkivet skal fjernes fra. Kommentarer: Arkivnavnet som sendes inn som parameter kan hentes ut via oppgavens TaskAreaOfInterest og dennes AccessModeConnection setarchivereadonly Formål : Temporært innskrenke rettighetene til et arkiv i en gitt oppgave fra skriv til les. Benyttes når en oppdateringsoppgave skal brukes til å hente ut alle eller enkelte av arkivene uten låsing. Deklarasjon : QdiErrorResult * setarchivereadonly ( std::string strarchivename, QdpSingleTask *psingletask) Returverdi: Metoden returnerer NULL dersom fjerning av arkiv fra oppgaven var vellykket. Ved feil returneres en beskrivende feilmelding i QdiErrorResult. Meldingen hentes ut via metoden geterrormsg() i QdiErrorResult. Side : 27