Warning
Høringsversjon!

Publisert: 2024-02-01

Nyeste versjon finnes på: https://sosi.geonorge.no/standarder/FKB_generell_del
Denne versjonen erstatter: FKB 5.0.1 2023-01-01

Faglig ansvarlig: Geovekst
Aktuell ansvarlig: Kartverket

Vedtatt som standard av Standardiseringskomiteen for Geomatikk

1. Orientering og introduksjon

1.1. Innledning

Dette dokumentet er en generell overbygning over de enkelte FKB-produktspesifikasjonene og angir generelle mekanismer i FKB og hvordan de forskjellige delene av spesifikasjonen skal sees i sammenheng.

1.2. Definisjon av Felles KartdataBase (FKB)

FKB er en samling datasett som utgjør en sentral del av grunnkartet

1.3. Formål med FKB

FKB er grunnleggende geografisk informasjon for å utøve lov- og forskriftsbelagte saker og ta gode beslutninger. FKB kan brukes til:

  • å kjenne seg igjen ute i terrenget

  • forvaltningsmessig saksbehandling i kommuner, statlige etater og ledningsetater

  • saksbehandling knyttet til plan- og bygningsloven med forskrifter (jf. [PBL-KART])

  • prosjekteringsformål

  • analyse og presentasjon i et integrert informasjonssystem (GIS-system)

  • produksjon av kart og avledede produkter med forskjellig krav til innhold, detaljering og stedfestingsnøyaktighet FKB inngår i det offentlige kartgrunnlaget ([DOK]).

1.4. Ansvar for FKB

FKB er spesifisert i FKB produktspesifikasjoner. Geovekst-samarbeidet har ansvar for utvikling av disse spesifikasjonene. Dette gjøres i nært samarbeid med kommunene utenfor Geovekst, andre brukere, produsenter og systemleverandører. Geovekst-forum har ansvar for å iverksette arbeid for å utarbeide nye eller revidere FKB-spesifikasjoner og vedtar FKB produktspesifikasjonene.

Det meste av etableringen av FKB-data skjer også gjennom Geovekst-samarbeidet og rettighetshavere vil da være Geovekst-partene. For enkelte områder vil FKB-data være etablert utenfor Geovekst og har andre eier- og rettighetsforhold.

Se mer om Geovekst-samarbeidet på Kartverkets hjemmesider.

1.5. Kriterier for FKB

Ved vurdering av hvilke datasett/objekter som skal inngå i FKB er følgende kriterier viktige:

  • FKB-data skal være vektordata

  • FKB-data skal ha et etablert forvaltningsopplegg (FDV)

  • FKB-data skal normalt ha en homogen nasjonal dekning

  • FKB-data skal normalt ikke være sikkerhetsgraderte data

  • FKB-data skal normalt være topografiske/fysiske data (grunnkart/basisdata)

  • Data som bare er interessante for en etat/part vil normalt ikke inngå i FKB

1.6. Geovekst-data - fullstendighet, kvalitet og rettslig gyldighet

FKB-data, ortofoto og laserdata (Geovekst-data) som selges gjennom kommunen eller Kartverkets forhandlere er etablert og finansiert gjennom Geovekst-samarbeidet eller kommunene alene for kommuner utenfor Geovekst-samarbeidet. Disse er også rettighetshavere til dataene.

Geovekst-dataene er de mest detaljerte og best oppdaterte geodataene som er tilgjengelig. Dataene skal gi en best mulig gjengivelse av terrenget og menneskeskapte objekter med varierende innhold, detaljering og nøyaktighet. Det skjer kontinuerlig endringer i terrenget (flom, ras, brann m.m.), objekter bygges og fjernes, så det kan ikke forventes at alle områder til enhver tid er 100% oppdaterte.

Datasettene kan derfor ha varierende fullstendighet og kvalitet. Brukere som har spesielle krav til dette, undersøke fullstendighet og kvalitet før bruk.

Geovekst-dataene er ikke rettslig gyldige.

2. Historikk og status

De første versjonene av FKB produktspesfikasjon oppsto samtidig med Geovekst-samarbeidet tidlig på 1990-tallet. Datainnholdet ble i tidlig fase utformet slik at det skulle tilsvare datainnholdet i Teknisk kartverk 1:1000 (TK) og Økonomisk Kartverk 1:5000 (ØK). Senere har det kommet større og mindre revisjoner med jevne mellomrom. Her listes ut noen av de store oppdateringene:

  • 1995: FKB 2.2

  • 2003: FKB 3.3

  • 2007: FKB 4.0

  • 2016: FKB 4.6

Fram til innføring av FKB 4.0 ble FKB regnet som en produktspesifikasjon. Ved innføring av FKB 4.0 ble de ulike datasettene i FKB skilt ut som egne produktspesifikasjoner og dokumentet FKB generell del (dette dokumentet) ble etablert for å beskrive de felles rammene for FKB-produktspesfikasjonene.

For komplett oversikt over endringer mellom tidligere versjoner henvises det til endringslogg i de enkelte versjonene.

2.1. Endringslogg

2.1.1. Endringer fra FKB 5.0.1 2023-01-01 til FKB 5.1 2024-02-01

  • Nytt kapittel 1.6 om fullstendighet, kvalitet og rettslig gyldighet for Geovekst-data

  • Oppdatert tabell 1 (kapittel 6.1) med referanser til oppdaterte FKB produktspesifikasjoner og fotogrammetriske registreringsinstrukser

  • Oppdatert beskrivelse av høydegrunnlag i kap 6.2.5

  • Oppdatert beskrivelse av modellering av assosiasjoner i FKB i kap 7.1.3

  • Lagt inn referanse til produktspesifikasjon AvvikKartdata 1.0 i kapittel 8.4

  • Lagt inn generelle retningslinjer for fotogrammetrisk datafangst av FKB som vedlegg D

2.1.2. Endringer fra FKB 5.0 2022-01-01 til FKB 5.0.1 2023-01-01

Oppdatert tabell 1 (kapittel 6.1) med referanser til oppdaterte FKB produktspesifikasjoner og fotogrammetriske registreringsinstrukser

2.1.3. Endringer fra FKB 4.6 2020-01-01 til FKB 5.0 2022-01-01

Punktene under beskriver de største endringene i FKB 5.0 sammenlignet med FKB 4.6 2020-01-01.

Håndtering av kodelister:

Alle kodelister i FKB 5.0 forvaltes i Geonorge kodelisteregister. Se mer om rammer for bruk av kodelister i FKB under Kodelister.

Assosiasjoner:

Det er åpnet for at vanlige assosiasjoner kan tas i bruk til å beskrive andre typer sammenhenger mellom objekter enn å beskrive flategeometri. F.eks. at et Bygning-objekt vet hvilke Veranda-objekter som "tilhører" bygget. Assosiasjonene modelleres i tråd med reglene i SOSI del 1 Regler for UML-modellering [SOSI-UML]. Se mer om rammer for bruk av assosiasjoner i FKB under Assosiasjoner.

Flategeometri:

Tidligere versjoner av FKB har basert seg på SOSI-formatets flategeometri som innebærer at alle flateobjekttyper må avgrenses av en eller flere avgrensningsobjekter og skal ha et representasjonspunkt. Dette er nå endret slik at flater som hovedregel modelleres med heleid geometri og uten representasjonspunkt. Der det er behov skal det likevel fortsatt modelleres representasjonspunkt og settes krav til sammenheng mellom flategeometrien og geometrien til egne avgrensningsobjekter. Dette modelleres som en assosiasjon etter gitte regler. Se nærmere beskrivelse under Flategeometri.

Id-håndtering; Identifikasjon av objektene i FKB og pekere til Id-er i eksterne systemer:

Regler for bruk av identifikasjon er presisert og pekere til eksterne systemer i form av URI-er [URI] er lagt inn på en lang rekke nye objekttyper. Les mer under Identifikasjon av objekter i FKB.

Endringer i fellesegenskaper:

Det er gjort noen justeringer i fellesegenskapene i FKB Generell del, dvs. hvilke egenskaper som er lovlig å benytte på objektene i FKB. Følgende endringer er gjort:

  • Datatypen posisjonskvalitet er endret. Den største endringen er at kodeliste målemetode er erstattet av den enklere datafangstmetode. I tillegg er nøyaktighet endret fra påkrevd til opsjonell og definisjoner etc. er gjennomgått og presisert.

  • Egenskapen registreringsversjon er endret fra å være definert som en datatype til å bli en kodeliste.

  • Egenskapene kopidata og prosesshistorie er ikke lenger definert som del av fellesegenskapene som skal brukes ved forvaltning av FKB.

  • Egenskapen sluttdato er lagt til som en del av fellesegenskapene. Denne er en egenskap som i likhet med oppdateringsdato styres av forvaltningssytemet og den er lagt til for å kunne støtte utveksling av data fra historiske spørringer. Egenskapen skal normalt ikke inngå i en leveranse av levende FKB-data (sluttdato vil da ikke ha noen verdi).

Oppdatert kvalitetsmodell:

Modell for å beskrive krav til kvalitet og dokumentere kvalitet på FKB-data er oppdatert. Ny modell baserer seg mer direkte på standarden Geodatakvalitet [G], noe som blant annet medfører at det i FKB 5.0 settes krav til både systematiske og tilfeldige avvik. Se mer under Kvalitet.

Endret dokumentasjon:

Dokumentasjon av FKB produktspesifikasjon er totalt omarbeidet slik at det nå er HTML som er standardformatet (fortsatt med PDF som et alternativ). Dette bør gjøre det lettere å hoppe mellom de ulike delene av FKB produktspesifikasjonene. Nytt format og nye verktøy gjør at ganske mye av dokumentasjonen er omarbeidet. Det er imidlertid forsøkt å gjenbruke innholdet mest mulig. Der det er vesentlige endringer i innholdet skal dette være beskrevet i endringsloggen for det enkelte FKB-datasett.

2.2. Revisjon

FKB produktspesifikasjonene oppdateres ved behov. Hver enkelt FKB produktspesifikasjon kan oppdateres uavhengig av de andre. De generelle retningslinjene for FKB (dette dokumentet) vil normalt oppdateres ved hver oppdatering av et underkapittel.

Hver enkelt FKB produktspesifikasjonen skal oppdateres maksimalt 1 gang pr. år og ny versjon utgis fortrinnsvis ved nyttår.

En versjon av et FKB-kapittel identifiseres ved et versjonsnummer. Dette nummeret er knyttet til datamodellen (objektkatalogen/applikasjonsskjema). I tillegg kan det utgis revisjoner av FKB-kapitler som ikke innebærer endring i objektkatalog (for eksempel presiseringer i registreringsinstruks for fotogrammetrisk kartlegging). Disse revisjonene merkes da med ny dato, men ikke nytt versjonsnummer.

3. Omfang

3.1. Dokumentet omfatter

Dette dokumentet beskriver generelle og prinsipielle forhold som er felles for alle FKB produktspesifikasjonene.

3.2. Bruksområde for dokumentet

Dette dokumentet er en viktig referanse for de enkelte FKB produktspesifikasjonene. Mange av begrepene/konseptene som benyttes i FKB forklares i dette dokumentet.

4. Normative referanser

Det er nødvendig å ha kjennskap til dokumentene under for fullt ut å forstå denne produktspesifikasjonen.

[ISO-METADATA] : 19115-1:2015 Geographic information - Metadata (Part 1: Fundamentals og Part 2: Extensions for acquisition and processing)

5. Definisjoner og forkortelser

5.1. Definisjoner

ajourføring

korrigering av innholdet i geodataene slik at de fremstiller de faktiske forhold på et gitt tidspunkt, etter de retningslinjer som gjelder for innhold og kvalitet [PABG]

applikasjonsskjema

informasjonsmodellene i SOSI-modellregister er modellert som UML-modeller. UML-modellen for et FKB-datasett benevnes som et UML-applikasjonsskjema. Fra UML-applikasjonsskjema kan det automatisk genereres et GML-applikasjonsskjema som beskriver hvordan dataene representeres som GML [SOSI-UML].

MERKNAD: Se objektkatalog

avledet datasett

bearbeidede primærdata tilpasset et bestemt bruksområde [FKB]

MERKNAD: Avledede data skal i prinsippet ikke ajourføres direkte, men ajourføringen skal komme gjennom automatisk utvelgelse og generalisering fra primærdata. I noen tilfeller vil dette være en for tung prosess slik at en må avvike fra hovedprinsippet. Kalles også generalisert datasett.

EKSEMPEL: N5 Kartdata (avledet/generalisert produkt fra FKB-data).

basis geodata

Detaljerte geodata som beskriver det fysiske landskapet ved naturlige eller menneskeskapte objekter. Basisdata brukes til lokalisering og som underlag for temadata. [FKB]

MERKNAD: basis geodata er synonymt med begrepet grunnkart (eller grunnkartdata)

datasett

identifiserbar samling av beslektede data [G]

egenskap

navngitt kjennetegn eller karakteristikk av et objekt

egenskapsnøyaktighet

uttrykk for hvor godt egenskapsdataene beskriver de aktuelle egenskapene [G]

featuretype

UML-modellelement for å modellere geografiske objekttyper [SOSI-UML].

MERKNAD: Begrepet brukes i mange sammenhenger synonymt med objekttype. Se også veileder for å lese UML-diagrammer.

Fotogrammetrisk FKB

FKB-data som er etablert ved fotogrammetrisk kartlegging [FKB]

MERKNAD: I Fotogrammetrisk FKB inngår også enkelte objekttyper som ikke registreres fotogrammetrisk. Eksempel er fiktive avgrensningslinjer og representasjonspunkt.

grunnkart

Grunnkart er et begrep som er synonymt med basis geodata. Se definisjon under basis geodata.

MERKNAD: Grunnkart brukes til flere formål og kan danne grunnlag for avledede kart i forskjellige målestokker. Grunnkartet skal være det kartgrunnlaget som skal tjene alle formål som omhandles i plan- og bygningsloven eller dens forskrifter.

fullstendighet

uttrykk for i hvilken grad spesifiserte deler av et produkt finnes i det aktuelle datasettet [G]

MERKNAD: Fullstendighet karakteriseres ved kvalitetsmålene manglende objekter, overskytende objekter (ønsket om fullstendige geodatabaser innebærer også at det er galt dersom det finnes objekter i databasene som ikke skal være der i henhold til spesifikasjonene) og manglende egenskaper. Fullstendighet kan angis i prosent i relasjon til spesifiserte krav. Informasjon om fullstendighet må være datert.

geodata

stedfestet informasjon [G]

MERKNAD: Geodata består av objektidentifikasjon og informasjon om stedfesting og egenskaper. Stedfestingsdataene på sin side kan omfatte både posisjonsdata og geometriske beskrivelsesdata.

kart

generalisert avbildning av geografiske objekter med deres romlige relasjoner; med angitt geodetisk datum, projeksjon og koordinatsystem, samt målestokk dersom avbildningen er analog [G]

kartdata

geodata tilrettelagt for presentasjon av kart [PABG]

kontinuerlig ajourhold

fortløpende ajourføring basert på rapportering fra forvaltningsrutiner, daglige arbeidsrutiner og samarbeidsparter [PABG]

MERKNAD: Kalles også administrativt vedlikehold. Data som samles inn administrativt, kan være digitale stikningsdata eller data fra sluttkontroll av beliggenhet, markmålte bygninger, senterpunkt bygning, situasjonsplan og melding om landbruksbygg.

kvalitet

i hvilken grad en samling av iboende egenskaper oppfyller krav [G]

MERKNAD: Se standarden Geodatakvalitet for en nærmere beskrivelse av datakvalitet.

logisk konsistens

hvor godt regler som finnes i spesifikasjonene er oppfylt [G]

