HISTORIKK I MATRIKKELEN Faggruppe matrikkel 9.des 2010 MATRIKKELDATA - TIL NYTTE FOR SAMFUNNET

Transkript

1 HISTORIKK I MATRIKKELEN Faggruppe matrikkel 9.des 2010 STEDSDATA - TIL NYTTE FOR SAMFUNNET

2 UTFORDRING: HVA SKAL VI GJØRE MED HISTORIKK I MATRIKKELEN? Fornøyd med eksisterende historikk? Erkjenner at vi må gjøre noe! Men hva skal gjøres? Og hvordan? Utredning gjennomført, med forslag til løsning.

3 HVA HAR VI AV HISTORIKK I MATRIKKELEN? Matrikkelen, slik den ble utviklet til iverksetting i november 2007 og med senere endringer, inneholder allerede løsninger for historikk. Historikk håndteres i matrikkelen ved hjelp av 3 ulike metoder: Ved bruk av Forretninger Ved modellering direkte på objektet i datamodellen Ved etablering i endringslogg (anvendes via api / rapporter)

4 FORRETNINGER Forretninger er knyttet til matrikkelenheter og inneholder spesifikke hendelser som medfører endringer for vedkommende matrikkelenheter, og uttrykker dermed en historikk. Forretninger benyttes kun for matrikkelenheter, og ikke for adresse, bygning eller andre enheter i matrikkelen. Forretning inneholder Forretningsdato Forretningstype Referanser (til arkiver / dokumenter) Matrikkelføringsdato Signatur (hvem som har ført opplysningene) Involverte matrikkelenheter med arealoppgaver Berørte matrikkelenheter

5 HISTORIKK MODELLERT DIREKTE PÅ OBJEKTET Historikken er gjerne modellert gjennom egenskaper som Gyldig til dato, Dato fra, RegistrertDato og lignende. Eksempel: BygningstatusHistorikk, som inneholder hvilken status en bygning har og hvilke den har gjennomgått. Denne metoden er anvendt bare i mindre grad i matrikkelen.

6 ENDRINGSLOGG Endringsloggen inneholder endringer som har skjedd i matrikkelen med Endringstidspunkt Brukernavn Endringsnummer Videre fremgår Endringstype (nyoppretting, oppdatering, sletting, identendring) og endringskilde, dvs hvor endringene kommer fra. I en del brukstilfeller i matrikkelen, spesielt innenfor adresse, er det lagt inn at systemet skal etablere historikk i endringsloggen.

7 MER OM ENDRINGSLOGG Alle eller deler av endringene i en periode kan hentes ut gjennom endringslogg-api. MEN: Endringsloggen har sine begrensninger når det gjelder historikk. Endringsloggen er primært ment som en synkroniseringsmekanisme for å holde andre systemer ajour med Matrikkelen. Loggen holder derfor generelt ikke rede på alle historiske tilstander av de endrede objekter.

8 KRAV TIL HISTORIKK I MATRIKKELEN Nærmere om føringer og krav i: Matrikkellov m/forskrifter Arkivlov m/forskrifter Geodatalov INSPIRE

9 KRAV I MATRIKKELLLOV M/FORSKRIFTER Ml forskrift 4 med merknader: Statens kartverk kan utarbeide nærmere regler om lagring av aktive og historiske matrikkelopplysninger. Matrikkelsystemet skal bl.a. innrettes slik at det tar vare på endringer i registrerte opplysninger.

10 KRAV I MATRIKKELLLOV M/FORSKRIFTER Ml forskrift 10 med merknader: (utdrag) Reglene i arkivloven gjelder for all retting, endring eller tilføying av opplysninger i matrikkelen. Arkivloven 9 bokstav d presiserer at arkivmateriale vanligvis ikke kan rettes på en slik måte at tidligere gale eller ufullstendige opplysninger blir slettet. I utgangspunktet må derfor all retting eller sletting i matrikkelen skje ved at nye opplysninger blir føyd til gamle opplysninger. Det gjelder også ved sletting av matrikkelenhet.

11 KRAV I ARKIVLOV M/FORSKRIFTER Det helt sentrale kravet i forhold til historikk er arkivlova 9 bokstav d som fastsetter at arkivmateriale ikke, uten på vise vilkår, kan rettast på ein slik måte at tidlegare urette eller ufullstendige opplysningar vert sletta, dersom desse har hatt noko å seia for saksførebuinga, vedtak eller anna som etter føremålet med denne lova bør kunna dokumenterast. Videre er det viktig å merke seg at bestemmelsene i forskriftens 2-14 tredje ledd og 3-16 åpner for at det kan etableres historiske databaser.

