1. Innledning, historikk og endringslogg
1.1. Innledning
Dette dokumentet er en registreringsinstruks for fotogrammetrisk ajourhold av FKB-TraktorvegSti.
FKB-TraktorvegSti må sees i sammenheng med Elveg 2.0 som inneholder vegnettet i NVDB. NVDB inneholder alt vegnett som er kjørbart med personbil og gang- og sykkelveger. FKB-TraktorvegSti spesifiserer øvrig vegnett. Dette er vegnett som er egnet for ferdsel med traktor (typeVeg "traktorveg") med ev. tilhørende vegsperringer og vegnett som er egnet for umotorisert ferdsel (typeVeg "sti" og "stitrapp").
For full beskrivelse av FKB-TraktorvegSti og detaljer rundt modellering og UML-modeller henvises det til Produktspesifikasjon FKB-TraktorvegSti 5.0 og SOSI del 2.
1.2. Endringslogg
1.2.1. Endringer fra versjon 5.0 2023-01-01 til versjon 5.0 2024-01-01:
-
Kapittel 5.1 Prinsipper for bruk av konnekteringslenke har fått flere bildeeksempler.
-
Kapittel 3.1, under Tilleggsinformasjon for fotogrammetrisk registrering, har fått tilleggstekst om konsekvensretting og hierarki.
1.2.2. Endringer fra versjon 5.0 2022-01-01 til versjon 5.0 2023-01-01:
-
FKB-Elveg er byttet ut med Elveg
-
Kapittel 5.1 Prinsipper for bruk av konnekteringslenke er skrevet om.
-
Figur 7 i kapittel 5.1 er slettet.
1.2.3. Endringer fra versjon 4.6 2016-06-01 til versjon 5.0 2022-01-01:
-
Oppdatert generelle konsepter fra FKB 5.0 generell del.
-
Justert generell tekst for blant annet kap. 7, 8 og 9.
-
Typeveg gangveg, fortau, gangfelt og trapp er fjernet fra FKB-TraktorvegSti da de innføres i Elveg 2.0 og Nasjonal vegdatabank (NVDB).
-
Ny typeveg stitrapp innført.
-
Definisjoner for typeveg traktorveg og sti er revidert.
-
Datatype Vegsystemreferanse med datterobjekter innført for å harmonisere med produkspesifikasjon for Elveg 2.0
-
Innført ny opsjonelle egenskaper: beredskapsveg og serviceveg.
-
Vegsperring: innført nye egenskaper FunksjonVegsperring (linket opp mot samme kodeliste i FKB-Veg), GjelderTidsrom og EierVegsperring for å samsvare med Elveg 2.0.
-
Innført egenskapene turruterPeker og eksternPeker for å gjøre det mulig å legge inn referanser (i form av URI-er) til de tilsvarende objektene forvaltet i andre systemer.
-
Navn og definisjoner i kodelistene er sjekket og harmonisert mot NVDB.
-
Kodelister er revidert og flyttet ut av produktspesifikasjon og forvaltes eksternt i Geonorge.
2. Generelle retningslinjer for fotogrammetrisk kartlegging av FKB
2.1. Fotogrammetrisk nykonstruksjon
Ved fotogrammetrisk nykonstruksjon skal alle objektene som er spesifisert i registreringsinstruksen og som er synlige i flybildene registreres.
2.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.
2.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.
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:
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.
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. |
2.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:
-
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 id-håndtering i FKB skal da legges til grunn.
-
-
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 beskrivelse av håndtering av datoegenskaper i FKB Generell del for mer om dette.
-
Det presiseres at for objekter som verifiseres ved ajourføring skal lokalid beholdes uendret.
-
-
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.
2.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 FKB generell del for en generell beskrivelse av oppgradering av FKB-data.
2.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
3. Objekttyper og egenskaper
Alle FKB-TraktorvegSti objekter skal registreres med et sett egenskaper som er felles for alle FKB datasett. En nærmere beskrivelse av hvilke og hvordan disse egenskapene skal registreres ved fotogrammetrisk datafangst er beskrevet i kapittelet Generelle retningslinjer for fotogrammetrisk kartlegging av FKB og FKB Generell del.
Registreringsinstruksen inneholder en del egenskaper som ikke skal registreres fotogrammetrisk, men som skal beholdes dersom egenskapene allerede finnes i eksisterende data. Ved geometriforbedring skal eksisterende egenskaper overføres til nytt objekt. Hvilke egenskaper dette gjelder er angitt som restriksjoner under.
3.1. Objekttype: Veglenke
Definisjon fra FKB produktspesifikasjon: Objekttype som representerer alle senterlinjelenker i FKB-TraktorvegSti.
Tilleggsinformasjon for fotogrammetrisk registrering
Veglenke er en felles objekttype for alle veglenker (senterlinjer) i et vegnett. Egenskapen typeveg beskriver hva slags veglenke det er. I FKB-TraktorvegSti er aktuelle verdier for typeveg Traktorveg, Sti og stitrapp. Se nærmere beskrivelse av av typeVeg under.
Veglenker skal knyttes sammen i nodepunkter (knutepunkter). Senterlinjeobjekter i dette datasettet skal ikke ligge nærmere hverandre enn 2 m uten at de henger sammen, eventuelt med konnekteringslenke.
Som beskrevet i kap.3.4 i FKB-Veg og kap.3.2 i Elveg gjelder konsekvensretting i FKB-Veg også for endringer av veglenker i TraktorvegSti:
Enhver endring av geometri og egenskap typeveg i Elveg eller FKB-TraktorvegSti skal følges opp med konsekvensretting av vegkanter og flater i FKB-Veg. Det er alltid senterlinjegeometri i Elveg og FKB-TraktorvegSti som skal være førende for innhold og koding av vegkanter og vegflater i FKB-Veg, ikke omvendt.
Føringer
FKB grunnrissreferanse |
Senterlinje |
---|---|
FKB høydereferanse |
Terreng |
FKB-A |
Påkrevd registrering |
FKB-B |
Påkrevd registrering |
FKB-C |
Påkrevd registrering |
FKB-D |
Påkrevd registrering |
Egenskapstabell for objekttype: Veglenke
Navn: | Type: | SOSI_navn: | Mult.: |
---|---|---|---|
identifikasjon |
«dataType» Identifikasjon |
..IDENT |
[0..1] |
identifikasjon.lokalId |
CharacterString |
…LOKALID |
[1..1] |
identifikasjon.navnerom |
CharacterString |
…NAVNEROM |
[1..1] |
identifikasjon.versjonId |
CharacterString |
…VERSJONID |
[0..1] |
oppdateringsdato |
DateTime |
..OPPDATERINGSDATO |
[0..1] |
sluttdato |
DateTime |
..SLUTTDATO |
[0..1] |
datafangstdato |
Date |
..DATAFANGSTDATO |
[1..1] |
verifiseringsdato |
Date |
..VERIFISERINGSDATO |
[0..1] |
registreringsversjon |
«CodeList» Registreringsversjon |
..REGISTRERINGSVERSJON |
[0..1] |
informasjon |
CharacterString |
..INFORMASJON |
[0..1] |
kvalitet |
«dataType» Posisjonskvalitet |
..KVALITET |
[1..1] |
kvalitet.datafangstmetode |
«CodeList» Datafangstmetode |
…DATAFANGSTMETODE |
[1..1] |
kvalitet.nøyaktighet |
Integer |
…NØYAKTIGHET |
[0..1] |
kvalitet.synbarhet |
«CodeList» Synbarhet |
…SYNBARHET |
[0..1] |
kvalitet.datafangstmetodeHøyde |
«CodeList» Datafangstmetode |
…DATAFANGSTMETODEHØYDE |
[0..1] |
kvalitet.nøyaktighetHøyde |
Integer |
…H-NØYAKTIGHET |
[0..1] |
senterlinje |
GM_Curve |
.KURVE |
[1..1] |
typeveg |
«CodeList» Typeveg |
..TYPEVEG |
[1..1] |
konnekteringslenke |
«» Boolean |
..KONNEKTERINGSLENKE |
[1..1] |
veglenkeadresse |
«dataType» Veglenkeadresse |
..VEGLENKEADRESSE |
[0..1] |
veglenkeadresse.kommunenummer |
«CodeList» Kommunenummer |
…KOMM |
[1..1] |
veglenkeadresse.adressekode |
«dataType» Integer |
…ADRESSEKODE |
[1..1] |
veglenkeadresse.adressenavn |
«dataType» CharacterString |
…ADRESSENAVN |
[1..1] |
veglenkeadresse.sideveg |
«» Boolean |
…SIDEVEG |
[1..1] |
vegsystemreferanse |
«dataType» Vegsystemreferanse |
..VEGSYSTEMREFERANSE |
[0..1] |
vegsystemreferanse.vegsystem |
«dataType» Vegsystem |
…VEGSYSTEM |
[1..1] |
vegsystemreferanse.vegsystem.vegkategori |
«CodeList» Vegkategori |
….VEGKATEGORI |
[1..1] |
vegsystemreferanse.vegsystem.vegfase |
«CodeList» Vegfase |
….VEGFASE |
[1..1] |
vegsystemreferanse.vegsystem.vegnummer |
«dataType» Integer |
….VEGNUMMER |
[0..1] |
vegsystemreferanse.vegstrekning |
«dataType» Vegstrekning |
…VEGSTREKNING |
[0..1] |
vegsystemreferanse.vegstrekning.strekningNummer |
«dataType» Integer |
….STREKNINGNUMMER |
[1..1] |
vegsystemreferanse.vegstrekning.delstrekningNummer |
«dataType» Integer |
….DELSTREKNINGNUMMER |
[0..1] |
kommunenummer |
«CodeList» Kommunenummer |
..KOMM |
[0..1] |
klasselandbruksveg |
«CodeList» KlasseLandbruksveg |
..KLASSELANDBRUKSVEG |
[0..1] |
belysning |
«» Boolean |
..BELYSNING |
[1..1] |
barmarksløype |
«» Boolean |
..BARMARKSLØYPE |
[1..1] |
rutemerking |
«CodeList» Rutemerking |
..RUTEMERKING |
[0..1] |
medium |
«CodeList» Medium |
..MEDIUM |
[1..1] |
serviceveg |
«» Boolean |
..SERVICEVEG |
[1..1] |
beredskapsveg |
«» Boolean |
..BEREDSKAPSVEG |
[1..1] |
eksternpeker |
URI |
..EKSTERNPEKER |
[0..1] |
turruterpeker |
URI |
..TURRUTERPEKER |
[0..1] |
Restriksjoner
Navn: | Beskrivelse: |
---|---|
barmarksløype |
Eksisterende data beholdes. Nye data påføres verdien False/Nei. |
beredskapsveg |
Eksisterende data beholdes. Nye data påføres verdien False/Nei. |
kommunenummer |
Eksisterende data beholdes, men påføres ikke nye objekter |
landbruksvegklasse |
Eksisterende data beholdes, men påføres ikke nye objekter |
rutemerking |
Eksisterende data beholdes, men påføres ikke nye objekter |
serviceveg |
Eksisterende data beholdes. Nye data påføres verdien False/Nei. |
veglenkeadresse |
Eksisterende data beholdes, men påføres ikke nye objekter |
vegsystemreferanse |
Eksisterende data beholdes, men påføres ikke nye objekter |
Presiseringer til beskrivelsen av kodelistekoder
Figurer og skisser knyttet til bruk av bestemte kodelister og koder.
Typeveg - Kodenavn: Sti
Definisjon: Tydelig, smalt og sammenhengende tråkk i terrenget, som har oppstått gjennom bruk eller aktiv tilrettelegging.
Tilleggsopplysninger FKB: Sti benyttes primært i utmark, men kan også registreres i urbane strøk for stier/tråkk i terrenget der det ikke er noen opparbeidet veg med klar avgrensning. Stier skal være del av et sammenhengende transportnettverk for gående. Kortere frittliggende stier som ikke inngår i et transportnettverk er derfor ikke nødvendig å registrere. I områder med mange stier (for eksempel rundt parkeringsplasser, parkområder etc.) er det bare nødvendig å registrere hovedferdselårene. For stier i utmark kan Typeveg Sti benyttes gjennomgående selv om stien i områder er opparbeidet som en gangveg (som for eksempel på høyt trafikkerte turiststier).
Typeveg - Kodenavn: Stitrapp
Definisjon: trapp som naturlig inngår i nettverket for stier
Tilleggsopplysninger FKB: Denne vegtypen benyttes der hvor trapper er et bindeledd mellom to andre veglenker, slik at det dannes et sammenhengende nettverk av veglenkene mellom stier eller mot andre veglenker. I FKB-BygnAnlegg registreres FrittståendeTrapp med flategeometri for de veglenkene som klassifiseres som Typeveg stitrapp.
Typeveg - Kodenavn: Traktorveg
Definisjon: Veg som hele året (eller deler av året) ikke egner seg for vanlig bilkjøring, men som er farbar med traktor.
Tilleggsopplysninger FKB: Traktorveger skal være så brede at traktorer kan benytte disse, minimum 2.5 meter. Traktorveger inngår i det permanente vegnettet og medfører varige terrenginngrep i form av en sammenhengende vegkropp. Slep og driftsveier som ikke har bearbeidet såle og som er skapt av gjentatte passeringer med traktor, defineres normalt ikke som en traktorveg. Slep og driftsveier som binder sammen samferdselsnettverket kan registreres som konnekteringslenke med typeveg sti. Veger som er bygd som traktorveger, men opprustet slik at de i praksis er kjørbare med bil skal registreres som bilveg i Elveg 2.0. En (tidligere) traktorveg som er gjengrodd med vegetasjon og ikke lenger egner seg for ferdsel med traktor skal ikke klassifiseres som traktorveg (men heller klassifiseres som Typeveg Sti).
![typeveg](figurer/typeveg.png)
![typeveg2](figurer/typeveg2.png)
![typeveg3](figurer/typeveg3.png)
4. Datakvalitet
For detaljer om kvalitetsmodellen som er benyttet her henvises det til FKB Generell del, kapittel 8.
Kvalitetskravene gjelder alle nye data som blir etablert i et FKB kartleggingsprosjekt (jf. Registrering av nye kartobjekter i kapittel 2).
4.1. Kvalitetskrav
Kvalitetselement | Kvalitetsmål | Referanse | Krav | Kommentar |
---|---|---|---|---|
Konseptuell konsistens |
Antall enheter der regler i konseptuelt skjema ikke er oppfylt |
NS-EN ISO19157:2013/010/1 |
0 feil |
F.eks. overskytende egenskaper eller ulovlige egenskaper. |
Topologisk konsistens |
Antall ulovlige egenoverlappinger |
NS-EN ISO19157:2013/027/1 |
0 feil |
Egenoverlapper ("spiker") skal ikke forekomme i FKB-Lufthavn |
Topologisk konsistens |
Antall ulovlige egenkryssinger |
NS-EN ISO19157:2013/026/1 |
0 feil |
Egenkryssinger skal ikke forekomme i FKB-Lufthavn |
Krav til logisk konsistens kontrolleres maskinelt vha. SOSI-kontroll, kontroll mot GML-skjema e.l.
Kvalitetselement | Kvalitetsmål | Referanse | Krav |
---|---|---|---|
Klassifikasjonsriktighet |
Prosentandel feil klassifiserte egenskaper |
Geodatakvalitet:2014/508/1 |
Maksimalt 0.5% feilklassifisering |
Kvalitetselement | Kvalitetsmål | Kvalitetsklasse Fullstendighet | Referanse | Krav |
---|---|---|---|---|
Manglende objekter |
Prosentandel manglende objekter |
1 |
Geodatakvalitet:2014/102/1 |
Maksimalt 0,5% manglende objekter |
Manglende objekter |
Prosentandel manglende objekter |
2 |
Geodatakvalitet:2014/102/1 |
Maksimalt 2% manglende objekter |
Overskytende objekter |
Prosentandel overskytende objekter |
1 |
Geodatakvalitet:2014/101/1 |
Maksimalt 0,5% overskytende objekter |
Overskytende objekter |
Prosentandel overskytende objekter |
2 |
Geodatakvalitet:2014/101/1 |
Maksimalt 2% overskytende objekter |
Krav til fullstendighet og egenskapskonsistens kontrolleres mot flybilder (ortofoto) som ble brukt under kartkonstruksjon.
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 |
Krav til stedfestingsnøyaktighet kontrolleres mot uavhengige innmålinger med bedre kvalitet som f.eks. laserdata eller landmåling. Hvilke objekttyper som inngår i hvilke kvalitetsklasser er angitt under.
Grove feil
Grove feil regnes som avvik større enn 3 ganger krav til standardavviket angitt i tabellen over. Kravet er at maksimalt 1 % av registrerte objekter skal ha avvik som kategoriseres som grove feil.
4.2. Kvalitetsklasser
Ved angivelse av krav til stedfestingsnøyaktighet og fullstendighet er objekttypene inndelt i forskjellige klasser. Nedenfor følger en oversikt over hvilken klasse objektypen Veglenke med tilhørende egenskap vegType tilhører i FKB-TraktorvegSti.
Objekttype | Kvalitetklasse Grunnriss | Kvalitetsklasse Høyde | Kvalitetsklasse Fullstendighet |
---|---|---|---|
Veglenke ("sti") |
4 |
4 |
2 |
Veglenke ("stitrapp") |
4 |
4 |
2 |
Veglenke ("traktorveg") |
3 |
2 |
2 |
5. Tilleggsinformasjon
5.1. Prinsipp for registrering av konnekteringslenke
Veglenker i FKB-TraktorvegSti skal registreres sammenhengende over åpne plasser internt i datasettet og i overganger mellom FKB-TraktorvegSti og Elveg 2.0. Egenskapen konnekteringslenke ja brukes for å angi at veglenken beskriver opplagte forbindelser over åpne plasser. Hensikten med egenskapen er å legge til rette for god teknisk sammenheng i datasettet samtidig med mulighet for bortfiltrering av disse lenkene ved uttegning i karttjenester. Konnekteringslenker skal registreres og ajourføres fotogrammetrisk etter følgende prinsipper:
1) Veglenker i FKB-TraktorvegSti skal registreres sammenhengende over åpne plasser internt i datasettet og i overganger mellom FKB-TraktorvegSti og Elveg 2.0
2) Konnekteringslenke ja skal angis når veglenke beskriver trase over åpen plass som er kartlagt med OBJTYPE AnnetVegarealAvgrensning i FKB-Veg (se bildeeksempler under).
3) Eksisterende veglenker med konnekteringslenke ja skal bare slettes dersom veglenka den skaper forbindelse til også slettes
4) Eksisterende veglenker med konnekteringslenke ja skal geometriforbedres dersom tilstøtende veglenker geometriforbedres
Betingelse: Egenskapen skal angis for veglenker som er konnekteringslenker
Det presiseres at konnekteringslenkene skal registreres over åpne plasser som en naturlig kobling mellom traktorveg/sti og veg. Forløpet skal følge andre samferdselsobjekter. Eventuell usikkerhet i forløpet skal fremgå av kvalitetskodingen. Konnekteringslenker kan også registreres der eksisterende AnnetVegarealAvgrensning representerer begynnelsen av traktorvegen/stien fra selve vegen.
Konnekteringslenker registreres kun ved nyregistrering eller endring på eksisterende veglenker. Utover dette må registrering av konnekteringslenker mellom eksisterende data (uten endringer) bestilles spesielt i prosjektet.
Under følger noen bildeeksempler som viser hvordan konnekteringslenker skal registreres i TraktorvegSti når traktorveg eller sti skal knyttes sammen mot veglenker i Elveg.
![Bilde av konnekteringslenker](figurer/konnekteringslenke.png)
![Bilde av konnekteringslenker](figurer/konnekteringslenke2.png)
![Bilde av konnekteringslenker](figurer/Konnekteringslenke1_TrvegSti.png)
![Bilde av konnekteringslenker](figurer/Konnekteringslenke2_TrvegSti.png)
![Bilde av konnekteringslenker](figurer/Konnekteringslenke3_TrvegSti.png)
![Bilde av konnekteringslenker](figurer/Konnekteringslenke4_TrvegSti.png)
Vi viser også til noen eksempler der det IKKE skal etableres konnekteringslenke. Det er typisk der det ikke er åpne arealer mellom lenkene eller fysiske hindringer (for eksempel grøfter) som gjør ferdsel mellom veglenkene unaturlig eller umulig.
![Bilde av konnekteringslenker](figurer/Konnekteringslenke5_TrvegSti.png)
5.2. Ajourføring
En første versjon av FKB-TraktorvegSti ble etablert første halvår 2014. All videre datainnsamling vil dreie seg om ajourhold av dette datagrunnlaget. Dersom man ønsker å etablere bedre nettverkstopologi vil dette være å anse som en oppgradering av datasettet og må avtales spesielt.
![ajourforing](figurer/ajourforing.png)
I ajourholdet vil objektene som inngår i FKB-TraktorvegSti normalt bli etablert ved hjelp av fotogrammetri (kartkonstruksjon eller digitalisering fra ortofoto). I noen tilfeller kan objektene også være etablert ved hjelp av GNSS-måling. Dette er spesielt aktuelt for innmåling av stier og vegsperringer som er vanskelig å se tydelig på flybilder.
5.3. Fotogrammetrisk datafangst
Fotogrammetrisk ajourhold av FKB-TraktorvegSti er en standard del av FKB-prosjekter. Ved slik datafangst sammenlignes datainnholdet i FKB-TraktorvegSti med flybilder og ny/endret geometri registreres.
Følgende datainnhold egner seg for fotogrammetrisk ajourhold:
-
Senterlinjegeometrien og metadata knyttet til geometrien som kvalitet og datafangstdato. Unntak fra dette er stier i skogsområder. Disse er i liten grad synlige på flybilder. All ny geometri knyttes sammen med nodepunkter og konnekteres med vegnett i Elveg/NVDB.
-
typeVeg: Det bør i de fleste tilfeller være mulig å skille Typeveg-kodene "traktorveg" og "sti" fra hverandre. Det vanskeligste å klassifisere fra flybilder er skille mellom en traktorveg og en (skogs-) bilveg. Tidligere data (og ev. manus for nye data) bør legges til grunn for klassifiseringen der det er tvil.
-
konnekteringlenke: Konnekteringslenker skal registreres. Geometri som naturlig og logisk bør knyttes sammen for å bilde nettverk kan gis egenskapen konnekteringslenke. Konnekteringslenker internt i datasettet kan registreres men viktigst er knyttingen mot Elveg.
-
belysning: Veglenker med belysning bør være kurant å se i flybilder.
-
medium: Veglenker som ikke går på terrenget bør være kurant å se i flybilder.
Følgende datainnhold er ikke egnet for fotogrammetrisk ajourhold:
-
Vegsperring konstrueres ikke fotogrammetrisk i FKB-TraktorvegSti. Vegsperring (med kurvegeometri) inngår imidlertid i fotogrammetrisk konstruksjon av FKB-Veg.
-
barmarksløype: Hva som er barmarksløyper bestemmes administrativt (Fylkesmannen i Finnmark). False/Nei er standardverdi.
-
beredskapsveg: Hva som er beredskapsveg bestemmes administrativt av eier. False/Nei er standardverdi.
-
rutemerking: Egenskapen holdes oppdatert ved at dataene sammenlignes med data for friluftsruter (se eget punkt under).
-
serviceveg: Hva som er serviceveg bestemmes administrativt av eier. False/Nei er standardverdi.
-
vegsystemreferanse og landbruksvegklasse: Vegsystemreferanse angis administrativt av kommunene som en koblingsnøkkel mot vegregisteret til landbruksforvaltninga. Landbruksvegklasse skal være i tråd med tilsvarende egenskap i dette vegregisteret.
-
veglenkeadresse: Angis administrativt av kommunene.
Dersom noen av disse objektene/egenskapene skal registreres fotogrammetrisk må det benyttes manus og avtales spesielt.
5.4. Ajourføring gjennom Nasjonal database Turruter
Fra 2014 er det satt igang forvaltning av turruter i Turrutebasen (Nasjonal database for turruter). Gjennom dette får Kartverket inn data fra friluftorganisasjoner, kommuner og privatpersoner som er ute i terrenget og kartlegger friluftsruter med GPS/GNSS. https://register.geonorge.no/register/versjoner/produktspesifikasjoner/kartverket/tur-og-friluftsruter.
Rutene som kartlegges gjennom dette opplegget vil i stor grad følge de samme stiene/gangvegene/traktorvegene som forvaltes i FKB-TraktorvegSti. Turrutene er en viktig datakilde, særlig for stier som ikke er lette å se i flybilder. Kartverket vil jobbe for å etablere gode rutiner for et slikt ajourhold.
5.5. Administrativ datafangst
Alle objekttyper innenfor datasettet FKB-TraktorvegSti skal ajourføres kontinuerlig dersom de kan fanges opp gjennom saksbehandling og/eller i det daglige forvaltningsarbeidet.
Dette gjelder spesielt for traktorveger og egenskaper/vegsperringer knyttet til disse som en del av landbruksforvaltningen. Det kontinuerlige vedlikeholdet av FKB-TraktorvegSti må knyttes nært til vedlikehold av Elveg og FKB-Veg slik at det blir samsvar mellom datasettene.
Når det gjelder klassifisering av Typeveg er kommunen den etaten som har det helhetlige ansvaret for vegforvaltningen i sitt område og som kjenner området best gjennom lokalkunnskap. Spesifikasjonen definerer og gir retningslinjer for de ulike typene veglenker. Kommunen utøver skjønn basert på disse retningslinjene og bestemmer hvilken vegtype veglenka har.
Vedlegg A: Forklaring til registreringsinstrukser for fotogrammetrisk registrering
A.1. UML-modell for Fotogrammetriske registreringsinstrukser
For å sørge for at det er fullt samsvar mellom FKB produktspesifikasjonene og registreringsinstruksene for datafangst er det utarbeida et opplegg med egne UML-datamodeller for registreringsinstruksene. I korte trekk går dette ut på at det tas en kopi av UML datamodellen for FKB produktspesifikasjonene der det legges inn justeringer og ekstrainformasjonen med tanke på datafangst. Disse UML-modellene følger ikke noen SOSI-standard, men er utarbeide med tanke på å kunne generere ut godt lesbar dokumentasjon og maskinlesbare filer for validering (SOSI-kontroll, GML-skjema etc.). UML datamodellene finnes i SOSI modellregister.
Registreringsinstruksene består av UML-elementer (se veiledning for å lese UML-diagrammer). Alle objekttyper listes derfor ut som "FeatureType" slik de er modellert i UML. Assosiasjoner i FKB listes i registreringsinstruksene ut i egenskapstabellen (med en FeatureType som datatype). I forbindelse med fotogrammetrisk registrering vil hovedregelen være at assosiasjoner håndteres som opsjonelle egenskaper, dvs. at de ikke registreres.
A.2. Informasjon som angis om alle objekttyper
-
Definisjon hentet fra FKB-produktspesifikasjon
-
Bilde/skisse hentet fra FKB-produktspesifikasjon
-
Tilleggsbeskrivelse for objekttypen for fotogrammetrisk registrering
-
Bilder/skisser med bildetekst for fotogrammetrisk registrering
-
Tabell med Føringer for fotogrammetrisk registrering. Se tabell under for en forklaring på hvilke føringer som kan være angitt og hva disse betyr.
-
Egenskapstabell hentet fra FKB-produktspesifikasjon. Denne inneholder alle egenskaper for objekttypen. Både de som skal registreres fotogrammetrisk og alle andre.
-
Tabell med Restriksjoner er angitt for noen objekttyper. Denne tabellen inneholder egenskaper det er knyttet spesielle krav til ved fotogrammetrisk registrering.
-
For objekttyper med egenskaper som benytter kodelister der disse kodeverdiene skal klassifiseres fotogrammetrisk finnes det også Presiseringer til beskrivelsen av kodelistekoder. Her listes de aktuelle kodene for fotogrammetrisk registering ut med en definisjon/beskrivelse som skal ligge til grunn for klassifiseringen og gjerne også forklarende bilder/skisser.
Føring | Verdier | Kommentar |
---|---|---|
FKB-A |
Registreres ikke / Opsjonell registrering / Påkrevd registrering |
Finnes på alle objekttyper |
FKB-B |
Registreres ikke / Opsjonell registrering /Påkrevd registrering |
Finnes på alle objekttyper |
FKB-C |
Registreres ikke / Opsjonell registrering /Påkrevd registrering |
Finnes på alle objekttyper |
FKB-D |
Registreres ikke / Opsjonell registrering /Påkrevd registrering |
Finnes på alle objekttyper |
FKB høydereferanse |
Fritekst som angir høydereferanse for registrering av geometrien til objekttypen |
Finnes på alle objekttyper |
FKB grunnrissreferanse |
Fritekst som angir grunnrissreferanse for registrering av geometrien til objekttypen |
Finnes på alle objekttyper |
FKB-A minstestørrelse |
Fritekst som angir minstestørrelse for registrering i FKB-A |
Finnes bare på objekttyper der det er minstestørrelser for registrering |
FKB-B minstestørrelse |
Fritekst som angir minstestørrelse for registrering i FKB-B |
Finnes bare på objekttyper der det er minstestørrelser for registrering |
FKB-C minstestørrelse |
Fritekst som angir minstestørrelse for registrering i FKB-C |
Finnes bare på objekttyper der det er minstestørrelser for registrering |
FKB-D minstestørrelse |
Fritekst som angir minstestørrelse for registrering i FKB-D |
Finnes bare på objekttyper der det er minstestørrelser for registrering |
FKB registeringsmetode |
Fritekst som angir krav til registreringsmetode for objekttypen |
Finnes bare på objekttyper der dette er relevant |
Merknad: Føring for minstestørrelser gjelder automatisk for en mindre detaljert FKB-standard. Dersom det bare er angitt krav til minstestørrelser i FKB-A gjelder denne automatisk også for de mindre detaljerte FKB-standardene om ikke annet er spesielt angitt.
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