MERKNAD: Logisk konsistens betegner sammenhengen mellom produktet og reglene produktet skal oppfylle. Logisk konsistens kan altså måles uten at en kjenner noen "fasit".

metadata

informasjon som beskriver et datasett [G]

MERKNAD: Hvilke opplysninger som inngår i metadataene, kan variere avhengig av datasettets karakter. Vanlige opplysninger er innhold, kvalitet, tilstand, struktur, format, produsent og vedlikeholdsansvar.

nøyaktighet

mål for en estimert verdis nærhet til sin sanne verdi eller til det man antar er den sanne verdi [G]

MERKNAD: I standarden Geodatakvalitet er de ulike nøyaktighetsmålene beskrevet.

objekt

forekomst (instans) av en objekttype [SOSI-UML]

objektkatalog

definisjon og beskrivelse av objekttyper, objektegenskaper samt relasjoner mellom objekter, sammen med eventuelle funksjoner som er anvendt for objektet. [SOSI-UML]

objekttype

geografisk objekttype er en klasse av objekter med felles egenskaper, forholdet mot andre objekttyper og funksjoner [SOSI-UML]

EKSEMPEL: Eksempler på objekttyper er Takkant, Arealbruksgrense og Mønelinje.

områdetype

arealinndeling basert på krav til detaljering/nøyaktighet av basis geodata i området [FKB]

MERKNAD: I FKB brukes områdetypen til å si noe om hvilken FKB-standard som bør velges i området. Områdetype brukes også som styrende for krav i standardene "Plassering og beliggenhetskontroll" og "Stedfesting av matrikkelenhets- og råderettsgrenser".

oppgradering

forbedring av den datatekniske kvaliteten av eksisterende data [PABG]

periodisk ajourhold

ajourføring som utføres systematisk med jevne mellomrom [PABG]

MERKNAD: Ved periodisk ajourføring blir eksisterende data, enten de har vært gjennom kontinuerlig ajourføring eller ei, kontrollert og evt. forbedret, og manglende objekter blir supplert. Objekter som ikke er endret, blir ikke kartlagt på nytt. Etter periodisk ajourføring skal datasettene minimum tilfredsstille kvalitetskravene for den valgte FKB-standard i området. Det kan være nødvendig også med en oppgradering for å oppfylle kvalitetskravene. Periodisk ajourføring gjøres vanligvis ved fotogrammetri.

presentasjonsdata

tilleggsdata til FKB som er nødvendige for å formidle en god presentasjon uten at de opprinnelige datasettene blir berørt [FKB]

MERKNAD: Presentasjonsdata lages for presentasjoner i ulike målestokker. Det genereres presentasjonsdata for å ha mulighet til blant annet å redigere, avblende/slette, skrive om eller flytte tekster og symboler i kartbildet, uten at datasettene blir berørt.

EKSEMPEL: Eksempler på presentasjonsdata er tekstdata generert fra datasett der tekst, tall eller symboler er ferdig plassert i kartbildet. En annen type presentasjonsdata er avblendingspolygoner som brukes til å fjerne unødig mye data i et aktuelt kartbilde.

primærdatasett

et definert geodatasett som består av de mest detaljerte og nøyaktige data innen et definert område, har en viss utbredelse og jevnlig blir produsert og/eller ajourholdt [G]

MERKNAD: Primærdatasett skal være presentasjons- og produktuavhengige. De skal kunne danne utgangspunkt for forskjellig bruk og forskjellige produkter. Det er derfor krav om en viss utbredelse og produksjon før en kan kalle et datasett for primærdatasett. Primærdatasett er i prinsippet uavhengige datasett (ikke avledet fra andre datasett) og ajourholdes uavhengig av andre datasett. Et objekt tilhører bare ett primærdatasett.

produktspesifikasjon

detaljert beskrivelse av ett datasett eller en serie med datasett med tilleggsinformasjon som gjør det mulig å produsere, distribuere og bruke datasettet av andre (tredjepart) [SOSI-KRAV]

MERKNAD: En dataproduktspesifikasjon kan lages for produksjon, salg, sluttbrukervirksomhet eller annet.

standardavvik

statistisk størrelse som angir spredningen for en gruppe måle- eller beregningsverdier i forhold til deres sanne eller estimerte verdier [G]

topologi

beskrivelse av sammenhengen mellom geografiske objekter [G]

MERKNAD: De aktuelle objektene har ofte en fysisk sammenheng. Topologi er de av objektenes egenskaper som overlever det som er kalt kontinuerlige transformasjoner (også kalt gummiduk-transformasjoner). Alle tallverdier (lengder, arealer og retninger) kan bli forandret, mens for eksempel naboskapsforhold vil være uendret.

5.2. Forkortelser

AR5: Arealressurskart i målestokk 1:5000

DOK: Det offentlige kartgrunnlaget. DOK er offentlige geografiske data som er tilrettelagt for kommunenes plan- og byggesaksarbeid. DOK er definert i [PBL-KART].

DTM: Digital TerrengModell.

ESRI fgdb: Leveranseformatet ESRI filgeodatabase (ESRI = Enviromental Systems Research Institute)

Georef: Metadataregister for Geovekst-data. Tilgjengelig som et datasett på Geonorge.

Geovekst: Geodatasamarbeid mellom de nasjonale partene KS (kommunesektorens organisasjon, omfatter både kommuner og fylkeskommuner), Energi Norge, Kartverket, Telenor, Statens vegvesen, Landbruksdepartementet og Norges vassdrags- og energidirektorat. Lokalt kan Geovekst-samarbeidet også ha andre parter.

GML: Geography Markup Language – Internasjonalt standardformat for utveksling av geografisk informasjon (OpenGIS® Geograph Markup Language (GML) Encoding Standard)

JSON: JavaScript Object Notation. Generelt tekstbasert utvekslingsformat som er mye brukt på nett og som også kan brukes for geografiske data. GeoJSON er en praktisk rettet spesifikasjon for å uttrykke geografiske data med vha. JSON.

NGIS: Nasjonalt Geografisk informasjonssystem. En generell modellbasert forvaltningsplattform for felles forvaltning av geografiske data i en sentral base gjennom åpne API-er som blant annet brukes i Sentral FKB. NGIS-OpenAPI er det nye grensesnittet for oppdatering av NGIS.

NRL: Nasjonalt register for luftfartshindre

NVDB: Nasjonal vegdatabank. Forvaltningsløsning for vegnettet og tilhørende informasjon eid av Statens vegvesen.

OCL: Object Constraint Language. Språk som brukes til å formulere krav/restriksjoner til modellelementene i UML.

PBL: Plan- og bygningsloven.

UML: Unified Modelling Language. Modelleringsspråk som (blant annet) brukes til å beskrive geografiske informasjonsmodeller.

URI: Uniform Resource Identifier. Kompakt streng av tegn som identifiserer en abstrakt eller fysisk ressurs.

UUID: Universally unique identifier. 128-bit globalt unik streng av tegn som kan genereres automatisk av en datamaskin.

WFS: Web Feature Service. Standard fra OGC (Open Geospatial Consortium) for å sende geografiske data over nett. WFS-T (T = Transaction) er en utvidelse for å sende endringer/transaksjonsdata.

6. Generelt om FKB

6.1. FKB-datasett

Tabellen under må justeres ut fra prosessen i standardiseringsprosjekt FKB 5.1 med tanke på versjonering av de enkelte datasettene. Det er forskuttert nye versjonsnummer for fotogrammetriske registreringsinstrukser

Tabell 1. Tabellen angir hvilke datasett som regnes som FKB-datasett i denne versjonen av FKB.
FKB-datasett Versjon Forvaltning Registreringsinstruks

FKB-AR5

5.0.1

Sentral FKB

Ikke aktuelt

FKB-Arealbruk

5.0.2

Sentral FKB

Fotogrammetrisk FKB-Arealbruk 5.0 2024-01-01

FKB-Bane

5.0.1

Sentral FKB

Fotogrammetrisk FKB-Bane 5.0 2022-01-01

FKB-BygnAnlegg

5.1

Sentral FKB

Fotogrammetrisk FKB-BygnAnlegg 5.0 2024-01-01

FKB-Bygning

5.1

Sentral FKB

Fotogrammetrisk FKB-Bygning 5.0 2024-01-01

FKB-Høydekurve

5.0.3

Sentral FKB

Punktsky FKB-Høydekurve 5.0 2022-01-01

FKB-Ledning

5.1

Sentral FKB

Fotogrammetrisk FKB-Ledning 5.0 2024-01-01

Punktsky FKB-Ledning 5.0 2022-01-01

FKB-Lufthavn

5.0.2

Sentral FKB

Fotogrammetrisk FKB-Lufthavn 5.0 2022-01-01

FKB-Naturinfo

5.0.1

Sentral FKB

Fotogrammetrisk FKB-Naturinfo 5.0 2024-01-01

FKB-Tiltak

5.1

Sentral FKB

Ikke aktuelt

FKB-TraktorvegSti

5.0

Sentral FKB

Fotogrammetrisk FKB-TraktorvegSti 5.0 2024-01-01

FKB-Vann

5.0.1

Sentral FKB

Fotogrammetrisk FKB-Vann 5.0 2024-01-01

FKB-Veg

5.0.1

Sentral FKB

Fotogrammetrisk FKB-Veg 5.0 2024-01-01

Elveg (vegnett)

(følger bare delvis reglene for resten av FKB)

Produktspesifikasjon Elveg 2.0

NVDB (med oppdatering fra kommunene gjennom Sentral FKB. Det jobbes med å ferdigstille produktspesifikasjonen NVDB Vegnett Plus som skal ta over for ELveg 2.0 i denne sammenhengen)

Fotogrammetrisk Elveg 2.0 2024-01-01

6.2. FKB-områdetyper

Det viktigste prinsippet i FKB er at en søker å kartlegge det samme området kun en gang, og at en kan benytte etablerte data til ulike formål. Dette kan for eksempel være kartproduksjon eller mer intelligente analysefunksjoner.

Behovene for FKB-data i en kommune varierer avhengig av hvilke formål datasettene skal brukes til. I FKB er det spesifisert FKB-standarder (FKB-A, FKB-B, FKB-C og FKB-D) som skal dekke behovet for felles kartdata i kommunens ulike områdetyper.

Detaljinnhold og stedfestingsnøyaktighet i FKB varierer i de ulike standardene, med størst detaljering og stedfestingsnøyaktighet i A-standarden og minst i D-standarden. Inndelingen i FKB-standarder setter krav til minimum detaljeringsgrad og stedfestingsnøyaktighet.

De ulike standarder kan benyttes slik at det for eksempel innen en kommune dannes et lappeteppe der flere av standardene er i bruk. Dette gir et datagrunnlag som er tilpasset behovet for felles kartdata i de ulike områdene av kommunen. Hvert enkelt (del)område kan bare være tilordnet en standard. Områdeinndelingen i en kommune vil kunne endre seg i takt med nye utbyggingsaktiviteter.

I praktisk vedlikehold av FKB kan det være aktuelt med forenklinger og varierende kompleksitet avhengig av de behov brukerne har. For delområder vil det for eksempel kunne være aktuelt å velge høyere standard enn det som gjelder for områdetypen generelt, for eksempel et hyttefelt i et fjellområde. Behov og ønsker hos brukerne er ofte relatert til kostnader, og kostnader er igjen relatert til metoder for datafangst etc. Det er derfor naturlig at brukeren definerer krav til innhold og krav til FKB-data som etableres.

Gjennom Geovekst-samarbeidet avgjøres i fellesskap hvilken FKB-standard som skal brukes i et område, og kartleggingskostnadene fordeles ut fra en kost/nytte vurdering. Dersom det er en part som har behov for kart med større detaljering og/eller bedre kvalitet enn de andre, vil denne parten måtte ta en større del av kartleggingskostnaden.

Kommunen har et spesielt ansvar for å påse at det er en tilstrekkelig kartleggingsstandard i kommunen til å utføre planleggingsoppgaver i kommunens ulike områdetyper.

Tabell 2. Oversikt over områdetyper som de ulike FKB-standardene skal benyttes i.
FKB-standard Områdetype Beskrivelse

FKB-A / FKB-B

Områdetype 1

Byområde.

Dette vil som regel være sentrale byområder og tettsteder med høy grad av utnytting eller svært høy grunnverdi.

FKB-B

Områdetype 2

Tettbygd/utbyggingsområder.

Dette vil være områder som i kommuneplanen er eller forutsettes disponert til tettsteds- og utbyggingsformål og som ikke omfattes av områdetype 1.

FKB-B / FKB-C

Områdetype 3

Spredtbygd/dyrket mark/skog.

Dette vil være områder som i kommuneplanen er eller forutsettes disponert til jordbruk eller skogbruk og spredt bebyggelse.

FKB-D

Områdetype 4

Områder med liten eller ingen bebyggelse.

Dette vil være den delen av kommunen som har en ekstensiv arealutnytting og lav grunnverdi: som regel fjellområder eller tilsvarende lite produktive arealer.

Skisse som viser prinsippene for inndeling av en kommune i forskjellige områdetyper
Figur 1. Eksempel på FKB-data i en kommune fordelt på områdetyper
Eksempel på kartutsnitt fra Georef-ABCD i Rogaland som viser fordeling av ulike områder i forskjellige FKB-standarder
Figur 2. Viser eksempel på fordeling av FKB-standarder i et område i Rogaland. Se laget Georef-ABCD i WMS-tjenesten for Georef

6.2.1. FKB-A-standard

Bruksområde:

Bruksområder for A-standarden er spesielt innenfor plan og prosjektering i byområder og tettsteder med høy utnyttelsesgrad, der kravet til detaljering, fullstendighet og stedfestingsnøyaktighet er meget stort. Data etablert etter A-standarden skal kunne benyttes som grunnlagsdata i en 3D (by)modell. A-standarden er aktuell som grunnlag for analyse og forvaltningsoppgaver for de mest intensive byområder og tettsteder med høy utnyttelsesgrad.

FKB-A-data kan benyttes til uttegning av detaljerte kart (målestokk 1:1000 eller bedre), samt utarbeidelse av produkter i målestokk 1:5000 som for eksempel N5 Raster og N5 Kartdata.

Detaljering:

FKB-A er en meget detaljert standard med detaljert registrering av bygninger (arker, verandaer, trapper mv) og med detaljert registrering av høyder på oppstikkende objekter (hus, mur, gjerde, mast med videre). Høydereferansen på objektene er vanligvis topp, mens detaljert terrenggrunnlag gir fothøyden til objektene.

Etableringsmetode:

Storparten av A-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 5–8 cm).

For en del datasett vil A-dataene bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for A-standarden.

Skisse som viser eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i A-standarden
Figur 3. Eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i A-standarden. Alle objekter i figuren er registrert i tre dimensjoner. I øvre venstre hjørne vises en 3D-modell av bygningen slik den kan dannes fra A-dataene (forutsetter en god terrengmodell). Modellen er her laget med utgangspunkt i takkanten.

6.2.2. FKB-B-standard

Bruksområde:

B-standarden benyttes i områder med tettbebyggelse og blandet bebyggelse, utbyggingsområder og langs større veger (europa-, riks- og fylkesveger). Denne standarden bør benyttes for de fleste områder utenfor byene der det finnes en viss mengde bygninger og tekniske installasjoner. B-standarden kan benyttes til detaljprosjektering og ved utarbeidelse av reguleringsplaner, men har enkelte begrensninger i forhold til A-standarden. B-standarden kan benyttes som grunnlagsdata for utarbeidelse av 3D-modeller, men disse vil ikke være like detaljert som i A-standarden.

FKB-B-data kan benyttes til uttegning av detaljerte kart (målestokk 1:1000 eller bedre), samt utarbeidelse av produkter i målestokk 1:5000 som for eksempel N5 Raster og N5 Kartdata.

Detaljering:

FKB-B er en detaljert standard med registrering av bygningsdetaljer (arker, verandaer, trapper med videre) og detaljert registrering av høyder på oppstikkende objekter (bygning, mur, gjerde, mast med videre). Høydereferansen på objektene er vanligvis topp, mens detaljert terrenggrunnlag gir fothøyden til objektene. Forskjellen på B-standard og A-standard er i hovedsak at det er større minstemål på objekter før de skal registreres i B-standarden.

Etableringsmetode:

Storparten av B-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 8–12cm). For en del datasett vil B-dataene kunne bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for B-standarden.

Skisse som viser eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i B-standarden
Figur 4. Eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i B-standarden. Alle objekter i figuren er registrert i tre dimensjoner. I øvre venstre hjørne vises en 3D-modell av bygningen slik den kan dannes ut fra B-dataene (forutsetter en god terrengmodell). Denne modellen viser hovedformen til bygningen, men er ikke like detaljert som A-standarden.

6.2.3. FKB-C-Standard

Bruksområde:

C-standarden benyttes i spredt bebygde og ubebygde områder. C-standarden har begrensninger innenfor utarbeidelse av reguleringsplaner, situasjonsplaner og byggeplaner og skal ikke etableres i områder der det er naturlig å etablere FKB-data etter B-standarden. C-standarden kan benyttes som grunnlagsdata for utarbeidelse av enkle 3D-modeller.

FKB-C kan benyttes til utarbeidelse av N5-produkter som for eksempel N5 Raster og N5 Kartdata

Detaljering:

FKB-C inneholder bygningers hovedform og de dominerende detaljene i topografien forøvrig. En del mindre detaljer registreres ikke i FKB-C og minstemål for registering er større enn i FKB A-B. Historisk ble detaljeringen i FKB-C utformet slik at den tilsvarte det tidligere økonomiske kartverket (ØK).

Etableringsmetode:

Storparten av C-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 15-25 cm). For en del datasett vil C-dataene kunne bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for C-standarden.

Skisse som viser eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i C-standarden
Figur 5. Eksempel på detaljering for bygning-, vann-, veg, vegnett og ledningsdata i C-standarden ved fotogrammetrisk datafangst. Alle objekter er registrert i 3 dimensjoner. I enkelte tilfeller vil vanndataene være etablert fra eksisterende ØK ved digitalisering, og da vil disse objektene normalt være representert i 2 dimensjoner. I øvre venstre hjørne vises en 3D-modell av bygningen slik den kan dannes fra C-dataene.

6.2.4. FKB-D-standard

Bruksområde:

D-standarden benyttes i områder med liten eller ingen bebyggelse (stort sett fjellområder). For å få heldekkende FKB-datasett for en kommune skal D-områdene fylles med data. Dette for å få landsdekkende data slik at vi ikke får ”hvite hull” i datasettene.

Skisse som viser hvordan FKB-data med og uten innhold i FKB-D-områder
Figur 6. Eksempel på FKB-data for et område med og uten data i D-områdene.

Etablering og detaljering:

For FKB-D data etablert tidligere vil detaljering i hovedsak være lik N50 Kartdata for vann, høyde, stier, traktorveger og bygningsmessige anlegg. Ved nyere etablering fra omløpsfoto vil D-standarden i hovedsak være lik C-standarden. Innholdet vil imidlertid variere fra datasett til datasett.

Tabell 3. Beskrivelse av datainnhold i de forskjellige datasettene i FKB-D-områdene.
Datasett Innhold

AR5

Flater med kode "Ikke kartlagt". NIBIO jobber med å fylle AR5 med et forenklet innhold fra skogressurskart (SR16) også i D-områder.

Høydekurve

Høydekurver avledet fra laserskanning eller etablert ved bildematching fra omløpsfoto i NDH-prosjektet. 1m ekvidistanse der det er utført laserskanning og 5m ekvidistanse i områder der det er utført bildematching. Gamle fotogrammetriske kurver kan fortsatt finnes igjen i enkeltområder.

Vegnett

Hentes fra NVDB. Samme innhold uavhengig av FKB-standard.

Tiltak

Samme innhold uavhengig av FKB-standard. Lite aktuelt i D-områder.

Vann

Eksisterende data er hovedsaklig likt N50 i detaljering og innhold. Ved nykonstruksjon er standarden lik C-standarden, med unntak for minstestørrelser for ElvBekk, KanalGrøft og Innsjø.

TraktorvegSti

Traktorveger og stier har i utmarksområder et forvaltningsopplegg som i stor grad baserer seg på andre datakilder enn fotogrammetri. Bl.a. samordning med N50 og friluftsruter. Datainnholdet er i stor grad uavhengig av FKB-standard.

Øvrige FKB-datasett

Lik C-standarden. Forskjellen ligger i at det er færre objekter å kartlegge i D-områder. Områder der det finnes menneskeskapte objekter av et visst omfang er i all hovedsak definert som FKB-C områder.

6.2.5. Høydegrunnlag

Datasettet FKB-Høydekurve er hovedsakelig avledet/generert fra Nasjonal Detaljert Høydemodell (NDH). NDH inneholder punktskyer fra laserskanning i de fleste områder, men noen områder med lite vegetasjon (høyfjellsområder) har terrengmodeller basert på bildematching fra flybilder med oppløsning 25 cm (omløpsfoto). Ved laserskanning gjennom NDH-prosjektet og Geovekst er leveranse av genererte høydekurver med 1m ekvidistanse basert på terrengmodellene standard. For områder der terrengmodellen er basert på bildematching genereres høydekurver med 5m ekvidistanse. Disse kurvene forvaltes i FKB-Høydekurve. Gamle høydekurver basert på fotogrammetrisk datafangst kan fremdeles finnes i enkelte områder.

Ved større terrenginngrep anbefales det at det gjøres ny laserskanning og at FKB-Høydekurve oppdateres med bakgrunn i oppdaterte sensordata. I påvente av nye høydekurver anbefales det at man fjerner høydekurvene i områder der man vet at terrenget er endret slik at FKB-Høydekurve ikke gir feilaktig informasjon.

For å få den mest detaljerte terrenginformasjonen bør terrengmodellene fra Høydedata.no brukes direkte og ikke de avleda høydekurvene i FKB.

6.3. Uavhengige primærdatasett

FKB bygger i utgangspunktet på prinsippet om uavhengige primærdatasett. Med dette menes at primærdatasettene ikke er avledet fra andre datasett og ajourføres uavhengig av andre datasett. Hvert primærdatasett kan på denne måten leve atskilt fra andre datasett. Et objekt skal kun tilhøre ett primærdatasett.

Uavhengige primærdatasett er nyttig fordi de ulike datasettene vedlikeholdes av ulike instanser, til ulik tid og med ulike verktøy. Dette gir en effektiv dataforvaltning, men gir også muligheter for inkonsistens mellom datasettene. Det er derfor viktig at det kjøres konsistenskontroller mellom FKB-datasettene (og ev. andre datakilder).

Merknad: Prinsippet om uavhengige datasett blir ikke etterlevd fullt ut. Mange objekter forvaltes av praktiske/tekniske/organisatoriske årsaker i flere systemer. Dette er likevel et godt prinsipp for å få til effektiv dataforvaltning og som det bør være et mål å etterstrebe ved modellering og forvaltning av FKB-data.

6.4. Identifikasjon av objekter i FKB

6.4.1. Unik identifikasjon av kartobjektene i FKB

Alle kartobjekter i FKB har en unik identifikator i form av datatypen Identifikasjon. Identifikasjon er en datatype som består av navnerom, lokalid og versjonid. For FKB-data er lokalid på formen UUID [UUID]. Dette innebærer at lokalid-en alene alltid er globalt unik. Identifikasjon er modellert som en del av fellesegenskapene i FKB. Se detaljer om dette under kapittel 7.

Logikken rundt identifisering og håndtering av unike objekter i FKB konsentrerer seg om håndtering av egenskapen lokalid. Ved bruk av FKB-data skal man forholde seg til lokalid som den egenskapen som identifiserer hvert kartobjekt i FKB unikt. Både NGIS-OpenAPI og Geosynkronisering-API baserer seg på lokalid til å identifisere transaksjoner på objekter i FKB. Når FKB-data utveksles på GML-format skal GML-id til objektene inneholde lokalid.

Det er vesentlig å presisere at identifikasjon på kartobjektene i FKB nettopp identifiserer et kartobjekt og ikke det fysiske objektet som kartobjektet representerer. Det kan oppstå nye/endra kartobjekter som representerer det samme fysiske objektet og man bør derfor være forsiktig med å knytte informasjon om det fysiske objektet til den unike identifikatoren i FKB. I slike sammenhenger bør man i stedet benytte en tematisk identifikator som f.eks. bygningsnummer for objekttype Bygning.

Regler for håndtering av lokalid:

FKB inneholder mange typer data og det er vanskelig å lage detaljerte regler for håndtering av identifikasjon i forbindelse med geometrioperasjoner som gjelder generelt for FKB. Noen overordna føringer gjelder likevel:

  • Nye kartobjekter: Det genereres en ny lokalid til objektet

  • Endring av et objekt (egenskaper og/eller geometri): Lokalid beholdes (versjonid oppdateres).

    • Endring av objekttype på et objekt er et spesialtilfelle. Dette håndteres som at et objekt av den gamle objekttypen slettes og at et objekt av den nye objekttypen etableres (lokalid beholdes ikke, se regler under).

  • Sletting av objekt: Objektet (inkl. lokalid) slettes. Nye objekter som oppstår skal ikke gjenbruke en lokalid som allerede er brukt/slettet

  • Splitting av et objekt: Håndteres som ett endret objekt (lokalid beholdes) og ett nytt objekt (ny lokalid)

  • Sammenføying av to objekter: Håndteres som ett endret objekt (lokalid beholdes) og ett slettet objekt

Dersom det finnes egenskaper på kartobjektene som er knyttet til det fysiske objektet (f.eks. bygningsnummer i FKB-Bygning) så må det lages rutiner som sikrer at denne informasjonen tas vare på gjennom av alle typer endringer i kartobjektene. Den generelle transaksjonslogikken i FKB vil ikke automatisk håndtere dette. Les mer om dette under Koblingsnøkler til andre data.

Alternativ håndtering av lokalid:

Det absolutte kravet i FKB er at situasjonen etter transaksjonen er komplett/riktig. I noen tilfeller er det lite hensiktsmessig/meningsfullt å beholde lokalid ved splitting/sammenføying av objekter. Dette kan f.eks. være ved ajourhold av FKB-AR5 (eller andre datasett) der det er vanskelig å knytte et kartobjekt til et spesifikt objekt i terrenget. I slike tilfeller kan man velge en alternativ håndtering ved splitting/sammenføying:

  • Splitting av objekt: Håndteres som ett slettet objekt og to nye objekter (to nye lokalid-er)

  • Sammenføying av objekt: Håndteres som to slettinger og ett nytt objekt (en ny lokalid).

Regler for håndtering av navnerom:

Regler for håndtering av versjonid:

  • Versjonid settes lik tidspunkt for oppdatering av objektet i forvaltningsbasen. Dette styres også automatisk av forvaltningssystmet. Versjonid er nøkkelen ved historiske spørringer mot FKB-data.

  • I forvaltningsbasen vil versjonid ha lik verdi som oppdateringsdato. Les mer om dette under Oppdateringsdato

Les mer om håndtering av identifikasjon i i forvaltningssystemet NGIS/Sentral FKB.

6.4.2. Koblingsnøkler til andre data

Datasettene i FKB inneholder noen koblingsnøkler til tilsvarende objekt i andre databaser. Dette gjøres ved at det legges en egenskapsverdi som unikt identifiserer det tilsvarende objektet i det eksterne systemet inn på kartobjektet i FKB.

Koblingsnøkler til andre data gir mulighet til å koble FKB-data til andre typer data og gir brukeren vesentlig større nytteverdi. Å etablere koblingsnøkler slik som omtalt over kan være arbeidskrevende.

Koblingsnøkler gir også muligheter for å utføre automatisk feilsjekking av FKB-dataene mot de eksterne dataene. Når dette blir gjort, oppdages en god del feil som må rettes. Ved å ta belastningen ved å rette opp feil vil data imidlertid gi vesentlig sikrere bruk i den daglige forvaltning. Koblingsnøkler som skal opprettes i FKB, er spesifisert under det enkelte datasett.

Eksempel på godt etablerte koblinger fra FKB til andre systemer/databaser er:

  • Kobling mellom representasjonspunkt i bygninger i FKB og Matrikkel (koblingsnøkkel er bygningsnummer - bygningens unike identifikasjon).

  • Kobling mellom veglenker i vegnettet (Elveg 2.0) og FKB-TraktorvegSti og adressekode/navn i Matrikkelen (koblingsnøkkel er adressekode).

Eksterne pekere som URI:

Ved innføring av FKB 5.0 innføres mulighet for kobling mot andre systemer i form av URI-er [URI] for en rekke nye objekttyper. Eksempler på dette er:

  • nvdbpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i NVBD

  • nrlpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i NRL

  • eksternpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i et eksternt system (angitt av URI-en)

Det er ikke et krav om at URI-en skal peke til en åpen tjeneste som gir en presentasjon av objektet i det eksterne systemet, men bruken av URI-er åpner for at dette er mulig.

6.5. Bruk av datoegenskaper

Fellesegenskapene for FKB definerer hvilke datoegenskaper som skal benyttes i FKB. Se kapittel 7 for detaljer i hvordan det er modellert. Dette kapittelet beskriver detaljer for den praktiske bruken av datoegenskapene.

6.5.1. Datafangstdato

Datafangstdato angir dato for måling/observering/registrering av objektet (i terrenget).

  • Ved fotogrammetrisk datafangst vil dette være datoen for når flybildene som ligger til grunn for kartkonstruksjonen ble tatt (flyfotodato).

  • Ved digitalisering av eksisterende kart vil dette normalt være datoen for når flybildene kartene er produsert etter er tatt (flyfotodato).

  • Ved landmåling vil dette være datoen for innmåling.

Ukjent dato: Datafangstdato er påkrevd på alle objekter. For en del eldre data kan det være at objektene ikke er kodet med noen dato. Som dummyverdi for FKB-data skal 18000101 benyttes.

6.5.2. Verifiseringsdato

Verifiseringsdato angir dato for når det er fastslått at eksisterende dataobjekt fremdeles samsvarer med objektet i virkeligheten. Egenskapen brukes f.eks. i forbindelse med fotogrammetrisk ajourhold, og hvor det ikke er registrert endringer på objektet (det virkelige objektet er i samsvar med dataobjektet).

6.5.3. Oppdateringsdato

Oppdateringsdato er tidspunkt for oppdatering i forvaltningssystemet. Dette er en verdi som styres automatisk av forvaltningssystemet etter følgende regler:

  1. Oppdateringsdato er datotid for oppdatering av databasen settes av forvaltningsbasen (ikke av klienten). For data i Sentral FKB vil verdien for oppdateringsdato samsvare med versjonid.

  2. Oppdateringsdato skal endres også hvis det er kopidata som blir endret eller importert i en ”kopibase”. I en kopibase vil altså oppdateringsdato være oppdatert, mens versjonid fortsatt skal ha en verdi som beskriver tidspunkt for oppdatering i forvaltningsbasen.

  3. Når avgrensingslinjene til en flate endres, skal flateobjektet få ny oppdateringsdato.

  4. Oppdateringsdato skal endres hvis en egenskap endres.

6.5.4. Sluttdato

Sluttdato er tidspunkt for når versjonen av objektet ble erstattet eller opphørte å eksistere. Egenskapen styres av forvaltningssystemet. Sluttdato sendes bare med ut fra forvaltningssystemet ved historiske spørringer. For levende data vil ikke sluttdato ha noen verdi og egenskapen skal da heller ikke sendes med.