12 KRAV I GEODATALOV Geodatalova sier ikke noe spesielt om håndtering av historiske data. Men lova gjennomfører INSPIRE-direktivet fra EU.

13 INSPIRE Det foreligger retningslinjer for dataspesifikasjoner i pr for Adminstrative enheter (vedlegg 1-tema, dvs tema som omfatter referansedata) Adresser (vedlegg 1-tema) Matrikkelenheter (vedlegg 1-tema)

14 GENERELT FRA RETNINGSLINJENE Generelt gjelder at alle objekttyper har et sett av temporale egenskaper. Tidsdimensjon og historikk er modellert på objektene ved to sett av egenskaper: startlivslopversjon og sluttlivslopversjon gyldigfra og gyldigtil

15 OM VERSJONERING Start og slutt på livsløpversjon er angitt i tid og er relatert til livsløpet for det aktuelle objektet i datasettet. Et eksempel kan være at en vegadresse registreres i matrikkelen (startlivslopversjon) og at denne senere slettes (sluttlivslopversjon). Et objekt vil kunne ha mange versjoner alt etter hvilke endringer som er utført på objektet i datasettet. Det må settes opp versjoneringsregler som angir hvilke endringer på et objekt som resulterer i ny versjon.

16 OM GYLDIGHET Gyldighet er relatert til den virkelige verden og angir tidspunktet for når enheten faktisk er gyldig (gyldig Fra og gyldigtil). Et eksempel kan være vedtak om tildeling av vegadresse, gjeldende fra et spesifikt tidspunkt. Dato for gyldigfra kan også være i fremtiden.

17 UML KLASSEDIAGRAM CADASTRAL PARCELS (UTDRAG)

18 ANDRE KRAV Etter at matrikkelen ble satt i produksjon i 2007, er det fra brukere satt fram ønsker om at historikken utvides for deler av innholdet. Det er særlig kommuner og systemleverandører som har presentert slike ønsker. Dette momentet bør også vektlegges når endring i historikken skal vurderes.

19 FORSTÅELSE OG OPPFØLGING AV KRAVENE (DEL I) Følgende legges til grunn: INSPIRE-spesifikasjonene om livsløpsinformasjon for et objekt må anvendes for å beskrive historikken i matrikkelen. Denne livsløpsinformasjonen knyttes til versjoner av objektet. Versjonering gjøres kun på objektnivå, ikke på egenskapsnivå. Versjonene må identifiseres. Det må defineres egne versjoneringsregler som sier hvilke forandringer på et objekt som skal resultere i en ny versjon av objektet eller sette objektet som slettet eller utgått.

20 FORSTÅELSE OG OPPFØLGING AV KRAVENE (DEL II) INSPIRE-spesifikasjonene om gyldighet fra-til trenger ikke innføres, i hvert fall ikke i denne omgang. Her dreier det seg egentlig om et spørsmål om utvidelse av innholdet i matrikkelen, og det er et eget tema som bør vurderes i annen sammenheng. Hvilke objekter som skal historikk, dsv versjoneres, og hvilke egenskaper som ved endring skal medføre at et objekt versjoneres, defineres etter vurdering i forhold til bestemmelsene i matrikkellov og arkivlov.

21 For klassene er det benyttet slik fargekode: GJENNOMGÅENDE VURDERING AV DATAELEMENTER Domenemodellen for matrikkelen er gjennomgått med vurdering av alle dataelementer mht historikk Her fremgår: Klasse Klasse Klasse Klassen versjoneres Klassen versjoneres gjennom andre klasser Klassen versjoneres ikke

22 EKSEMPEL Klasse Egenskap / relasjon Status Krav Endring Adresse Endringslogg Arkivlov. INSPIRE. Representasjonspunkt ds Arkivlov INSPIRE Versjonering. Se versjoneringsregler. Får historikk gjennom versjonering av Adresse Adressetilleggsnavn Endringslogg. Får ut gml verdi. Arkivlov Kortnavn Endringslogg ds ds ds matrikkelenhetid ds ds ds kretsids ds ds ds kommunaltilleggsdel ds ds ds tilleggsnavnkildekode Endringslogg. Får ut gml verdi. ds ds