6.5.5. Praktisk bruk av datoegenskapene i forbindelse med ajourhold av FKB-data

Ved fotogrammetrisk ajourføring blir noen objekter registrert på nytt, noen får endret databeskrivelse, noen slettes, mens andre forblir uforandret. For påføring av de ulike datoegenskapene gjelder følgende ved en fullstendig fotogrammetrisk ajourføring:

  1. Nye dataobjekter skal ha påført ny DATAFANGSTDATO (=flyfotodato for bildene som ligger til grunn for kartkonstruksjon).

  2. Dataobjekter som fantes fra før i datasettet og det gjennom visuell inspeksjon blir verifisert at objektene fortsatt eksisterer uforandret i terrenget, skal beholde gammel DATAFANGSTDATO. I tillegg skal ny VERIFISERINGSDATO legges på objektet. Dette selv om man ikke har kontrollert at egenskapskodingen av objektet er riktig. Dersom det er dataobjekter som ikke synes i bildene, for eksempel på grunn av gjengroing, skygge i bildene eller overdekking, må det utøves skjønn. Enten vurderes det at dataobjektet fremdeles eksisterer uforandret (kodes som over) eller at det er borte (slettes). Dersom man er i stor tvil, skal dataobjektet beholdes uten påføring av verifiseringsdato.

  3. Endrede dataobjekter skal ha påført ny DATAFANGSTDATO (=flyfotodato for bildene som ligger til grunn for endringen). Dersom det kun er deler av et objekt som er endret, splittes dataobjektet. Det samme gjelder for objekter som krysser prosjektavgrensningen. Den delen som er uforandret beholder DATAFANGSTDATO, men det settes på ny VERIFISERINGSDATO. Den delen av objektet som er endret får kun ny DATAFANGSTDATO.

  4. Sletting av dataobjekter. Når objektet ikke fins i terrenget lenger, eller det vurderes til å ha blitt borte, skal det slettes fra FKB. I ajourholdsprosjekter vil det være en god ide å levere slettede objekter til oppdragsgiver. Typisk kan dette gjelde bygninger som ikke er merket som revet/brent, flyttet eller utgått i Matrikkelen.

Figur som viser eksempel på bruk av datafangstdato og verifiseringsdato på FKB-data
Figur 7. Eksempel på datering av objekter ved fotogrammetrisk ajourføring

6.6. Kodelister

Alle kodelister i FKB 5.0 forvaltes i Geonorge kodelisteregister. I UML-modellene ligger tomme kodelister med referanse (URL) til kodelistene i Geonorge. Dette innebærer at kodelistene i FKB kan endres uten at versjonsnummer på produktspesifikasjonene oppdateres. Systemer som forholder seg til FKB datamodellene må også forholde seg til Geonorge kodelisteregister.

Alle kodelister i Geonorge kodelisteregister inneholder 3 verdier: kodenavn, beskrivelse/definisjon og kodeverdi. Det er kodeverdiene som utveksles i dataene i alle formater, mens kodenavn og beskrivelse vil være det som presenteres for brukerne i de fleste tilfeller.

Retningslinjene for utforming av kodeverdier i FKB 5.0:

  • Kodeverdiene må være unike og teknisk enkle å utveksle/tolke. Det innebærer at norske tegn, skilletegn (bindestrek/underscore/mellomrom) og andre spesialtegn unngås. Som hovedregel brukes små bokstaver og ved sammensatte kodeverdier brukes stor bokstav på andre ledd ("NCName")

  • Kodeverdiene skal være kortest mulig (normalt under 10 tegn)

  • Kodeverdiene skal om mulig gi en intuitiv mening (en forkortet/sammentrekt versjon av kodenavn e.l.)

  • Etablerte kodeverdier (f.eks. i form av tallverdier) fra tidligere versjoner av FKB eller andre systemer som NVDB/Matrikkelen beholdes

Statuskoder i Geonorge kodelistergister:

  • Status Gyldig: Brukes for gyldige koder i FKB. Kun kodeverdier med status Gyldig skal brukes ved oppdateringer inn i FKB

  • Status Utgått og Erstattet: Brukes for koder som ikke lenger skal benyttes ved oppdateringer i FKB. Det kan likevel være mulig at eldre FKB-data har disse kodene.

  • Status Sendt inn, Ikke godkjent og Utkast: Brukes for koder som er foreslått brukt i FKB, men disse skal ikke benyttes før status ev. endres til Gyldig.

6.7. Vedlikehold

Hovedprinsippet for ajourføring av FKB-data er at utvalgte objekter og datasett skal ajourføres kontinuerlig gjennom daglige administrative rutiner, for eksempel byggesaksbehandling, eller ved rapportering fra samarbeidspartene. Fullstendighet og hurtig oppdatering av de viktigste objektene skal prioriteres fremfor stedfestingsnøyaktighet. Dette betyr at stedfestingsnøyaktighet i enkelte tilfeller kan bli dårligere enn kravet til aktuell FKB-standard. Det er imidlertid et krav at alle aktuelle objekter skal være kodet med opplysninger om datafangstmetode og stedfestingsnøyaktighet (..KVALITET).

Alle endringer vil ikke bli fanget opp gjennom administrative rutiner, og det vil derfor være nødvendig med periodisk ajourføring, der hele datasettet gjennomgås og bringes opp på et ajourført nivå tilsvarende som ved nykartlegging. Ved periodisk ajourføring skal data fra kontinuerlig ajourføring kontrolleres, eventuelt forbedres, manglende objekter skal suppleres og overskytende objekter skal slettes. Objekter som ikke er endret, blir ikke kartlagt på nytt. Hyppigheten av periodisk ajourhold varierer avhengig av områdetype og byggeaktivitet.

Figur som viser oppdatering av FKB gjennom kontinuerlig og periodisk ajourhold
Figur 8. De 2 hovedprosessene for ajourføring av FKB-data.

For mer informasjon om ajourføring av FKB-data henvises det til veilederen til standarden Produksjon av basis geodata [PABG] og Geovekst veiledningsdokumentasjon [GEO-VEIL]. Det henvises også til spesifikasjonen av datasettet FKB-Tiltak som handler om å fange opp objekter i kontinuerlig ajourhold gjennom saksbehandling.

6.8. Oppgradering

Med oppgradering menes forbedring av den datatekniske kvaliteten av eksisterende data.

Ved utgivelse av nye versjoner av Produktspesifikasjon for FKB må det vurderes i det enkelte tilfelle om og hvordan eldre FKB-data skal oppgraderes. Dette vil ofte være et økonomisk spørsmål. Data skal som minimum oppgraderes slik at de er kodet i henhold til gjeldende versjon av FKB. Eventuelle mangler i forhold til gjeldende versjon av FKB skal lagres som metadata.

Oppgradering av eldre FKB-data kan deles inn i tre hovedgrupper.

  1. Oppdatering av koder til ny SOSI/FKB-versjon. Objekttyper og egenskaper skal omkodes til gjeldende versjon av SOSI/FKB. I en del tilfeller der man har eldre data kan det være aktuelt å ikke oppgradere dataene slik at de følger alle topologiske regler som er spesifisert i FKB.

  2. Oppgradering av FKB-data fra 2 dimensjoner til 3 dimensjoner (med høyde). For data på terrenget som mangler høyde vil det være interessant å påføre høydeverdier fra terrengmodell. Dette kan gjøres i egne oppgraderingsprosjekter eller i forbindelse med periodisk ajourføring.

  3. Konsistens mellom datasett. Enkelte FKB-data skal være koblet mot registerdatabaser. Forbedring av disse koblingene er aktuelt å gjøre som egne oppgraderingsjobber. Eksempel på en slik oppgraderingsjobb er ”husvask”. I ”husvask” kontrolleres at bygningspunkt i Matrikkel ligger inne i bygningskroppen.

6.9. Sømløse data

Mellom kommuner eller fylker:

FKB-data forvaltes i Sentral FKB. Prinsippet er at forvaltningsløsningen er satt opp mest mulig sømløs, men praktiske hensyn gjøre at noen datasett likevel er delt i kommunevise eller fylkesvise baser. Alle datasett er delt i sondedeler slik at kommunene oppdaterer direkte i sin lokale UTM-sone.

Ved deling i forskjellige forvaltningsbaser er det gjeldende administrative grense som brukes til avgrensning.

Figur som viser problemer med gap/overlapp grunnet manglende sømløshet
Figur 9. Eksempel på data fra to nabokommuner der man ikke har forvaltet dataene etter et felles forvaltningsområde. Kommunegrensen er tegnet med svart tykk stiplet linje.

Mellom områdetyper/kartleggingsstandarder:

Forvaltningen skjer sømløst mellom kartleggingsstandardene (A-D). Det er kun kvalitetskodingen som angir at data har ulik stedfestingsnøyaktighet. Det er metadataregisteret Georef som angir gjeldende kartleggingsstandard. Georef er tilgjengelig som WMS-tjeneste, se informasjon på geonorge.no.

7. Modellering av FKB produktspesifikasjoner

FKB 5.0 skal generelt modelleres i henhold til reglene i SOSI Regler for UML-modellering versjon 5.1 [SOSI-UML]. I tillegg er det gjort noen presiseringer/innsnevringer for FKB som er beskrevet i dette kapittelet. FKB Generell del inneholder felles modelleringselementer (kodelister, datatyper og fellesegenskaper) som realiseres i de enkelte FKB produktspesifikasjonene.

7.1. Geometrimodell i FKB

7.1.1. Geometrityper

Tabell 4. Tabell over hvilke geometrityper som kan benyttes i FKB 5.0 i UML-modellene og forskjellige formater
UML (ISO 19107) SOSI Geometri GML Geometri JSON Geometri

GM_Point

.PUNKT

gml:Point

point

GM_Curve

.KURVE

gml:Curve

linestring

GM_Surface

.FLATE

gml:Surface

polygon

FKB-data skal ha en enklest mulig geometri. Andre geometrityper enn de som er angitt i tabellen over (som f.eks. multipoint, multicurve, multisurface etc.) skal ikke benyttes i FKB 5.1.

7.1.2. Flere geometrier

Hovedregel i FKB produktspesifikasjoner er at hver objekttype modelleres med en geometriegenskap. Det finnes imidlertid noen unntak fra denne hovedregelen. Se tabell under for mulige kombinasjoner av geometriegenskaper for objekttyper som er definert med mer enn en geometriegenskap i FKB:

Tabell 5. Tabell over hvilke kombinasjoner av geometrityper som kan benyttes som multippel geometri i FKB 5.0
Kombinasjon av geometriegenskaper Beskrivelse Eksempel

Påkrevd flategeometri og opsjonell punktgeometri

Brukes for objekttyper med flategeometri for å gi mulighet til å utveksle representasjonspunkt for flategeometrien. Anbefales kun brukt der representasjonspunktet har en mening/funksjon.

Objtype Arealressursflate

Påkrevd punktgeometri og opsjonell flategeometri

Brukes for objekttyper som alltid vil ha punktgeometri, men som også kan ha flaterepresentasjon.

Objtype Bygning

Opsjonell punktgeometri og opsjonell flategeometri (og en constraint som sier at en av dem skal finnes)

Brukes for objekttyper som det i noen sammenhenger er naturlig å representere som punkt og i andre sammenhenger som flate (ut fra størrelse/detaljering etc).

Objtype Pipe

I alle disse kombinasjonene vil det være et krav om at punktgeometrien ligger innenfor flategeometrien. I GML-formatet vil disse dataene utveksles med flere geometriegenskaper. I SOSI-formatet vil de bare ha en geometri. Enten punktgeometri eller flategeometri - der punktgeometrien utveksles som representasjonspunkt i flaten.

7.1.3. Assosiasjoner

Kartobjektene i FKB er alltid selvstendige objekter som kan eksistere uavhengig av andre objekter. Assosiasjoner uttrykker generelt en eller annen sammenheng mellom to objekttyper/objekter. Et eksempel på dette kan være å uttrykke hvilke Veranda-objekter som tilhører hvilke Bygning-objekter. FKB 5.1 åpner for å benytte assosiasjoner i datamodellene etter følgende rammer:

  • Assosiasjoner modelleres som vanlige assosiasjoner i tråd med reglene i SOSI Regler for UML-modellering 5.1 [SOSI-UML]. Andre varianter av assosiasjoner som aggregering, komposisjon etc. benyttes ikke i FKB.

  • Assosiasjoner i FKB skal alltid modelleres mellom konkrete/instansierbare objekttyper (og altså ikke til/fra supertyper). Dette gjør det enklere å implementere assosiasjonene som koblingstabeller i geografiske databaser.

  • Assosiasjoner i FKB modelleres som hovedregel som enveis. Det vil si at de bare er navigerbare i en retning. (Eks: Bygningen vet hvilke verandaer som hører til bygget, men verandaen vet ikke hvilken bygning den tilhører)

  • Multiplisitet på den navigerbare enden skal alltid være 0..1 eller 0..*. (Dvs. at det at det finnes et objekt av en objekttype vil ikke medføre krav om at det må finnes et referert objekt av en annen type.)

  • Assosiasjonene modelleres slik at det settes krav til at de assosierte objektene utveksles som refererte objekter i GML (dvs. ved bruk av taggen inlineOrByReference=byReference i UML)

  • Dersom det benyttes assosiasjoner som er navigerbare i begge retninger så skal det ikke være multiplisitet 0..* i begge ender. (Dvs. at mange-til_mange-forhold unngås i FKB datamodeller)

Se eksempler på Utveksling av assosiasjoner på GML- og SOSI-format i Vedlegg C.

Hvilke avgrensningskurver som brukes til å avgrense et flateobjekt er en spesialvariant av assosiasjoner med egne krav. Dette er beskrevet nærmere under Modellering av flateobjekter

7.1.4. Flategeometri

7.1.4.1. To typer flateobjekter

Objekttyper i FKB med flategeometri deles i 2 typer:

Tabell 6. Oversikt over de 2 typene flateobjekttyper som finnes i FKB
Type Beskrivelse Flatereferanser Eksempel

1

Der avgrensningsobjektene ikke har noen funksjon utover å avgrense flateobjektene ("simple-feature" flater)

Ingen avgrensningsobjekter, ingen flatereferanser ("heleid geometri")

Objekttype Brønn, Objekttype Industriområde

2

Der det finnes egne avgrensningsobjekter og det er krav til sammenheng mellom flateobjektene og avgrensningsobjektene

Flateobjektet vet hvilke avgrensningsobjekter som utgjør flateavgrensningen og retning og rekkefølge på disse objektene ("delt geometri")

Objtype Bygning, Objtype Elv

7.1.4.2. Modellering av flateobjekter

Hvilken av de 2 typene flater en objekttype er må man ta stilling til når man utarbeider FKB produktspesifikasjonen.

flategeometri modell
Figur 10. Mal for UML-modellering av objekttyper med flategeometri. "Type 1" til venstre og "Type 2" til høyre

Det er lov (men ikke anbefalt) å modellere med opsjonell punktgeometri i tillegg til flategeometrien for å kunne utveksle representasjonspunkt for flater. Dette gjelder flater av både "Type 1" og "Type 2".

Dersom man skal modellere en objekttype av "Type 2" (med krav til sammenheng mellom flateobjekt og avgrensningsobjekter) gjelder følgende regler ved UML-modelleringen:

  1. Det etableres en assosiasjon fra flateobjekttype (kilde) til avgrensningsobjekttype (mål)

  2. Assosiasjonen skal være navigerbar fra kilde til mål (se pil i figuren over)

  3. Assosiasjonen skal ha mulitiplisitet null-til-mangemål-siden av assosiasjonen

  4. Assosiasjonen skal ha rollenavn som starter med avgrensesAvmål-siden (rollenavnene må være unike pr. flateobjekttype så dersom en flateobjekttype kan avgrenses av flere typer avgrensningsobjekter så legges avgrensningsobjekttype som postfiks i rollenavnet for å gjøre det unikt)

  5. Flateobjekttypen skal ha restriksjon med denne beskrivelsen: "Område-geometrien skal være lik summen av geometriene til de assosierte avgrensningsobjektene"

Se eksempler på Utveksling av flategeometri på GML- og SOSI-format i Vedlegg C.

7.2. UML felleselementer til bruk i «ApplicationSchema» for FKB-datasett

Generelle klasser med fellesegenskaper som kan kopieres inn og benyttes i FKB produktspesifikasjoner.


7.2.1. Pakke: Generelle elementer

Definisjon: Pakke med modelleringselementer som benyttes i applikasjonsskjema for forvaltning av FKB


Realisering fra SOSI generelle typer
Figur 11. Realisering fra SOSI generelle typer

Oversiktsdiagram Fellesegenskaper
Figur 12. Oversiktsdiagram Fellesegenskaper

Hoveddiagram Posisjonskvalitet
Figur 13. Hoveddiagram Posisjonskvalitet

7.2.1.1. «FeatureType» Fellesegenskaper (abstrakt)

Definisjon: abstrakt objekttype som bærer sentrale egenskaper som er anbefalt for bruk i produktspesifikasjoner.

Egenskaper

Navn:

identifikasjon

Definisjon:

unik identifikasjon av et objekt

Merknad FKB:

Unik identifikasjon av et objekt, ivaretas av den ansvarlige produsent/forvalter, og som kan benyttes av eksterne applikasjoner som referanse til objektet.

Den unike identifikatoren er unik for kartobjektet og skal ikke endres i kartobjektets levetid. Dette må ikke forveksles med en tematisk identifikator (for eksempel bygningsnummer) som unikt identifiserer et objekt i virkeligheten. En bygning med samme bygningsnummer vil kunne representeres i mange kartprodukter der det finnes en unik identifikasjon i hver av dem.

For FKB benyttes UUID (Universally unique identifier) som lokalId. Dette innebærer at lokalId alene alltid vil være unik. Likevel skal alltid navnerom også angis. Navnerom angir FKB-datasettet.

Multiplisitet:

[1..1]

Type:

«dataType» Identifikasjon

Profilparametre i tagged values:

SOSI_navn: IDENT

Navn:

oppdateringsdato

Definisjon:

tidspunkt for siste endring på objektet

Merknad FKB: Denne datoen viser datasystemets siste endring på dataobjektet. Egenskapen settes av forvaltningssystemet etter følgende regler:

i. Oppdateringsdato er tidspunkt for oppdatering av databasen og settes av forvaltningsbasen (ikke av klienten).

ii. Oppdateringsdato skal endres også hvis det er kopidata som blir endret eller importert i en ”kopibase”.

iii. Når avgrensingslinjene til en flate endres, skal flateobjektet få ny oppdateringsdato.

iv. Oppdateringsdato skal endres hvis en egenskap endres.

Multiplisitet:

[1..1]

Type:

DateTime

Profilparametre i tagged values:

SOSI_datatype: DATOTID
SOSI_navn: OPPDATERINGSDATO

Navn:

sluttdato

Definisjon:

Tid for når denne versjonen av objektet var erstattet eller opphørt å eksistere.

Merknad FKB:

Egenskapen settes av forvaltningssystemet. Sluttdato skal kun sendes med ut fra forvaltningssystemet i sammenhenger der objektenes historikk er interessant.

Multiplisitet:

[0..1]

Type:

DateTime

Profilparametre i tagged values:

SOSI_datatype: DATOTID
SOSI_navn: SLUTTDATO

Navn:

datafangstdato

Definisjon:

dato når objektet siste gang ble registrert/observert/målt i terrenget

Multiplisitet:

[1..1]

Type:

Date

Profilparametre i tagged values:

SOSI_datatype: DATO
SOSI_navn: DATAFANGSTDATO

Navn:

verifiseringsdato

Definisjon:

dato når dataene er fastslått å være i samsvar med virkeligheten.

Merknad FKB: Brukes for eksempel i de sammenhenger hvor det er foretatt fotogrammetrisk ajourhold, og hvor det ikke er registrert endringer på objektet (det virkelige objektet er i samsvar med dataobjektet)

Multiplisitet:

[0..1]

Type:

Date

Profilparametre i tagged values:

SOSI_datatype: DATO
SOSI_navn: VERIFISERINGSDATO

Navn:

registreringsversjon

Definisjon:

angivelse av hvilken produktspesifikasjon som er utgangspunkt for dataene

Multiplisitet:

[0..1]

Type:

«CodeList» Registreringsversjon

Profilparametre i tagged values:

defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/registreringsversjon
SOSI_datatype: T
SOSI_lengde: 10
SOSI_navn: REGISTRERINGSVERSJON

Navn:

informasjon

Definisjon:

generell opplysning.

Merknad FKB:

Mulighet til å legge inn utfyllende informasjon om objektet. Egenskapen bør bare brukes til å legge inn ekstra informasjon om enkeltobjekter. Egenskapen bør ikke brukes til å systematisk angi ekstrainformasjon om mange/alle objekter i et datasett.

Multiplisitet:

[0..1]

Type:

CharacterString

Arv og realiseringer

Subtyper:

«FeatureType» KvalitetOpsjonell
«FeatureType» KvalitetPåkrevd

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Fellesegenskaper

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt


7.2.1.2. «FeatureType» KvalitetPåkrevd (abstrakt)

Definisjon:

Egenskaper

Navn:

kvalitet

Definisjon:

beskrivelse av kvaliteten på stedfestingen

Merknad: Denne er identisk med ..KVALITET i tidligere versjoner av SOSI.

Multiplisitet:

[1..1]

Type:

«dataType» Posisjonskvalitet

Profilparametre i tagged values:

SOSI_navn: KVALITET

Arv og realiseringer

Supertype:

«FeatureType» Fellesegenskaper

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt


7.2.1.3. «FeatureType» KvalitetOpsjonell (abstrakt)

Definisjon:

Egenskaper

Navn:

kvalitet

Definisjon:

beskrivelse av kvaliteten på stedfestingen

Merknad: Denne er identisk med ..KVALITET i tidligere versjoner av SOSI.

Multiplisitet:

[0..1]

Type:

«dataType» Posisjonskvalitet

Profilparametre i tagged values:

SOSI_navn: KVALITET

Arv og realiseringer

Supertype:

«FeatureType» Fellesegenskaper

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt


7.2.1.4. «dataType» Identifikasjon

Definisjon: Unik identifikasjon av et objekt i et datasett, forvaltet av den ansvarlige produsent/forvalter, og kan benyttes av eksterne applikasjoner som stabil referanse til objektet.

Merknad 1: Denne objektidentifikasjonen må ikke forveksles med en tematisk objektidentifikasjon, slik som f.eks bygningsnummer.

Merknad 2: Denne unike identifikatoren vil ikke endres i løpet av objektets levetid, og ikke gjenbrukes i andre objekt.

Profilparametre i tagged values

SOSI_navn

IDENT

Egenskaper

Navn:

lokalId

Definisjon:

lokal identifikator av et objekt

Merknad: Det er dataleverendørens ansvar å sørge for at den lokale identifikatoren er unik innenfor navnerommet. For FKB-data benyttes UUID som lokalId.

Multiplisitet:

[1..1]

Type:

CharacterString

Profilparametre i tagged values:

SOSI_datatype: T
SOSI_lengde: 100
SOSI_navn: LOKALID

Navn:

navnerom

Definisjon:

navnerom som unikt identifiserer datakilden til et objekt, anbefales å være en http-URI

Eksempel: http://data.geonorge.no/SentraltStedsnavnsregister/1.0

Merknad : Verdien for navnerom vil eies av den dataprodusent som har ansvar for de unike identifikatorene og må være registrert i data.geonorge.no eller data.norge.no

Multiplisitet:

[1..1]

Type:

CharacterString

Profilparametre i tagged values:

SOSI_datatype: T
SOSI_lengde: 100
SOSI_navn: NAVNEROM

Navn:

versjonId

Definisjon:

identifikasjon av en spesiell versjon av et geografisk objekt (instans)

Multiplisitet:

[0..1]

Type:

CharacterString

Profilparametre i tagged values:

SOSI_datatype: T
SOSI_lengde: 100
SOSI_navn: VERSJONID

Arv og realiseringer

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Identifikasjon


7.2.1.5. «dataType» Posisjonskvalitet

Definisjon: beskrivelse av kvaliteten på stedfestingen.

Merknad: Posisjonskvalitet er ikke konform med kvalitetsmodellen i ISO slik den er defineret i ISO19157:2013, men er en videreføring av tidligere brukte kvalitetsegenskaper i SOSI. FKB 5.0 innfører en egen variant av datatypen Posisjonskvalitet der kodeliste målemetode er byttet ut med den mer generelle kodelista Datafangstmetode.

Profilparametre i tagged values

SOSI_navn

KVALITET

Egenskaper

Navn:

datafangstmetode

Definisjon:

metode for datafangst. Egenskapen beskriver datafangstmetode for grunnrisskoordinater (x,y), eller for både grunnriss og høyde (x,y,z) dersom det ikke er oppgitt noen verdi for datafangstmetodeHøyde.

Multiplisitet:

[1..1]

Type:

«CodeList» Datafangstmetode

Profilparametre i tagged values:

defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode
SOSI_datatype: T
SOSI_lengde: 3
SOSI_navn: DATAFANGSTMETODE

Navn:

nøyaktighet

Definisjon:

standardavviket til posisjoneringa av objektet oppgitt i cm

I de aller fleste sammenhenger benyttes en anslått eller forventet verdi for standardavvik, men dersom man har en beregnet verdi skal denne benyttes.

For objekter med punktgeometri benyttes verdi for punktstandardavvik. For objekter med kurvegeometri benyttes standardavviket for tverravviket fra kurva. For objekter med overflate- eller volumgeometri er forståelsen at standardavviket beregnes ut fra (3D) avvikene mellom sann posisjon og nærmeste punkt på overflata.

Merknad:

Verdien er ment å beskrive nøyaktigheten til objektet sammenlignet med sann verdi. Standardavvik er i utgangspunktet et mål på det tilfeldige avviket og det innebærer at vi forutsetter at det systematiske avviket i liten grad påvirker nøyaktigheten til posisjoneringa. For fotogrammetriske data settes som hovedregel verdien lik kravet til standardavvik ved datafangst. Se standarden Geodatakvalitet for nærmere definisjon av standardavvik og hvordan dette defineres, beregnes og kontrolleres.

Multiplisitet:

[0..1]

Type:

Integer

Profilparametre i tagged values:

SOSI_datatype: H
SOSI_lengde: 6
SOSI_navn: NØYAKTIGHET

Navn:

synbarhet

Definisjon:

beskrivelse av hvor godt objektene framgår i datagrunnlaget for posisjonering (f.eks. flybildene).

Multiplisitet:

[0..1]

Type:

«CodeList» Synbarhet

Profilparametre i tagged values:

defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/synbarhet
SOSI_datatype: H
SOSI_lengde: 1
SOSI_navn: SYNBARHET

Navn:

datafangstmetodeHøyde

Definisjon:

metoden brukt for høyderegistrering av posisjon.

Det er bare nødvending å angi en verdi for egenskapen dersom datafangstmetode for høyde avviker fra datafangstmetode for grunnriss.

Multiplisitet:

[0..1]

Type:

«CodeList» Datafangstmetode

Profilparametre i tagged values:

defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode
SOSI_datatype: T
SOSI_lengde: 3
SOSI_navn: DATAFANGSTMETODEHØYDE

Navn:

nøyaktighetHøyde

Definisjon:

standardavviket til posisjoneringa av objektet oppgitt i cm

I de aller fleste sammenhenger benyttes en anslått eller forventet verdi for standardavvik, men dersom man har en beregnet verdi skal denne benyttes.

For objekter med punktgeometri benyttes verdi for punktstandardavvik. For objekter med kurvegeometri benyttes standardavviket for tverravviket fra kurva. For objekter med overflate- eller volumgeometri er forståelsen at standardavviket beregnes ut fra (3D) avvikene mellom sann posisjon og nærmeste punkt på overflata.

Merknad:

Verdien er ment å beskrive nøyaktigheten til objektet sammenlignet med sann verdi. Standardavvik er i utgangspunktet et mål på det tilfeldige avviket og det innebærer at vi forutsetter at det systematiske avviket i liten grad påvirker nøyaktigheten til posisjoneringa. For fotogrammetriske data settes som hovedregel verdien lik kravet til standardavvik ved datafangst. Se standarden Geodatakvalitet for nærmere definisjon av standardavvik og hvordan dette defineres, beregnes og kontrolleres.

Multiplisitet:

[0..1]

Type:

Integer

Profilparametre i tagged values:

SOSI_datatype: H
SOSI_lengde: 6
SOSI_navn: H-NØYAKTIGHET

Restriksjoner

Navn:

ugyldige datafangstmetoder for høyde

Beskrivelse:

inv: self.datafangstmetodeHøyde <> 'dig'

--Datafangstmetode Digitalisert skal ikke brukes på egenskapen datafangstmetodeHøyde

Arv og realiseringer

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Posisjonskvalitet


7.2.1.6. «CodeList» Synbarhet

Definisjon: synbarhet beskriver hvor godt objektene framgår i datagrunnlaget for posisjonering (f.eks. flybildene).

Profilparametre i tagged values

asDictionary

true

codeList

https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/synbarhet

SOSI_datatype

H

SOSI_lengde

1

SOSI_navn

SYNBARHET


7.2.1.7. «CodeList» Datafangstmetode

Definisjon: metode for datafangst.

Datafangstmetoden beskriver hvordan selve vektordataene er posisjonert fra et datagrunnlag (observasjoner med landmålingsutstyr, fotogrammetrisk stereomodell, digital terrengmodell etc.) og ikke prosessen med å innhente det bakenforliggende datagrunnlaget.

Profilparametre i tagged values

asDictionary

true

codeList

https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode

SOSI_datatype

T

SOSI_lengde

3

SOSI_navn

DATAFANGSTMETODE


7.2.1.8. «CodeList» Registreringsversjon

Definisjon: FKB-verjson som ligger til grunn for registrering. Mest relevant for data som er fotogrammetrisk registrert.

Profilparametre i tagged values

asDictionary

true

codeList

https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/registreringsversjon

SOSI_datatype

T

SOSI_lengde

10

SOSI_navn

REGISTRERINGSVERSJON


7.2.1.9. «CodeList» Høydereferanse

Definisjon: koordinatregistering utført på topp eller bunn av et objekt

Profilparametre i tagged values

asDictionary

true

codeList

https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/hoydereferanse

SOSI_datatype

T

SOSI_lengde

6

SOSI_navn

HREF


7.2.1.10. «CodeList» Medium

Definisjon: objektets beliggenhet i forhold til jordoverflaten

Eksempel: Veg på bro, i tunnel, inne i et bygningsmessig anlegg, etc.

Profilparametre i tagged values

asDictionary

true

codeList

https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/medium

SOSI_datatype

T

SOSI_lengde

1

SOSI_navn

MEDIUM


7.2.2. Pakke: Elementer til bruk i distribusjon

Definisjon: Pakke med elementer som kan benyttes i applikasjonsskjema for distribusjon av FKB-data/FKB-produkter


Hoveddiagram Mekanismer til bruk i distribusjon
Figur 14. Hoveddiagram Mekanismer til bruk i distribusjon

Realisering av elementer fra SOSI Generell del
Figur 15. Realisering av elementer fra SOSI Generell del

7.2.2.1. «FeatureType» EkstraegenskaperDistribusjon (abstrakt)

Definisjon: Inneholder ekstraegenskaper som er aktuelle i forbindelse med distribusjon