23 EKSEMPEL Klasse Egenskap / relasjon Status Krav Endring Teiggrensepunkt Endringslogg Forretning Arkivlov Teiggrensepunkt er subklasse av Grensepunkt og versjoneres gjennom den. nedsatti Endringslogg ds Får historikk gjennom versjonering av Grensepunkt grensepunkttype kvalitet kommunaltilleggsdel datafangstdato ds ds ds ds ds ds ds ds ds ds ds ds

24 KRAVSPESIFIKASJON FOR HISTORIKK I MATRIKKELEN

25 HOVEDFORMÅLENE Løsningen må tilfredsstille hovedformålene med historikk i matrikkelen. Disse formålene er: Å dokumentere endringer i datainnholdet i matrikkelen med hensyn til: Hva endringen går ut på Når endringen er utført Hvem har utført endringen Å kunne gjengi status for datainnholdet på et angitt historisk tidspunkt Å kunne vise endringer som har skjedd med datainnholdet i et gitt historisk tidsintervall Å tilfredsstille arkivlova Å tilfredsstille INSPIRE-krav Å tilfredsstille brukerbehov

26 FORHOLDET TIL EKSISTERENDE MATRIKKELSYSTEM Krav: Innføring av historikk må ta hensyn til at matrikkelen er i drift. Det er et overordnet krav at det skal gjøres minst mulig endringer i eksisterende løsning. Begrunnelsen for dette er å: Unngå å redusere stabiliteten i produksjonen Unngå kostbare omarbeidinger av et velfungerende system Unngå at brukere, systemleverandører og samarbeidsparter (f eks eksterne registre) blir påført ressurskrevende endringer Det skal ikke lages særregler for elementer som har historikk i eksisterende løsning. Det må gjøres noen endringer i datamodellen.

27 KRAV TIL YTELSE Ytelsen i matrikkelens produksjonsversjon må ikke merkbart reduseres. Det aksepteres slakkere krav til respons på spørringer mot historiske data enn til spørringer mot og oppdatering av produksjonsdata. Dette fordi: En rekke forespørsler vil kunne håndteres som rapporter som sendes publikum. Det forventes generelt mindre bruk av historiske data enn av øvrige data. Løsningen må kunne håndtere et tilsvarende antall brukere som for produksjonsversjonen.

28 ANDRE TEKNISKE KRAV Historiske data skal være sikret med kriseløsning tilsvarende som for produksjonsdata. Det skal være enkelt å etablere testserver, kursserver, o.l som i dag. Testversjonene skal inkludere historikk. Dette for å kunne teste hele løsningen. Også speila server for rapporter skal ha med historikk. Det må påregnes at matrikkelens datamodell vil bli utvidet og endret også i fremtiden. De enkelte datasett vil derfor kunne ha ulikt innhold og ulik struktur til ulik tid. Flytting av egenskap fra en tabell til en annen vil også kunne skje. Løsningen må kunne håndtere dette. Løsningen bør være plattformuavhengig når det gjelder valg av database.

29 OVERORDNA LØSNINGSMODELL Den overordna løsningsmodellen inneholder følgende elementer: Unik identifisering av objekter: Objekter i matrikkelen skal tildeles en unik identifikator. Versjonering Versjonering med livsløpsinformasjon for et objekt skal anvendes for å håndtere historikken. Produksjonsversjonen er alltid lik siste versjon. Identifisering av versjonene. De ulike versjoner av et objekt skal identifiseres ved Unik INSPIRE-id + tidspunkt (start- og slutt på livsløpet for versjonen).

30 VERSJONERINGSREGLER Følgende versjoneringsregler skal implementeres: Endring i egenskap på et objekt, skal gi ny versjon av objektet. Når flere egenskaper endres og oppdateres samtidig, skal dette resultere i én og ikke flere nye versjoner.

31 HVA HISTORIKKEN SKAL OMFATTE Det skal være historikk for alle dataelementer slik det fremgår av oversikt. Det skal fremgå hvilken bruker som har utført endringen. Informasjonen legges til ved oppretting av ny versjon. Personer som har skjerma adresse av typen fortrolig eller strengt fortrolig i folkeregisteret vises ikke i matrikkelen, ref føringsinstruksen kapittel 8.1. Slike data skal heller ikke vises i tilknytning til historikk. I tillegg må det sikres at det for slike skjerma adresser ikke er mulig å finne adressen ved å hente fram tidligere versjoner.