Egenskaper

Navn:

kopidata

Definisjon:

angivelse av at objektet er hentet fra et kopidatasett og ikke fra originaldatasettet

Merknad: Inneholder informasjon om når kopidatasettet ble kopiert fra originaldatasettet og hvem som er originaldataansvarlig

Multiplisitet:

[0..1]

Type:

«dataType» Kopidata

Profilparametre i tagged values:

SOSI_navn: KOPIDATA

Arv og realiseringer

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt


7.2.2.2. «featureType» KantUtsnitt

Definisjon: avgrensning av et utsnitt. KantUtsnitt lagres ikke i forvaltningsbasen men kan benyttes for å lage komplette flateavgrensninger ved klipping av et område ut fra forvaltningsbasen. KantUtsnitt kan finnes i fileksporter.

Egenskaper

Navn:

grense

Definisjon:

forløp som følger overgang mellom ulike fenomener

Multiplisitet:

[1..1]

Type:

«dataType» Kurve

Navn:

identifikasjon

Definisjon:

Unik identifikasjon av objektet

Multiplisitet:

[0..1]

Type:

«dataType» Identifikasjon

Arv og realiseringer

Realisering av:

«ApplicationSchema» Generelle typer 5.1/Objekttyper med tydelige fellestrekk/Avgrensningslinjer::«FeatureType» KantUtsnitt


7.2.2.3. «dataType» Kopidata

Definisjon: angivelse av at objektet er hentet fra en kopi av originaldata

Merknad: Kan benyttes dersom man gjør et uttak av en database som ikke inneholder originaldataene.

Profilparametre i tagged values

SOSI_navn

KOPIDATA

Egenskaper

Navn:

områdeId

Definisjon:

identifikasjon av område som dataene dekker

Merknad: Kan angis med kommunenummer eller fylkesnummer. Disse bør spesifiseres nærmere.

Multiplisitet:

[1..1]

Type:

Integer

Profilparametre i tagged values:

SOSI_datatype: H
SOSI_lengde: 4
SOSI_navn: OMRÅDEID

Navn:

originalDatavert

Definisjon:

ansvarlig etat for forvaltning av data

Multiplisitet:

[1..1]

Type:

CharacterString

Profilparametre i tagged values:

SOSI_datatype: T
SOSI_lengde: 50
SOSI_navn: ORIGINALDATAVERT

Navn:

kopidato

Definisjon:

dato når objektet ble kopiert fra originaldatasettet

Merknad: Er en del av egenskapen Kopidata. Brukes i de tilfeller hvor en kopidatabase brukes til distribusjon. Å kopiere et datasett til en kopidatabase skal ikke føre til at Oppdateringsdato blir endret. Eventuell redigering av data i et kopidatasett medfører ny Oppdateringsdato, Datafangstdato og/eller Verifiseringsdato.

Multiplisitet:

[1..1]

Type:

DateTime

Profilparametre i tagged values:

SOSI_datatype: DATOTID
SOSI_navn: KOPIDATO

Arv og realiseringer

Realisering av:

«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Kopidata

8. Kvalitet

8.1. Kvalitet på FKB-data

FKB data oppdateres gjennom forskjellige prosesser og det er et overordnet prinsipp at fullstendighet prioriteres framfor homogen stedfestingsnøyaktighet. FKB-data er en blanding av data med ulike datakilder og kvalitet. Et resultat av dette er at det er vanskelig å garantere stedfestingsnøyaktigheten til FKB-data innenfor et område. For å ha full kontroll på kvaliteten på FKB-dataene i en leveranse må man derfor se på kvalitetskodingen (metadata) på det enkelte objekt. Kravene til kvalitet på FKB settes ved datafangst.

Fotogrammetri er fortsatt den dominerende datakilden. For de fleste FKB-datasett har over 99% av kartobjektene fotogrammetri som datafangsmetode. Ved fotogrammetrisk datafangst settes det klare krav til kvaliteten og det utføres kontroll. Ambisjonen er at FKB-dataene skal ha en så god og homogen kvalitet som mulig og det jobbes for å sette tilsvarende krav til dataene også ved andre typer datafangst.

8.2. Kvalitetselementer som benyttes for å sette krav til FKB-data

I dette avsnittet er det angitt hvilke kvalitetselementer som skal benyttes i spesifikasjoner for datafangst av FKB-data. Kvalitetselementene er hentet fra Geodatakvalitet [G] og det henvises til denne standarden for nærmere beskrivelse av de ulike kvalitetselementene og kvalitetsmålene, og for prinsipper for kontroll av kravene i en leveranse.

I enkelte sammenhenger kan det også være behov for å sette krav til FKB-dataene som ikke lar seg beskrive av kvalitetsmålene som er definert i Geodatakvalitet. I slike sammenhenger må det i såfall utarbeides egne kvalitetsmål (dvs. beskrives detaljert hva kravet går ut på og hvordan det skal kontrolleres). Dette kan være spesifikke krav til topologisk konsistens eller lignende.

I FKB er det kun kvalitetselementet stedfestingsnøyaktighet med tilhørende datafangstmetode, samt datering som obligatorisk skal ligge i selve dataene. Informasjon om øvrige kvalitetselementer vil normalt finnes i kontrollrapporter for det enkelte kartleggingsprosjekt eller som metadatainformasjon.

Tabell 7. Kategori: Stedfestingsnøyaktighet
Kvalitetselement Kvalitetsmål Referanse

Grunnrissnøyaktighet

Grove feil (%)

Geodatakvalitet:2014/301/1

Grunnrissnøyaktighet

Systematiske feil (m)

Geodatakvalitet:2014/303/1

Grunnrissnøyaktighet

Standardavvik (m)

Geodatakvalitet:2014/304/1

høydenøyaktighet

Grove feil (%)

Geodatakvalitet:2014/301/1

høydenøyaktighet

Systematiske feil (m)

Geodatakvalitet:2014/302/1

høydenøyaktighet

Standardavvik (m)

Geodatakvalitet:2014/304/1

Ved kontroll av stedfestingsnøyaktighet må man alltid kontrollere både standardavvik, systematiske avvik og andel grove feil mot en fasit [G].

Tabell 8. Kategori: Logisk konsistens
Kvalitetselement Kvalitetsmål Referanse Kommentar

Domenekonsistens

Antall enheter som ikke er i samsvar med domenet

NS-EN ISO19157:2013/016/1

Objekttyper, egenskaper og egenskapsverdier skal være i tråd med datamodellen. Kontrolleres f.eks. ved GML-validering eller SOSI-kontroll

Konseptuell konsistens

Antall enheter der regler i konseptuelt skjema ikke er oppfylt

NS-EN ISO19157:2013/010/1

Må spesifiseres nærmere hvilke krav i det konseptuelle skjemaet som skal oppfylles dersom kvalitetsmålet skal benyttes.

Topologisk konsistens

Antall ulovlige løse ender

Geodatakvalitet:2014/201/1

Må spesifiseres nærmere hva som regnes som en ulovlig løs ende dersom kvalitetsmålet skal benyttes

Topologisk konsistens

Antall feil i lenkekryssing

Geodatakvalitet:2014/202/1

Må spesifiseres nærmere hvilke typer lenkekryssinger som regnes som feil dersom kvalitetsmålet skal benyttes

Topologisk konsistens

Antall ulovlige egenoverlappinger

NS-EN ISO19157:2013/027/1

Kvalitetsmål som generelt kan settes til objekter med kurvegeometri

Topologisk konsistens

Antall ulovlige egenkryssinger

NS-EN ISO19157:2013/026/1

Kvalitetsmål som kan settes til objekter med kurvegeometri som inngår i flateavgrensninger

Topologisk konsistens

Antall ulovlige småpolygoner

NS-EN ISO19157:2013/025/1

Må spesifiseres nærmere hvilke typer småpolygoner som regnes som feil dersom kvalitetsmålet skal benyttes

Topologisk konsistens

Prosentandel feil på fulldekkende flater

Geodatakvalitet:2014/204/1

Kvalitetsmål som er aktuelt på objekttyper som skal utgjøre en heldekkende flate i et område

For alle kvalitetsmål som måler «antall avvik» på logisk konsistens er det naturlig at kravet settes til 0 dersom kvalitetsmålet anvendes.

Tabell 9. Kategori: Egenskapskonsistens
Kvalitetselement Kvalitetsmål Referanse

Klassifikasjonsriktighet

Prosentandel feil klassifiserte egenskaper

Geodatakvalitet:2014/508/1

Tabell 10. Kategori: Fullstendighet
Kvalitetselement Kvalitetsmål Referanse

Manglende objekter

Prosentandel manglende objekter

Geodatakvalitet:2014/102/1

Overskytende objekter

Prosentandel overskytende objekter

Geodatakvalitet:2014/101/1

Når man setter krav til datakvalitet i fotogrammetrisk registreringsinstruks og andre spesifikasjoner for datafangst av FKB-data skal det alltid settes krav til stedfestingskvalitet, egenskapskvalitet og fullstendighet ved hjelp av alle kvalitetsmålene som er definert i tabellene over. For logisk konsistens er flere av kvalitetsmålene av en slik natur at det må spesifiseres nærmere hvilke typer situasjoner som regnes som et avvik. Her må det gjøres et valg av hvilke kvalitetsmål som skal anvendes og ev. en nærmere spesifisering av hva som ligger i kravene i den enkelt spesifikasjon.

8.3. Krav til stedfestingsnøyaktighet - inndeling i klasser

For å angi krav til stedfestingsnøyaktighet er det definert fire klasser som objekttypene er inndelt i. Inndelingen i klasser bygger på hvor skarpt objekttypen er definert i terrenget. Denne inndelingen i nøyaktighetsklasser benyttes gjennomgående for alle datasett som inngår i fotogrammetrisk FKB og kan også anvendes som utgangspunkt for å sette krav til innsamling av FKB-data med andre metoder. For å få en oversikt over hvilke krav som gjelder for ulike objekttyper henvises det til spesifikasjonen av det enkelte FKB-datasett.

Tabell 11. Oversikt over krav til stedfestingsnøyaktighet (systematisk avvik / standardavvik ) for ulike nøyaktighetsklasser i de ulike FKB-standardene

FKB-Standard

Nøyaktighetsklasser

Klasse 1

Svært veldefinerte detaljer (cm)

Klasse 2

Veldefinerte detaljer (cm)

Klasse 3

Uskarpe detaljer (cm)

Klasse 4

Diffuse detaljer (cm)

FKB-A

Grunnriss

3 / 10

5 / 15

10 / 35

15 / 55

Høyde

3 / 10

5 / 15

8 / 25

12 / 40

FKB-B

Grunnriss

5 / 15

6 / 20

10 / 35

15 / 55

Høyde

5 / 15

6 / 20

10 / 35

15 / 50

FKB-C/D

Grunnriss

15 / 48

15 / 55

20 / 70

30 / 100

Høyde

15 / 48

20 / 70

25 / 90

40 / 150

I tidligere versjoner av FKB har det ikke blitt definert egne krav til systematiske avvik. Det har i stedet blitt beskrevet at «systematiske avvik ikke skal trekkes fra ved beregning av standardavvik» noe som avviker fra definisjonen av standardavvik. Tidligere bruk av «standardavvik» i FKB har lignet mer på begrepet RMS etter definisjon i Geodatakvalitet.

For å kunne følge standarden Geodatakvalitet fullt ut ved kontroll av data innføres fra FKB 5.0 eksplisitte krav til både systematiske avvik og standardavvik (se tabell 5). Kravene til systematiske avvik er satt slik at de maksimalt er 1/3 av krav til standardavvik. Kravene til systematisk avvik er basert på erfaringstall, samt at det sikrer at det systematiske avviket bare vil utgjøre en liten andel av det totale avviket mellom sann posisjon og målt posisjon. Kravet til standardavvik brukes derfor alene som et mål på dataenes nøyaktighet i metadataene.

Krav til grove feil

Grove feil regnes som avvik større enn 3 ganger krav til standardavviket angitt i tabellen over. Kravet vil vanligvis være maksimalt 1 % grove feil, men kan variere for ulike objekttyper og angis i den enkelte FKB produktspesifikasjon.

8.4. Avvik funnet ved kontroll av FKB-data

Produktspesifikasjon AvvikKartdata 1.0 spesifiserer hvordan avvik på kartdata skal utveksles. I forbindelse med utveksling av avvik knyttet til FKB-data i FKB-Kartleggingsprosjekter eller andre sammenhenger skal denne produktspesifikasjonen legges til grunn.

Vedlegg A: Utvekslingsformater for FKB-data

FKB 5.0 er laget spesielt med tanke på utveksling på GML-format [SOSI-GML] og SOSI-format [SOSI-FORMAT]. Alle FKB 5.0-data kan konverteres fram og tilbake mellom SOSI-format og GML-format uten at man mister informasjon.

I tillegg er ESRI fgdb et populært format for filbasert distribusjon gjennom geonorge og JSON [JSON] er et populært format ved jobbing mot Sentral FKB med NGIS-OpenAPI [NGIS]. For ESRI fgdb og JSON-formatene finnes det ikke standarder som beskriver krav til utvekslingsformatet i detalj.

A.1. Leveranseformater ved distribusjon fra Geonorge

Tabell 12. Liste over tilgjengelige filformater for nedlasting av FKB-data fra Geonorge.no
Format Inndeling Koordinatsystem Tegnsett Språk

GML 3.2.1

Kommunevise filer

Euref89 UTM33 + lokal sone

UTF-8

nor

SOSI-format 5.0

Kommunevise filer

Euref89 UTM33 + lokal sone

UTF-8

nor

ESRI fgdb

Kommunevise filer

Euref89 UTM33 + lokal sone

UTF-8

nor

ESRI fgdb

Landsdekkende + fylkesvise filer

Euref89 UTM33

UTF-8

nor

A.2. Formater i NGIS-OpenAPI

NGIS-OpenAPI er det nye og fleksible API-et for oppdatering av (blant annet) FKB-data [NGIS].

I NGIS-OpenAPI benyttes enten GML-format eller JSON-format for dataoverføring. GML-formatet er på samme måte som GML-filer ved distribusjon gitt av GML-Schema for produktspesifikasjonene og pakkes inn i WFS-T transaksjoner [WFS]. Dette er samme type dataformat som også brukes i Geosynkronisering-API.

Alternativt kan JSON-format benyttes i NGIS-OpenAPI. Dette formatet er basert på GeoJSON RFC 7946, august 2016 med utvidelser. Et programbibliotek som kan tolke GeoJSON vil også kunne lese dataene som utveksles med NGIS-OpenAPI, men vil ikke uten videre kunne tolke innholdet i utvidelsene. Utvidelsene brukes til f.eks. å utveksle informasjon om assosiasjoner, flatereferanser ved delt geometri og action ved oppdateringer (insert/replace/erase). Se dokumentasjon av NGIS-OpenAPI for eksempler på filformat ved bruk av API-et.

Vedlegg B: Romlige referansesystem

FKB-data er detaljerte data med høy presisjon. Dette betyr at man må være bevisst på ev. feil som kan innføres ved transformasjon av dataene mellom forskjellige romlige referansesystemer. I forvaltningen av FKB-data gjøres vanligvis oppdateringen direkte i den aktuelle kommunens koordinatsystem slik at man unngår transformasjon av data. Kommuner i tidligere Finnmark fylke har EUREF89 UTM35 som lokal sone. Kommuner i Nordland og tidligere Troms har EUREF89 UTM33 som lokal sone, mens kommuner fra Trøndelag og sørover bruker EUREF89 UTM32 som lokal sone.

Dersom det skal tillates oppdatering med transformasjon inn i FKB-dataene må det benyttes en transformasjon som gir presisjon bedre enn oppløsningen i FKB-dataene (i praksis bedre en 5 mm).

Tabell 13. Liste over romlige referansesystem som benyttes i forvaltningen av FKB
Referansesystem EPSG-kode (GML/JSON-format) SOSI-kode (SOSI-format)

EUREF89 UTM32 (2d)

25832

Koordsys 22, Vert-datum ikke angitt

EUREF89 UTM33 (2d)

25833

Koordsys 23, Vert-datum ikke angitt

EUREF89 UTM35 (2d)

25835

Koordsys 25, Vert-datum ikke angitt

EUREF89 UTM32 + NN2000

5972

Koordsys 22, Vert-datum NN2000

EUREF89 UTM33 + NN2000

5973

Koordsys 23, Vert-datum NN2000

EUREF89 UTM35 + NN2000

5975

Koordsys 25, Vert-datum NN2000

Ved distribusjon kan dataene transformeres til en rekke andre referansesystemer ved help av standard transformasjonsbiblioteker.

Vedlegg C: Assosiasjoner og flategeometri på SOSI- og GML-format

Generelt gjelder SOSI del 1 Realisering av GML-format 5.0 [SOSI-GML] og Realisering av SOSI-format 5.0 [SOSI-FORMAT] ved utveksling av FKB-data. I FKB 5.0 innføres Assosiasjoner og endringer i håndtering av Flategeometri. Dette vedlegget inneholder detaljer om hvordan dette skal utveksles på SOSI- og GML-format inkludert korte eksempler.

C.1. Utveksling av assosiasjoner

C.1.1. SOSI-format

I SOSI-formatet utveksles assosiasjoner med referanser til SOSI-gruppenummer (altså kun unikt innenfor SOSI-fila).

Eksempel på assosiasjon på SOSI-format. Referanse fra Maste-objekt til SOSI-gruppenummer for Bardun-objekt ("..BARDUN :1").
  .KURVE 1:
  ..OBJTYPE Bardun
  ..IDENT
  ...LOKALID "5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d"
  ...NAVNEROM "http://data.geonorge.no/SFKB/50/FKB-Ledning/so"
  ...VERSJONID "2021-09-24 11:51:54.015000"
  ..OPPDATERINGSDATO 20210929133801
  ..DATAFANGSTDATO 20210924
  ..VERIFISERINGSDATO 20210924
  ..REGISTRERINGSVERSJON 2022-01-01
  ..INFORMASJON "Dette er fiktive eksempeldata"
  ..HREF TOP
  ..MEDIUM T
  ..KVALITET
  ...DATAFANGSTMETODE fot
  ...NØYAKTIGHET 120
  ...SYNBARHET 0
  ...DATAFANGSTMETODEHØYDE fot
  ...H-NØYAKTIGHET 200
  ..DRIFTSMERKING "ABCD1234"
  ..EIERORGNR "234567891"
  ..EKSTERNPEKER https://enangitturl/geografiskobjekt/5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d
  ..LEDNINGSNETTVERKSTYPE ekom
  ..NØH
  7034142346 567181215 43670
  7034142346 567189494 65130
  .PUNKT 2:
  ..OBJTYPE Mast
  ..IDENT
  ...LOKALID "81ffc802-3e9f-492b-95b6-bb15b645a7e8"
  ...NAVNEROM "http://data.geonorge.no/SFKB/50/FKB-Ledning/so"
  ...VERSJONID "2021-09-24 11:51:54.015000"
  ..OPPDATERINGSDATO 20210929133801
  ..DATAFANGSTDATO 20210924
  ..VERIFISERINGSDATO 20210924
  ..REGISTRERINGSVERSJON 2022-01-01
  ..INFORMASJON "Dette er fiktive eksempeldata"
  ..HREF TOP
  ..MEDIUM T
  ..KVALITET
  ...DATAFANGSTMETODE fot
  ...NØYAKTIGHET 30
  ...SYNBARHET 0
  ...DATAFANGSTMETODEHØYDE fot
  ...H-NØYAKTIGHET 110
  ..DRIFTSMERKING "ABCD1234"
  ..EIERORGNR "234567891"
  ..EKSTERNPEKER https://enangitturl/geografiskobjekt/81ffc802-3e9f-492b-95b6-bb15b645a7e8
  ..LEDNINGSNETTVERKSTYPE lavspentnett
  ..ANTALL_LASERPUNKT 55
  ..BELYSNING JA
  ..MASTEKONSTRUKSJON enkelStolpe
  ..LINJEBREDDE 0.23
  ..VERTIKALAVSTAND 8.23
  ..BARDUN :1
  ..NØH
  7034127981 567190174 126900

C.1.2. GML-format

I GML-formatet utveksles assosiasjoner med mekanismen xlink:href på objektet det pekes fra til GML-Id på objektet det pekes til. GML-Id skal i FKB utformes etter konvensjonen «objekttypenavn_lokalid» slik at denne er unik/meningsfull også på utsiden av GML-fila.