32 TILLEGG I DATAMODELLEN Datamodellen for matrikkelen skal utvides med følgende tillegg: Unik identifisering av objektene. Livsløpsinformasjon for alle versjonerte objekter. Brukernavn (bruker som har forårsaket ny versjon).

33 HVORDAN SKAL HISTORISK DATA VÆRE TILGJENGELIGE? Historikk formidles gjennom uthentingsapi. Her skal alle versjoner leveres, også gjeldende versjon. Historikk skal ikke være tilgjengelig gjennom oppdateringsapi. Statens kartverk lager en egen leseklient for historiske data. Denne skal være tilgjengelig for kommunene og aktuelle samarbeidsparter. Det stilles ikke krav til tjenester for wms/wfs for historiske data. Det kan eventuelt utvikles senere etter behov. Det skal ikke lages funksjonalitet for at historikk inngår i lokale kopier av matrikkelen

34 KARTVERKETS LESEKLIENT FOR HISTORISKE DATA Visning Klienten utvikles etter samme mal som for visning av matrikkelinnholdet i Kartverkets oppdateringsklient. Klienten åpnes alltid med produksjonsversjonen. Bruker velger historisk dato for visning. Tidligste dato er lik dato for produksjonssetting av historikk i matrikkelen. All historikk skal være tilgjengelig i klienten i en komplett visning. Alle objekter og egenskaper, inkludert geometri, skal vises. Historisk dato skal også kunne gis inn for visning av enkeltobjekter.

35 KARTVERKETS LESEKLIENT FOR HISTORISKE DATA Mer om visning: Det skal være egne visninger for historikk for alle versjonerte objekter (med unntak av Kontaktperson, Person, Fylke, Kommune og klasser under Kommunetillegg), der alle versjoner av objektet listes opp og kan velges for visning. I tillegg skal også versjoner av assosierte objekter kunne vises med skru av- og på-funksjon i historikken for hovedobjektet. Klienten skal kunne sammenligne en gitt versjon av et objekt med annen versjon av objektet, og angi hva (hvilken egenskap(er)) som er endret. For geometrien vil det kunne være aktuelt å vise flere versjoner med forskjellig farge i samme vindu, eventuelt med utheving av endringer.

36 KARTVERKETS LESEKLIENT FOR HISTORISKE DATA Eksisterende rapporter: En del av de eksisterende standardrapportene fra matrikkelen omfatter allerede historikk. Slike rapporter trenger ikke endres, i hvert fall ikke med det første. En del andre eksisterende standardrapporter må utvides med et nytt utvalgskriterium (historisk dato) for å kunne rapportere status på et gitt historisk tidspunkt. Når dette utvalgskriteriet settes, må rapporten tydelig merkes som historisk rapport.

37 KARTVERKETS LESEKLIENT FOR HISTORISKE DATA Nye rapporter: Enkel historikk for objekt, med mulighet for å angi tidsintervall. Rapport som viser alle versjoner av et objekt (med unntak av Kontaktperson, Person, Fylke, Kommune og klasser under Kommunetillegg). Historikk for objekt, med mulighet for å angi tidsintervall. Rapport som viser alle versjoner av et objekt (med unntak av Kontaktperson, Person, Fylke, Kommune og klasser under Kommunetillegg) og angir hva som er endret mellom versjonene. For begge disse rapportene gjelder at i tillegg skal også versjoner av assosierte objekter kunne velges vist i historikken for hovedobjektet.

38 BRUKSTILFELLER I OPPDATERINGSKLIENT Det er ikke nødvendig med endring i eksisterende brukstilfeller i matrikkelen. Tilleggene i datamodellen skal håndteres på tjeneren. Det er ikke registrert behov for nye brukstilfeller som følge av innføring av historikk. Innføring av historikk etter denne kravspesifikasjonen vil ikke ha noen innvirkning på eksisterende eksterne oppdateringsklienter eller leseklienter.

39 SVAR PÅ UTFORDRINGEN Utredningen gir svar på utfordringen gjennom det foreslåtte opplegget for håndtering av historikk i matrikkelen. Beslutning ikke tatt. Utvikling og iverksetting gjenstår.