Eksempel på assosiasjon på GML-format. Referanse fra Maste-objekt til GML-id for Bardun-objekt ("<app:bardun xlink:href="#Bardun_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d" />")
<gml:featureMembers>
<gml:featureMember>
    <app:Bardun gml:id="Bardun_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d">
      <app:identifikasjon>
        <app:Identifikasjon>
          <app:lokalId>5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:lokalId>
          <app:navnerom>http://data.geonorge.no/SFKB/50/FKB-Ledning/so</app:navnerom>
        </app:Identifikasjon>
      </app:identifikasjon>
      <app:oppdateringsdato>2021-09-24T10:41:12</app:oppdateringsdato>
      <app:datafangstdato>2021-09-24</app:datafangstdato>
      <app:verifiseringsdato>2021-09-24</app:verifiseringsdato>
      <app:registreringsversjon>2022-01-01</app:registreringsversjon>
      <app:informasjon>Dette er fiktive eksempeldata</app:informasjon>
      <app:høydereferanse>TOP</app:høydereferanse>
      <app:medium>T</app:medium>
      <app:kvalitet>
        <app:Posisjonskvalitet>
          <app:datafangstmetode>fot</app:datafangstmetode>
          <app:nøyaktighet>120</app:nøyaktighet>
          <app:synbarhet>0</app:synbarhet>
          <app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
          <app:nøyaktighetHøyde>200</app:nøyaktighetHøyde>
        </app:Posisjonskvalitet>
      </app:kvalitet>
      <app:driftsmerking>ABCD1234</app:driftsmerking>
      <app:eierOrgNr>234567891</app:eierOrgNr>
      <app:eksternPeker>https://enangitturl/geografiskobjekt/5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:eksternPeker>
      <app:hovedbruk>ekom</app:hovedbruk>
      <app:senterlinje>
        <gml:Curve gml:id="geom_2a02c15b-0512-43e3-8ac8-55836ab84bba" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
          <gml:segments>
            <gml:LineStringSegment>
              <gml:posList>567181.346 7034142.215 43.670 567189.494 7034142.346 65.130</gml:posList>
            </gml:LineStringSegment>
          </gml:segments>
        </gml:Curve>
      </app:senterlinje>
    </app:Bardun>
</gml:featureMember>
<gml:featureMember>
   <app:Mast gml:id="Mast_81ffc802-3e9f-492b-95b6-bb15b645a7e8">
      <app:identifikasjon>
        <app:Identifikasjon>
          <app:lokalId>81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:lokalId>
          <app:navnerom>http://data.geonorge.no/SFKB/50/FKB-Ledning/so</app:navnerom>
        </app:Identifikasjon>
      </app:identifikasjon>
      <app:oppdateringsdato>2021-09-24T10:41:16.56</app:oppdateringsdato>
      <app:datafangstdato>2021-09-24</app:datafangstdato>
      <app:verifiseringsdato>2021-09-24</app:verifiseringsdato>
      <app:registreringsversjon>2022-01-01</app:registreringsversjon>
      <app:informasjon>Dette er fiktive eksempeldata</app:informasjon>
      <app:høydereferanse>TOP</app:høydereferanse>
      <app:medium>T</app:medium>
      <app:kvalitet>
        <app:Posisjonskvalitet>
          <app:datafangstmetode>fot</app:datafangstmetode>
          <app:nøyaktighet>30</app:nøyaktighet>
          <app:synbarhet>0</app:synbarhet>
          <app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
          <app:nøyaktighetHøyde>110</app:nøyaktighetHøyde>
        </app:Posisjonskvalitet>
      </app:kvalitet>
      <app:driftsmerking>ABCD1234</app:driftsmerking>
      <app:eierOrgNr>234567891</app:eierOrgNr>
      <app:eksternPeker>https://enangitturl/geografiskobjekt/81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:eksternPeker>
      <app:hovedbruk>lavspentnett</app:hovedbruk>
      <app:posisjon>
        <gml:Point gml:id="geom_acf77bef-c6de-4fbf-a5c0-2b5f0035f46j" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
          <gml:pos>567190.174 7034127.981 126.900</gml:pos>
        </gml:Point>
      </app:posisjon>
      <app:antallLaserPunkt>55</app:antallLaserPunkt>
      <app:belysning>true</app:belysning>
      <app:konstruksjon>enkelStolpe</app:konstruksjon>
      <app:linjebredde>0.23</app:linjebredde>
      <app:vertikalAvstand>8.23</app:vertikalAvstand>
      <app:bardun xlink:href="#Bardun_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d" />
    </app:Mast>
</gml:featureMember>
</gml:featureMembers>

C.2. Utveksling av flategeometri

C.2.1. SOSI-format

SOSI-formatet er bygget opp med referanser til avgrensningsobjektene i stedet for at flateobjektene inneholder selve geometrien. Flater med delt geometri ("Type 2") kan derfor utveksles som tradisjonelle SOSI .FLATE-objekter med flatereferanser (.REF). Om man ønsker å utveksle flater med heleid geometri ("Type 1") i SOSI så skal man etablere et "hjelpeobjekt" i form av en .KURVE-gruppe med objekttype Flateavgrensning (som ikke har noen identifikasjon/lokalid) som inneholder hele flateavgrensningen og refereres fra .FLATE-objektet. Dersom "Type 1"-flaten inneholder øyer/hull må det etableres egne Flateavgrensning SOSI-grupper også for disse som referes som hull etter vanlige regler for SOSI-formatet.

Eksempel på heleid flate på SOSI-format. Avgrensningsgeometrien for flata ligger i et eget Flateavgrensning-objekt (uten identifikasjon) som refereres fra flate-objektet. Flateobjektet i eksempelet har representasjonspunkt.
  .KURVE 1:
  ..OBJTYPE Flatevgrensning
  ..NØH
  6661981480 569544030 89200
  6662009490 569606410 91200
  6661998970 569625840 90800
  6662001850 569629640 91000
  6662054940 569635020 91500
  6662067850 569576330 90500
  6662054490 569566500 90500
  6661981480 569544030 89200
  .FLATE 2:
  ..OBJTYPE Anleggsområde
  ..IDENT
  ...LOKALID 58c892c4-f615-4317-935f-038765687265
  ...NAVNEROM "http://data.geonorge.no/SOSI/FKB-Arealbruk"
  ..OPPDATERINGSDATO "2021-08-26T21:08:00Z"
  ..DATAFANGSTDATO "2021-08-26"
  ..KVALITET
  ...DATAFANGSTMETODE "fot"
  ...NØYAKTIGHET "42"
  ...SYNBARHET "1"
  ...DATAFANGSTMETODEHØYDE "fot"
  ...H-NØYAKTIGHET "42"
  ..REF :1
  ..NØ
  6662024665 568494636
Eksempel på flate med delt geometri på SOSI-format. Flate-objektet inneholder kun representasjonspunkt og referanse til avgrensningsobjektene ("..REF :2 :-3")
  .FLATE 1:
  ..OBJTYPE Bygning
  ..IDENT
  ...LOKALID 5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d
  ...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
  ..REF :2 :-3
  ..NØH
  56844403 666198148 8920
  .KURVE 2:
  ..OBJTYPE Bygningsavgrensning
  ..IDENT
  ...LOKALID 81ffc802-3e9f-492b-95b6-bb15b645a7e8
  ...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
  ..NØH
  56852584 666199897 9080
  56850641 666200949 9120
  56844403 666198148 8920
  .KURVE 3:
  ..OBJTYPE Bygningsavgrensning
  ..IDENT
  ...LOKALID 32face7c-c0d8-4264-ac2d-1e47977cc976
  ...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
  ..NØH
  56852584 666199897 9080
  56852964 666200185 9100
  56853502 666205494 9150
  56847633 666206785 9050
  56846650 666205449 9050
  56844403 666198148 8920

C.2.2. GML-format

En "Type 1" flate vil i GML være rett fram å utveksle som en gml:Surface med heleid geometri. Om man skal utveksle en flate av "Type 2" i GML vil man også sende med flate-objektets komplette egengeometri som gml:Surface. I tillegg er det definert regler for hvordan referansene til de assosierte avgrensningsobjektene skal utveksles:

  1. Referanse fra flateobjekt til avgrensningsobjekt legges som en xlink:href på flateobjektet som peker på GML-Id for avgrensningsobjektet. Dette er i tråd med krav til - og erfaringer med - hvordan assosiasjoner utveksles på GML-formatet.

  2. GML-Id utformes etter konvensjonen «objekttypenavn_lokalid» slik at denne er unik/meningsfull også på utsiden av GML-fila.

  3. Informasjon om rekkefølge og retning på de assosierte avgrensningsobjektene legges inn ved bruk av taggen xlink:title. I tilfellene der dette er interessant forutsettes det at xlink:title formateres med 4 kolonner:

    • Kolonne 1: sekvensnummer til flate – 0 er første flate (høyere tall ved multisurface/multipolygon)

    • Kolonne 2: sekvensnummer til ring – ytre begrensing = 0, første hull = 1, osv.

    • Kolonne 3: sekvensnummer til kurve - 0 er første

    • Kolonne 4: retning + eller – (om avgrensningsobjektet skal nøstes med eller mot koordinatretningen)

Eksempel på heleid flate på GML-format. Geometrien ligger "inline" i objektet.
<gml:featureMembers>
  <gml:featureMember>
    <app:Anleggsområde gml:id="Anleggsområde_58c892c4-f615-4317-935f-038765687265">
      <app:identifikasjon>
        <app:Identifikasjon>
          <app:lokalId>58c892c4-f615-4317-935f-038765687265</app:lokalId>
          <app:navnerom>http://data.geonorge.no/SOSI/FKB-Arealbruk</app:navnerom>
        </app:Identifikasjon>
      </app:identifikasjon>
      <app:oppdateringsdato>2021-08-26T21:08:00</app:oppdateringsdato>
      <app:datafangstdato>2021-08-26</app:datafangstdato>
      <app:kvalitet>
        <app:Posisjonskvalitet>
          <app:datafangstmetode>fot</app:datafangstmetode>
          <app:nøyaktighet>42</app:nøyaktighet>
          <app:synbarhet>2</app:synbarhet>
          <app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
          <app:nøyaktighetHøyde>42</app:nøyaktighetHøyde>
        </app:Posisjonskvalitet>
      </app:kvalitet>
      <app:område>
        <gml:Polygon gml:id="1" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList>568444.03 6661981.48 89.2 568506.41 6662009.49 91.2 568525.84 6661998.97 90.8 568529.64 6662001.85 91 568535.02 6662054.94 91.5 568476.33 6662067.85 90.5 568466.5 6662054.49 90.5 568444.03 6661981.48 89.2</gml:posList>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </app:område>
    </app:Anleggsområde>
  </gml:featureMember>
</gml:featureMembers>
Eksempel på flate med delt geometri i på GML-format. Flate-geometrien ligger "inline" i objektet og i tillegg ligger det inne referanser til egne avgrensningsobjekter som en assosiasjon med spesielle regler ("<avgrensning xlink:title="0 0 0 -" xlink:href="#Bygningsavgrensning_81ffc802-3e9f-492b-95b6-bb15b645a7e8"/>"). Det er krav om samsvar mellom geometrien til flata og de refererte avgrensningsobjektene.
<gml:featureMembers>
   <gml:featureMember>
      <app:Bygning gml:id="Bygning_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d">
         <app:identifikasjon>
            <app:Identifikasjon>
               <app:lokalId>5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:lokalId>
               <app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
            </app:Identifikasjon>
         </app:identifikasjon>
         <app:område>
            <gml:Polygon gml:id="geom_1" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>568444.03 6661981.48 89.20 568506.41 6662009.49 91.20 568525.84 6661998.97 90.80 568529.64 6662001.85 91.00 568535.02 6662054.94 91.50 568476.33 6662067.85 90.50 568466.50 6662054.49 90.50 568444.03 6661981.48 89.20</gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
            </gml:Polygon>
         </app:område>
         <app:sentralpunkt>
            <gml:Point gml:id="geom_2" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
               <gml:pos>568497.68 6662024.15 90.67</gml:pos>
            </gml:Point>
         </app:sentralpunkt>
         <app:avgrensning xlink:title="0 0 0 -" xlink:href="#Bygningsavgrensning_81ffc802-3e9f-492b-95b6-bb15b645a7e8"/>
         <app:avgrensning xlink:title="0 0 1 +" xlink:href="#Bygningsavgrensning_32face7c-c0d8-4264-ac2d-1e47977cc976"/>
      </app:Bygning>
  </gml:featureMember>
  <gml:featureMember>
      <app:Bygningsavgrensning gml:id="Bygningsavgrensning_81ffc802-3e9f-492b-95b6-bb15b645a7e8">
         <app:identifikasjon>
            <app:Identifikasjon>
               <app:lokalId>81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:lokalId>
               <app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
            </app:Identifikasjon>
         </app:identifikasjon>
         <app:grense>
         <gml:Curve gml:id="geom_3" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
          <gml:segments>
            <gml:LineStringSegment>
               <gml:posList>568525.84 6661998.97 90.80 568506.41 6662009.49 91.20  568444.03 6661981.48 89.20</gml:posList>
            </gml:LineStringSegment>
	  </gml:segments>
         </gml:Curve>
         </app:grense>
      </app:Bygningsavgrensning>
  </gml:featureMember>
  <gml:featureMember>
      <app:Bygningsavgrensning gml:id="Bygningsavgrensning_32face7c-c0d8-4264-ac2d-1e47977cc976">
         <app:identifikasjon>
            <app:Identifikasjon>
               <app:lokalId>32face7c-c0d8-4264-ac2d-1e47977cc976</app:lokalId>
               <app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
            </app:Identifikasjon>
         </app:identifikasjon>
         <app:grense>
            <gml:Curve gml:id="geom_4" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
	    <gml:segments>
            <gml:LineStringSegment>
               <gml:posList>568525.84 6661998.97 90.80 568529.64 6662001.85 91.00 568535.02 6662054.94 91.50 568476.33 6662067.85 90.50 568466.50 6662054.49 90.50 568444.03 6661981.48 89.20</gml:posList>
            </gml:LineStringSegment>
	    </gml:segments>
         </gml:Curve>
         </app:grense>
      </app:Bygningsavgrensning>
   </gml:featureMember>
</gml:featureMembers>

Vedlegg D: Generelle retningslinjer for fotogrammetrisk registrering av FKB

D.1. Fotogrammetrisk nykonstruksjon

Ved fotogrammetrisk nykonstruksjon skal alle objektene som er spesifisert i registreringsinstruksen og som er synlige i flybildene registreres.

D.1.1. Registrering av nye kartobjekter

Hovedregelen er at påkrevde objekttyper registreres, mens opsjonelle objekttyper ikke registreres.

Unntak fra hovedregelen kan avtales i teknisk spesifikasjon for kartleggingsprosjektet.

D.1.2. Registrering av egenskaper på nye kartobjekter

Hovedregelen er at obligatoriske egenskaper registreres, mens opsjonelle egenskaper ikke registreres ved fotogrammetrisk datafangst.

Egenskaper som skal registreres/klassifiseres ved hjelp av fotogrammetri er beskrevet spesielt i registreringsinstruksen. Opsjonelle egenskaper som ikke er spesielt nevnt i registreringsinstruksen skal ikke registreres med mindre annet er spesielt angitt.

Følgende egenskaper håndteres spesielt:

  • Egenskapen Identifikasjon skal ikke legges inn på objektene

  • Egenskapen Oppdateringsdato skal ikke legges inn på objektene

  • Alle objekter skal ha egenskapene Nøyaktighet og NøyaktighetHøyde som del av datatypen Posisjonskvalitet

  • Alle objekter skal ha egenskapen Registreringsversjon

Unntak fra hovedreglene kan spesifiseres under den enkelte objekttype/egenskap i den enkelte registreringsinstruks eller i teknisk spesifikasjon for kartleggleggingsprosjektet.

Assosiasjoner håndteres ved fotogrammetrisk registrering av FKB-data på samme måte som opsjonelle egenskaper. Dvs. at det ikke skal etableres assosiasjoner i dataene dersom det ikke er spesielt beskrivet i den enkelte registreringsinstruks eller avtalt i kartleggingsprosjektet.

D.1.2.1. Kvalitet og datafangstdato

Alle objekter som registreres fotogrammetrisk skal merkes med kvalitet og datafangstdato.

I følge definisjonen av Datafangstdato skal dette være datoen for når flybildene som ligger til grunn for kartkonstruksjonen ble tatt (flyfotodato). I en del kartleggingsprosjekter kan imidlertid bildene være tatt på ulike datoer og det kan da være ønskelig at alle data i prosjektet likevel får samme dato. Dersom man ønsker å gjøre det på denne måten skal dette avklares i det enkelte prosjekt.

I FKB 5.0 er kun målemetode satt som påkrevd egenskap i datatypen «dataType» Posisjonskvalitet. Ved fotogrammetrisk regisrering skal imidlertid alltid også nøyaktighet og synbarhet registreres. Alle objekter som registreres fotogrammetrisk registreres med datafangstmetode fot.

I SOSI-formatet skal ingen egenskaper kompaktifiseres i FKB 5.0. Dette gjelder også posisjonskvalitet (dvs. at datafangstmetode, nøyaktighet etc. angis som egenskaper på 3-prikksnivå under ..KVALITET).

D.1.2.2. Obligatoriske egenskaper med kodelister

En del egenskaper med kodelister er angitt som påkrevde. Dette krever at det legges på en verdi ved fotogrammetrisk registrering. For slike egenskaper skal det være definert en "standardverdi" som benyttes i de tilfellene det ikke er angitt noe annet. Konkrete regler for hvordan dette skal registreres for de enkelte objekttyper/egenskaper skal være angitt i registreringsinstruksen. Egenskapene Medium og Høydereferanse (HREF) er benyttet på mange objekter i flere FKB-datasett og for disse gjelder følgende generelle regler dersom ikke annet er spesielt angitt:

Tabell 14. Registrering av verdier for egenskapen Medium der ikke annet er spesifisert
Kodeverdi Forklaring

T (på terrenget)

Standardverdi. Benyttes for alle objekter der det ikke er grunn til å benytte en annen verdi

U (under terrenget)

Objekter under bakken er generelt lite aktuelt for fotogrammetrisk registrering, men det kan likevel være aktuelt å benytte denne verdien for objekter (delvis) under bruer/bygninger/kulverter etc. der det ikke er direkte innsyn med fotogrammetri, men krav til gjennomgående registrering av objektet.

B (på bygning)

Benyttes for objekter på toppen av (på taket av) bygninger og ev. andre konstruksjoner.

L (i lufta)

Benyttes for generelt for objekter befinner seg lufta. Dette kan være objekter i en stolpe eller på en bru. Bruk er presisert for en del objekttyper.

Enkelte objekttyper kan ha spesielle beskrivelser av bruk av andre koder for Medium. F.eks. er det presisert at en Veranda på et tak (takterrasse) registreres med Medium B, mens en Veranda som henger på en vegg (balkong) registreres med Medium L.

Medium brukes i stor grad for å styre tegneregler for FKB-dataene. Altså slik at objekter med Medium U typisk ikke tegnes ut (ev. stiples), mens objekter med Medium L tegnes over/oppå andre objekter.

Tabell 15. Registrering av verdier for egenskapen Høydereferanse der ikke annet er spesifisert
Kodeverdi Forklaring

topp (toppen av objektet)

Standardverdi ved fotogrammetrisk registrering. For de fleste objekttyper er dette også presisert på objekttypen

fot (foten av objektet)

Benyttes ved fotogrammetrisk registrering kun for objekttyper der det er presisert at høydereferansen skal være foten av objektet eller terrenghøyde.

D.1.3. Egenskaper på flater med heleid geometri

For objekttyper som er modellert med heleid flategeometri (finnes f.eks. i Arealbruk, BygnAnlegg og Naturinfo) må egenskaper knyttet til geometrien som datafangstdato og kvalitet representere hele flateobjektet. Man har ikke som tidligere muligheten av å splitte avgrensningen og sette ulik kvalitet/dato på ulike deler av avgrensningen.

Dersom deler av (avgrensningen til) en flate har redusert kvalitet bør dette gjenspeiles på flatas kvalitetskoding. Ved ajourføring av en flate settes ny datafangstdato på flateobjektet.

D.2. Fotogrammetrisk ajourhold

Ved fotogrammetrisk ajourhold sender oppdragsgiver eksisterende data i henhold til FKB-produktspesifikasjon til oppdragstaker som grunnlag for ajourføring. FKB-dataene oppdateres der det har skjedd endringer slik at fullstendigheten i kartet skal bli tilsvarende som på fototidspunktet.

Merknad: Det forutsettes at eksisterende data oppfyller kravene til stedfestingsnøyaktighet gitt i produktspesifikasjonen. Dersom dette ikke er tilfelle kan det være vanskelig å gjøre en fornuftig ajourføring av dataene. Nykonstruksjon eller oppgradering bør da vurderes.

Fotogrammetrisk ajourhold innebærer i prinsippet følgende operasjoner:

  1. Registrere nye objekter der disse finnes i flybildene, men ikke i eksisterende data. Reglene som gjelder nye objekter ved Fotogrammetrisk nykonstruksjon skal da anvendes.

    • I en del situasjoner må eksisterende objekter splittes eller sammenføyes i forbindelse med fotogrammetrisk registrering. De generelle reglene for Unik identifikasjon av kartobjektene i FKB skal da legges til grunn.

  2. Verifisere at objekter som er registrert i eksisterende data fortsatt er i tråd med datagrunnlaget/flybildene. For disse objektene skal egenskapen VERIFISERINGSDATO oppdateres, men forøvrig skal objektene ikke endres. Se eget kapittel om Bruk av datoegenskaper i FKB.

    • Det presiseres at for objekter som verifiseres ved ajourføring skal lokalid beholdes uendret.

  3. Slette (fjerne fra fila) objekter som finnes i eksisterende data, men som ikke finnes i flybildene.

    • Dersom man er i tvil om objektet fremdeles finnes i terrenget grunnet dårlig innsyn i flybildene så skal objektet beholdes. Det finnes særlige retningslinjer for slike vurderinger på en del objekttyper.

Unntak fra/presisering av hovedreglene kan avtales i teknisk spesifikasjon for kartleggleggingsprosjektet.

D.3. Fotogrammetrisk oppgradering

Mens ajourføring dreier seg om å fange opp endringer i terrenget som ikke finnes i FKB-dataene dreier en oppgradering seg om en total gjennomgang av alle data innenfor kartleggingsområdet for å sikre at de er i tråd med spesifiserte krav. Eksempler på oppgradering kan være:

  • Omklassifisering av angitte objekttyper i tråd med nye regler/krav i FKB-produktspesifikasjon

  • Oppgradering av angitte objekttypers geometrirepresentasjon (f.eks. hvis det bestemmes at en objekttype skal endres fra HREF fot til HREF topp)

  • Påføring av egenskaper på alle objekter av en objekttype

  • Påføring av høydeverdier på alle objekter av en objekttype

  • Tilpasning av angitte objekttyper for å skape konsistens mellom datasett (f.eks. en omkoding av eksisterende data i FKB-Veg for å skape konsistens med vegnettet)

Reglene for oppgradering er ikke beskrevet i fotogrammetrisk registreringsinstruks og må avtales spesielt i det enkelte kartlegginsprosjekt der dette er aktuelt. Se Oppgradering for en generell beskrivelse av oppgradering av FKB-data.

D.4. Geografisk avgrensning av kartleggingsområder

Ved fotogrammetrisk datafangst angis prosjektområdet datafangsten skal skje innenfor ved hjelp av et definert avgrensningspolygon. Følgende håndtering gjelder dersom ikke annet er angitt:

  • Avgrensningspolygonet utformes av oppdragsgiver på en slik måte at bygninger (og sekundært andre typer flate-objekter) i minst mulig grad deles.

  • Avgrensningspolygonet leveres tilbake fra oppdragstaker sammen med dataene.

    • Nærmere retningslinjer for ev. justeringer i avgrensningspolygonet fra oppdragstaker avtales i det enkelte prosjekt. I så fall skal justert avgrensning leveres tilbake sammen med dataene. Justering kan for eksempel være aktuelt dersom man ønsker å konstruere objekter innenfor hele flyfotodekningen eller man ønsker å få registrert alle bygninger som deles av avgrensningspolygonet

  • Nye flate-objekter skal deles av avgrensningspolygonet

    • For flater med delt geometri benyttes en fiktiv avgrensningsobjekttype langs avgrensningspolygonet som det i følge datamodellen er lovlig at kan avgrense flata.

    • For flater med heleid geometri angis det ikke på noen spesielle måte at flata er avgrenset av avgrensningspolygonet, men avgrensninga til flata skal være helt sammenfallende med geometrien til avgrensningspolygonet

  • Flate-objekter som verifiseres i forbindelse med ajourføring skal ikke splittes.

    • Dersom det ikke kan verifiseres fotogrammetrisk at hele objektet fortsatt finnes så skal objektet ikke endres (merkes med VERIFISERINGSDATO) selv om store deler av objektet er innenfor prosjektområdet.

  • Nye kurve-objekter skal konnekteres til avgrensningspolygonet

    • Eksisterende data utenfor prosjektområdet som naturlig skal knyttes sammen med nye kurve-objekter splittes og knyttes til nye objekter i siste punkt som ligger innenfor avgrensningspolygonet

  • Kurve-objekter som skal verifiseres i forbindelse med ajourføring splittes i siste punkt som ligger innenfor prosjektområdet. VERIFISERINGSDATO påføres kun på den delen som i sin helhet ligger innenfor prosjektområdet. Dersom objektet krysser prosjektavgrensningen gjentatte ganger kan hele objektet verifiseres uten splitting, forutsatt stereodekning

Lisensvilkår

Lisens

Denne standarden er gitt ut under norsk lisens for offentlige data (NLOD).

Du har lov til:

  • å kopiere og tilgjengeliggjøre

  • å endre og/eller sette sammen med andre datasett

  • å kopiere og tilgjengeliggjøre en endret eller sammensatt versjon

  • å benytte datasettet kommersielt

På følgende vilkår:

  • at du navngir lisensgiver slik lisensgiver ber om, men ikke på en måte som indikerer at disse har godkjent eller anbefaler deg eller din bruk av datasettet

  • at du ikke bruker dataene på en måte som fremstår som villedende, og heller ikke fordreier eller uriktig fremstiller dataene

Med den forståelse:

  • at data som inneholder personopplysninger og er taushetsbelagt ikke er omfattet av denne lisensen og ikke kan viderebrukes

  • at lisensgiver fraskriver seg ethvert ansvar for informasjonens kvalitet og hva informasjonen brukes til