DEL 1 PRAKTISK BRUK

 

1 REVISJONER

Kapittel-versjon

Dato

Merknad

Ver. 1.0

okt 1987

Første utgave

Ver. 1.2

mai 1988

Kap. 3.6 omarbeidet
Kap 5: Nytt
Kap 6: Tidligere kap 5.

Ver 1.3

Juni 1989

Hele delen omarbeidet

Ver 1.4

Mars 1990

Små opprettinger

Ver 2.0

April 1992

Foreløpig - små endringer

Ver 2.1

Januar 1994

Små endringer

Ver 2.2

Januar 1995

SOSI-arb.gr 1. Full gjennomgang med nye mekanismer og forbedringer

Ver 2.21

Mai 1996

SOSI-arb.gr 1, rettelser og tilføyelser

Aktuell ansvarlig: SOSI-sekretariatet
Statens kartverk
IT-tjenesten
Tlf 32 11 81 00

1.1 Endringslogg fra SOSI-versjon 2.2

Det er skjedd en del endringer / rettelser i SOSI-del 1, praktisk bruk. De fleste endringene er tatt med i endringsloggen. Handtering av tekst er flyttet , men selve endringene er dekket her.

4.1 Hodet på SOSI-fila
Følgende er tatt med som en presisering:

NB. Ved dårlig synbarhet er det ønskelig å beskrive korrekt nøyaktighet, ikke bare henvise til tidligere verdi.


4.5 Innholdsfortegnelse
FKB-versjon er lagt, for å kunne skille mellom en syntaktisk oppdatering og en innoldsmessig.

.DEF
..INNHOLD *
...FKB-DATA *
....FKB-NAVN T8 Kapittelnavn
....FKB-STD T1 bokstav for FKB-standard (A,B,C,D)
....FKB-OPSJ T1 hvis opsjoner er med, er verdien O
....FKB-VERSJON
T5 F.eks FKB-VERSJON 2.1
...BEGRENSNINGER

....MAX_ELEMENT_PKT H5 Max antall punkter i grafisk element
....MAX_OBJEKT_PKT
H5 Max antall punkter i grafisk objekt
....MAX_REF_OBJEKT H5 Antall referenser (i
flate/trase)

Eksempelet med FKB-versjon over sier at innholdet er i overensstemmelse med DEL3 i SOSI-versjon 2.1. Dvs. at enkelte objekter som f.eks er standard i SOSI-versjon 2.2 forstatt ikke nødvendigvis finnes i fila dersom disse f.eks var opsjon i versjon 2.1.

Denne mekanismen er lagt inn for å muliggjøre syntaktisk oppgradering mellom versjoner.

4-7 Opplysning om eier og produsent
Med EIER forstås her rettighetshaver.

6.1.3 Sammenknytning i ulike dimensjoner.
I utgangpsunktet skal objekter knyttes sammen i den dimensjon de er representert i.. Objekter med 3 dimensjoner skal knyttes sammen i nord , øst og høyde, og objekter i 2D knyttes sammen i nord og øst.

Imidlertid vil det i enkelte tilfeller være behov for å knytte sammen 2D med 3D objekter, uten at høydene midles. I disse tilfellene vil punktene være knytta sammen kun i grunnriss. Eksempel på dette finnes i bygningsdata. I disse tilfellene trenger ikke 2D-objekter å arve høyden.

Objekter knyttes i enkelte sammenhenger sammen i grunnriss selv om høydene er ulike. Dette er da beskrevet i de respektive databeskrivelsekapitlene, kartleggingsstandarden (SOSI-DEL3) eller eventuelt registreringsinstruks(SOSI-DEL5), eller som merknad i hodet på SOSI-fila.

6.7 Grafisk element: BUEP
Bedre koordinater i eksempelet

6.9 Grafisk element: SIRKEL
Bedre koordinater i eksempelet

6.12 Grafisk element: TEKST.
Skrevet om, noen opprettinger, presisering, bedre eksempler :

6.12.2 SOSI-basisnavn-definisjoner
DIM beskriver bokstavenes eller symbolenes bredde og høyde i millimeter på kartet pr. bokstav. Høyde regnes fra bunnlinje til øvre kant. Se TREF.

Dersom bredde ikke er oppgitt, benyttes standard bredde for den gitte teksthøyden jfr. fonten.
Topplinje fjernet fra TREF.
For SYMBOL er ØK erstattet med FKB for “Grafisk standard for ØK og TK”

8.3 KVALITET
Flater representert ved et sentralpunkt trenger ikke kvalitetskoding. Kvaliteten på flate kan avledes fra de objektene som danner flata.

Koding av nøyaktighet er ikke begrenset til nøyaktighetskodene i tabellen. i standarden

8.4 DATO
Alle objekter beskrevet i henhold til SOSI-versjon 2.2 skal ha dato. En del eldre data vil vanskelig kunne tidfestes. For disse kan en benytte ..DATO *, dvs at dato er vurdert, men ikke tallfeste.

8.13 Avblending
Avblendingsdata er kodet med en spesiell egenskap (..AVBLEND) som forteller hvilken primærdata som skal bli avblenda.

.DEF
..AVBLEND T6
Benytter kodrnavnet på databeskrivelseskapitlene:
DEK, VBASE, VSIT, ETC

Benyttes kun for avblendinsdata / presentasjonsdata

9.1 Rutenett, ramekant, etc.
Fritekst_kart benytter det grafiske element TEKST, samt TTEMA 9599.

10. Presentasjonsdata
Dette er et nytt kapittel, som inneholder noe av det som lå under TEKST tidligere.

I en presentasjon inngår objekter fra ett eller flere primærdatakapitler, ikke geografiske objekter og mekanismer samt presentasjonsdata i form av tekststrenger og symbler.

Undisplayed Graphic

Med presentasjonsdata mener her tilleggsdata som er nødvendig for å produsere presentasjoner, og som ikke lar seg fornuftig generere automatisk i en uttegningsprosess.
Eksempler på presentasjonsdata er tekstdata der tekst og symboler er ferdig plassert i kartbilde for et aktuelt kartprodukt.

Tekst på kartet som er generert automatisk i uttegningsprosessen fra f.eks primærdatasett omfattes ikke av det vi her kaller presentasjonsdata.

Beskrivelsesteknikker for presentasjonsdata er beskrevet under det grafiske element .TEKST.

Formålet med tekstdataspesifikasjonen er å ta vare på det redaksjonelle arbeidet ved manuell plassering og redigering av alt tekstmateriell i en produksjonsprosess. Med tekst forstås også utplasserte symboler (eks. markslagssymboler).

Tekstdata inngår ikke i primærdatabeskrivelsene, men er presentasjonsdata som er spesifikk for en enkelt kartserie (eller endog et enkeltstående kartblad).

Symboler i en presentasjon tegnes ut fra tekstobjekter (som ofte er generert fra primærdatabaser) eller tegnes direkte fra primærdatabaser.

I forbindelse med fotogrammetrisk konstruksjon har en bl.a behov for å legge ut markslagssymboler uten at en oppfatter dette som representasjonspunkt for flaten. Disse må da referes til et symbolbibliotek.

2 INNLEDNING

SOSI-formatets syntaksbeskrivelse åpner mulighet for nær sagt uendelig mange måter å beskrive samme informasjonen på.

Mange brukere ønsker mye fastere definering av formatet, slik at programmer som skal lese/skrive SOSI-data har en fastere struktur å forholde seg til. I tillegg er det behov for standard metoder for å beskrive geografiske forekomster (punkt,linjer,buer,flate etc.)

Dette kapittel av SOSI-formatet har som mål å definere standard måter å angi ulike fenomener på innenfor en SOSI-syntaks. Dette innebærer blant annet at en her innfører standard kompaktifisering og konkatenering.

Skal formatet svare til hensikten, - det å kunne transportere data mellom ulike systemer - , må det også defineres hvordan punkt, linjer, buer, sirkler, flater etc. skal beskrives og hvordan egenskapsdata skal kunne tilknyttes. Således kan en si at DEL-2 av SOSI-manualen beskriver en datastruktur for geografiske data som importører og eksportører av SOSI-data må forholde seg til.

3 OPPBYGNING AV SOSI-FILA

Her gis en kort gjennomgang av hvordan en SOSI-fil er oppbygd, inklusivt et noe omfattende eksempel som viser en del av de mulighetene formatet gir.

SOSI-fila har denne hovedstruktur:

.HODE (Innledende opplysninger)
.DEF (Brukerstyrte definisjoner - se syntaksdelen
.selve dataene (Datagrupper)
.SLUTT (Avslutning )

Hodet på SOSI-fila innledes alltid med gruppeelementet .HODE. Hodet inneholder opplysninger som gjelder for hele fila. Noen opplysninger i hodet gjelder koordinatene slik som opplysning om koordinatsystem, origo for data, dekningsområde etc. Andre hodeopplysninger er egenskapsinformasjon som gjelder for alle objekter i hele fila med mindre disse er angitt spesielt i de enkelte datagrupper nede i fila. Mere detaljert gjennomgang av .HODE kommer senere.

Brukerstyrte definisjoner (.DEF) benyttes hvis en ønsker å definere spesielle egenskapsnavn som ikke er definert i den offisielle SOSI-standarden.

Datagruppene innledes alltid med et SOSI-gruppeelementnavn, som for kartdatas vedkommende alltid vil være enten et grafisk element, eller et grafisk objekt.

• Grafiske elementer består av ett eller flere punkt (koordinatsett). (Eksempel: PUNKT, LINJE, KURVE, BUE, TEKST, SIRKEL, SVERM, KLOTOIDE, BEZIER,...)

• Grafiske objekter består av flere grafiske elementer eller andre grafiske objekter og er knyttet sammen med referansenummer. (Eksempel: TRASE, FLATE,)

Datagruppene nummereres med serienummer for identifisering innen SOSI-fila, men det er ikke nødvendig at nummereringen er fortløpende eller sortert. Serienummerne benyttes ikke direkte i data med lavere SOSI-NIVÅ enn 4, men bør alltid brukes for å kunne identifisere de enkelte grafiske elementer. (Ved feilrapportering.)

Videre kan datagrupper logisk knyttes sammen ved hjelp av referansenummer som peker til serienummer for andre datagrupper. Dette benyttes av de grafiske objektene.

Hver datagruppe kan ha en eller flere egenskapsopplysninger. Med begrepet egenskapsopplysninger forstår vi det en tradisjonelt har kalt TEMA, samt andre egenskapsopplysninger. Merk at vi nå kaller alt bortsett fra koordinatene for egenskapsopplysninger.

Tema-begrepet i SOSI ( PTEMA, LTEMA, FTEMA og TTEMA) blir derfor en spesiell egenskap benyttet til primærklassifisering av data. Mer nyansert koding foregår ved å beskrive objektenes virkelige egenskaper. Historiske årsaker gjør at for enkelte datatyper er tema benyttet i større utstrekning enn kanskje ønskelig.

Egenskaps-informasjon kan knyttes både til hele datagrupper (gruppeinformasjon) og til enkeltpunkt innen en datagruppe (punktinformasjon).

Egenskapsopplysninger angis med et SOSI-navn og tilhørende verdi (eks: ..PTEMA 1000, eller ..KVALITET 50 500).

Både gruppeinformasjon og punktinformasjon kan opptre i ulike mengder. Samme egenskapstype kan opptre flere ganger med ulik verdi (multiple egenskapsopplysninger). Eksempel på dette er eiendomsgrense som både er eiendomsgrense og bekk samtidig. Merk videre at samme SOSI-navn kan benyttes både i gruppe- og punktinformasjonsdelen.

I tillegg til “vanlig” egenskapsinformasjon inneholder gruppe- og punktinformasjonsdelen spesielle funksjons- opplysninger slik som RADIUS, STORSIRKEL etc.

Før en går mer i detalj i beskrivelsen av SOSI-fila, følger her et eksempel på sosi-fil (skissemessig). (Husk at “!” er kommentartegn i SOSI)

SOSI-filens
hode.


Innhold

behandles senere








Kommentar i hode

 


Grafisk element

 

Grafisk element
LINJE.
(eiendomsgrense
og kommunegrense)






Punktinfo:

(Grensetre)

Punktinfo:
(kors i fjell)

Knutepunkt



Grafisk element
KURVE (bekk)

hvor den ene
enden er
knutepunkt.


Grafisk element .
BUE.
(Eiendomsgrense)
RADIUS alltid
i meter.


Grafisk element

TEKST

Teksten definert
med STRENG
Skal skrives ved
punkt 2.

Grafisk objekt
FLATE
(Eiendomsteig
m/sentralpunkt:

Gnr 5 Bnr 7
Ringsaker komm)


Slutt på data

.HODE
..TRANSPAR
...KOORDSYS 5
...ORIGO-NØ 100000 10000
...ENHET 0.010
...VERT-DATUM NN54 SJØ0
..OMRÅDE
...MIN-NØ 100000 10000
...MAX-NØ 102400 13200
..SOSI-VERSJON 2.2
..SOSI-NIVÅ 4
!
..DATO 19890623
..KVALITET 11 300
!
! data er bare delvis synfart.
!
..EIER "Statens Kartverk"
..PRODUSENT "NORKART A/S"
!
.PUNKT 1:
PUNKT. ..PTEMA 1000
(fastmerke) ..NØ
23456 2345
-
.LINJE 250:
..LTEMA 4003
..LTEMA 4011
..KVALITET 40 58
..NØ
23456 2345
23460 2345
23470 2346
23480 2347
23490 2350
23500 2366 ...PTEMA 4065
...KVALITET 40 400
..NØ
23512 2345
23565 2350 ...PTEMA 4072
..NØ
3565 2370
23460 2356 ...KP 1
..NØ
23500 2350
-
.KURVE 223:
..LTEMA 3211
..KVALITET 51 200
...NØH
23456 2345 123 ...KP 1
..NØ
23460 2360 123
-
BUE 312:
..LTEMA 4011
..RADIUS -593.56
..NØ
23456 2345
23480 2367
-
.TEKST 298:
..TTEMA 3101
..STRENG "Valbjørg-vatnet"
..NØ
23467 2350
23400 2400
-
-
-
.FLATE 305:
..FTEMA 4011
..KOMM 0412
..EKODE 1
..ARKODE 1
..GID 5 7
..REF :3 :-5 :58
..NØ
23487 2365
.SLUTT

 

4 HODET PÅ SOSI-FILA

4.1 Generelt

Hodet på SOSI-fila inneholder opplysninger som gjelder for hele fila. Noen opplysninger i hodet gjelder koordinatene, mens andre gjelder egenskapsopplysninger for data på fila. Opplysningene som gjelder koordinatene (..TRANSPAR og ..OMRÅDE ) må alltid være med i en SOSI-fil.

Forholdet mellom informasjon i HODE og gruppeinfo og punktinfo er slik at det som står i HODE gjelder for alle datagrupper på fila hvor aktuell informasjon ikke er endret i gruppeinfo eller punktinfo. Tilsvarende fungerer forholdet mellom gruppeinfo og punktinfo.

Det er altså slik at hvis en fil inneholder data om en egenskap (f.eks kommunenummer) vil kommunen kunne angis i filens hode i stedet for på hver datagruppe nede på fila. Skulle så noen få datagrupper ligge i en annen kommune vil dette kunne spesifiseres direkte på de aktuelle datagrupper. Alle andre datagrupper vil tilhøre kommunen angitt i hodet. Kanskje det mest aktuelle eksempel på denne teknikk er bruken i forbindelse med kvalitetsopplysningene, på data fra en type datafangst.

Informasjon på gruppenivå overstyrer informasjon i hodet. I en del tilfeller kan det være bare en eller flere verdier innen et SOSI-gruppelement som overstyres, som f.eks ved kvalitet. Her benyttes * for å angi at verdi mangler, og @ for å henvise til tilsvarende verdi på neste høyere nivå.

.HODE
..TRANSPAR
...KOORDSYS 3
...ORIGO-NØ 100000 10000
...ENHET 0.100
...OMRÅDE
...MIN-NØ 266400 57600
...MAX-NØ 268800 60800
..KVALITET 22 60 0 22 60
..SOSI-NIVÅ 4
.KURVE 1:
..LTEMA 3001
..DATO 19870617
..KVALITET * * 2 * * !(Ukjent målemetode og nøyaktighet i grunnriss og høyde, men middels synlig i flybilde, UMULIG)
..NØ 12345 45678 12356 23456
.KURVE 2:
..LTEMA 3001
..KVALITET @ @ 2 !(Målem. 22 og nøy. 60 , men middels synl.

NB. Ved dårlig synbarhet er det ønskelig å beskrive korrekt nøyaktighet, ikke bare henvise til tidligere verdi.

Nedenfor følger et eksempel på et SOSI-hode for kartdata.

.HODE
..TRANSPAR
...KOORDSYS 3 NGO48 NGO48
...ORIGO-NØ 100000 10000
...ENHET 0.100
...ENHET-D 0.1
...ENHET-H 1.0
...VERT-DATUM NN54 SJØ0 HSH O
..OMRÅDE
...MIN-NØ 266400 57600
...MAX-NØ 268800 60800
..SOSI-VERSJON 2.2
..SOSI-NIVÅ 4
..TEGNSETT DOSN8
..KARTID CX056-5-1
..DATO 19870617
..KVALITET 50 200
..PRODUSENT "Viak A/S"
..EIER "Statens Kartverk"

En del elementer skal ligge i hodet på en SOSI-fil, her vist som et eksempel:

.HODE
..TRANSPAR
...KOORDSYS 3
...ORIGO-NØ 100000 10000
...ENHET 0.100
..OMRÅDE
...MIN-NØ 266400 57600
...MAX-NØ 268800 60800
..SOSI-VERSJON 2.2
..SOSI-NIVÅ 4
..TEGNSETT DOSN8

I de SOSI-filer som ikke har ...HØYDE-REF ligger det implisitt at det er benyttet NN54 / NNN57. Det oppfordes imidlertid til alltid å lagre informasjon om høydereferensen i SOSI-fila.

4.2 Transformasjonsparametre

Hensikten med transformasjonsparametre i hodet er å definere horisontalt og vertikalt datum, origo og oppløsning (enhet) for de koordinater som ligger på fila, slik at den som leser koordinatene nedenfor blir i stand til å beregne METER i terrengmålestokk (evt geografiske sekunder) i et aktuelt koordinatsystem.

TRANSPAR defineres slik:

.DEF
..TRANSPAR *
...KOORDSYS *
....SYSKODE H4
....DATUM T35 ! Forklarende tekst
....PROJEK T35 ! Forklarende tekst
...ORIGO-NØ *
....ORIGO-N H8
....ORIGO-Ø H8
...ENHET D6 ! Enhet generelt
...ENHET-H D6 ! Enhet høyde
...ENHET-D D6 ! Enhet dybde
...VERT-DATUM *

....HØYDE-REF
T5
....DYBDE-REF
T5
....FRISEIL-REF T5
....HØYDETYPE T1

4.2.1 KOORDSYS

KOORDSYS angir hvilket koordinatsystem (eller akse) koordinatene på fila tilhører. Hele fila må inneholde koordinater fra bare ett koordinatsystem.

Overgangen til WGS84 muliggjør ulike projeksjoner basert på dette datum, i tillegg til de tidligere kjente. Den spesifiserte form av WGS84 som brukes i Norge betegnes EUREF89. Tidligere var f.eks UTM alltid basert på ED50, mens en nå kan få UTM basert på WGS84. Imidlertid er ikke alle kombinasjoner av datum og projeksjon lovlige, slik at lovlige kombinasjoner kan beskrives entydig gjennom KOORDSYS. For en del spesielle kombinasjoner av datum og projeksjon kan det implementeres en brukerdefinert definisjon av kombinasjonen, samt transformasjonsparametere for transformasjon over til en kjent kombinasjon av datum og projeksjon.

Koord sys

Beskrivelse

Datum

Projeksjon

Akse/-sone

1

NGO-akse I

NGO1948

Gauss-Krüger

1

2

NGO-akse II

NGO1948

Gauss-Krüger

2

3

NGO-akse III

NGO1948

Gauss-Krüger

3

4

NGO-akse IV

NGO1948

Gauss-Krüger

4

5

NGO-akse V

NGO1948

Gauss-Krüger

5

6

NGO-akse VI

NGO1948

Gauss-Krüger

6

7

NGO-akse VII

NGO1948

Gauss-Krüger

7

8

NGO-akse VIII

NGO1948

Gauss-Krüger

8

9

NGO 48

NGO48 Geografisk

Ingen

Ingen

21

UTM-Sone 31

EUREF89/WGS84

UTM

31

22

UTM-Sone 32

EUREF89/WGS84

UTM

32

23

UTM-Sone 33

EUREF89/WGS84

UTM

33

24

UTM-Sone 34

EUREF89/WGS84

UTM

34

25

UTM-Sone 35

EUREF89/WGS84

UTM

35

26

UTM-Sone 36

EUREF89/WGS84

UTM

36

31

UTM-Sone 31

ED50

UTM

31

32

UTM-Sone 32

ED50

UTM

32

33

UTM-Sone 33

ED50

UTM

33

34

UTM-Sone 34

ED50

UTM

34

35

UTM-Sone 35

ED50

UTM

35

36

UTM-Sone 36

ED50

UTM

36

41

Lokalnett, uspes.

42

Lokalnett, uspes.

50

ED50 Geografisk

ED50

Ingen

Ingen

51

NGO-56A (Møre)

NGO1948

Gauss-Krüger

52

NGO-56B (Møre)

NGO1948

Gauss-Krüger

53

NGO-64A (Møre)

NGO1948

Gauss-Krüger

54

NGO-64B (Møre)

NGO1948

Gauss-Krüger

72

WGS72 Geografisk

WGS72

Ingen

Ingen

84

WGS84 Geografisk

WGS84

Ingen

Ingen

87

ED87 Geografisk

ED87

Ingen

Ingen

99

Egendefinert

101

Lokalnett, Oslo

102

Lokalnett, Bærum

103

Lokalnett, Asker

104

Lokalnett, Lillehammer

105

Lokalnett,Drammen

106

Lokalnett, Bergen / Askøy

107

Lokalnett, Trondheim

Eksempel:

Eksempel 1

Eksempel 2

.HODE 0:

..TRANSPAR

...KOORDSYS 31

...ORIGO-NØ 0 0

...ENHET 1.000

..OMRÅDE

...MIN-NØ 6450 -1200

...MAX-NØ 8060 11500

.HODE 0:

..TRANSPAR

...KOORDSYS 99 "WGS84" "Lambert's ekv.asimut"

...ORIGO-NØ 0 0

...ENHET 1.000

..OMRÅDE

...MIN-NØ 6450000 -1200000

...MAX-NØ 8060000 11500000

UTM-akse 31 basert på ED 50

Ortografisk ekvivalent asimutal projeksjon basert på datum WGS84.

4.2.2 TRANSSYS

I tilfeller der de foreslåtte kodene ikke er tilstrekkelig, benyttes et annet SOSI-element for å gi en beskrivelse av overgang til kjent datum og projeksjon.

Definisjon

Kodeverdi

Forklaring

.DEF

..TRANSSYS

...TILSYS

...KONSTA1

...KONSTB1

...KONSTA2

...KONSTB2

...KONSTC1

...KONSTC2

*

H4

D20

D20

D20

D20

D20

D20

Offisiell SYSKODE

Transformasjonsparameter

Transformasjonsparameter

Transformasjonsparameter

Transformasjonsparameter

Transformasjonsparameter

Transformasjonsparameter

Det forutsettes at den valgte tilsys-koden er en standard SYSKODE.

Transformasjonsformelen :

• NTIL=KONSTC1 + KONSTA1 * NORD + KONSTA2 * ØST
• ØTIL=KONSTC2 + KONSTB1 * NORD + KONSTB2 * ØST
• NTIL er nord-koordinat i TILSYS
• ØTIL er øst-koordinat i TILSYS
• NORD er eksisterende nord-koordinat i fila.
• ØST er eksisterende øst-koordinat i fila.
Denne transformasjonen er er affin transformasjon. Transformasjon mellom ulike projeksjoner bør kun skje i lokale områder.

4.2.3 ORIGO

Origo er en addisjonsfaktor som må benyttes for alle koordinater nede i fila for å få reelle terrengkoordinater. Origo(..ORIGO-NØ) består av en nord-verdi(...ORIGO-N) og en øst-verdi(ORIGO-Ø).

Både ORIGO-N og ORIGO-Ø angis i hele meter i terrengkoordinater (eller sekunder for geografiske koordinater) innenfor det koordinatsystem som er angitt. Origo for høyde er alltid 0 (aktuell for ..NØH).

4.2.4 ENHET

Med ENHET forstås den faktor som koordinatene nede på på SOSI-fila (FIL-N, FIL-Ø og FIL-H) må multipliseres med for å få meter. Formelen for beregning av terrengkoordinater blir da:

NORD=ORIGO-N + FIL-N * ENHET
ØST=ORIGO-Ø + FIL-Ø * ENHET
HØYDE=0 + FIL-H * ENHET

Dersom ENHET-H er satt er HØYDE=0 + FIL-H * ENHET-H

Dersom ENHET-H og ENHET-D ikke er satt, gjelder verdien for ENHET generelt. ENHET på gruppenivå overstyrer ikke eventuell ENHET-H eller ENHET-D i filhode.

ENHET kan opptre som gruppeinfo på enkeltgrupper nede på selve fila, og gjelder da bare den aktuelle datagruppe. Dette betyr i praksis at en kan ha ulik oppløsning/nøyaktighet på koordinater på samme fil. Dette er spesielt aktuelt når bare noen data har høy nøyaktighet, mens storparten har lav nøyaktighet eller motsatt.

4.2.5 VERT-DATUM

Det er naturlig å beskrive topografien på land ved den vertikale avstand fra havets overflate. Det har likeledes vært naturlig å velge havets gjennomsnittelige overflate, men også andre vannstandsnivåer inngår som informasjon på enkelte kartserier. Denne vertikale avstanden kalles høyde. Under havflaten betegnes avstanden til havbunnen dybde. Denne har stort sett en annen referanseflate.

Fram til i dag har SOSI-data sjelden hatt informasjon om vertikalt datum. Dette har ligget implisitt i form av det offisielle høydesystemet, som har vært “Norsk null av 1954” og “Nord-norsk null av 1957”. Innføringen av EUREF89 samt bedre geoideberegninger gir nå større valgmuligheter.

Et norsk sjøkart har flere referensenivåer: referensenivå for dybder (sjøkartnull), referensenivå for friseilingshøyder og referansenivå for kystkonturen. Den siste er beskrevet under kyst og sjø-kapittelet, og innlemmes ikke her.

Noen begrepsoppklaringer:

Dybde
Den vertikale avstanden fra et gitt referensenivå til sjøbunnen/innsjøbunnen.

Høyde
Uttrykk for punkters beliggenhet i vertikal retning. Høyde regnes vanligvis relativt til en fysisk eller matematisk definert referanseflate som ligger eksakt eller tilnærmet horisontalt.

Høyvann
Den høyeste vannstand som inntreffer på et sted i løpet av en tidevannsperiode

Lavvann
Den laveste vannstand som inntreffer på et sted i løpet av en tidevannsperiode.

Midlere vannstand
Nivået midt mellom middel høyvann og middel lavvann.Dette nivået kan være noe forskjellig fra middelvann.

Sjøkartnull Vårjevndøgn spring lavvann.

 

.DEF
..VERT-DATUM *
...HØYDE-REF T5 !NN54 Norsk Null av 1954

!NNN57 Nord-Norsk Null av 1957

!ELLIP Ellipsoide jfr KOORDSYS
!NKG89 Geoide bestemt av NKG i 1989

!<cm> Lokal referenseflate, angitt i det
!
antall cm som må legges til høyde-
!
referensen for å få NN54/NNN57

!

...DYBDE-REF T5
!SJØ0
Sjøkartnull

!HREF Høyeste vannstand i reg. vann

!LREF Laveste vannstand i regulert vann

...FRISEIL-REF T5
!HSH Høstjevndøgns spring høyvann
!HREF
Høyeste vannstand i reg. vann

!LREF Laveste vannstand i regulert vann

...HØYDE-TYPE T1
!O Ortometrisk (Standard)
!N Normal

!D Dynamisk

I de SOSI-filer som ikke har ...HØYDE-REF ligger det implisitt at det er benyttet NN54 / NNN57. Det oppfordes imidlertid til alltid å lagre informasjon om høydereferensen i SOSI-fila.

HØYDE-REF beskriver referenseflate for høydene, dvs. den refersnseflate som er utgangspunkt for høydefastsettelsen.

DYBDE-REF beskriver referenseflate for dybdene, dvs. den referenseflate som er utgangspunkt for dybdefastsettelsen.

FRISEIL-REF beskriver referenseflate for friseilingshøyde, dvs. den referenseflate som er utgangspunkt for friseilingshøyden.

HØYDETYP beskriver ulike typer høyder:

Ortometrisk høyde
Et punkts avstand fra geoiden, målt langs loddlinjen, basert på stedets lokale tyngdefelt.. Med høyde over havet menes i Norge ortometrisk høyde.

Normal høyde
Ortometrisk høyde beregnet med den forutsetning at jordens tyngdefelt er normalt, dvs refererer seg til en idealisert jordellipsoide.

Dynamisk høyde
Differense mellom geopotensialet i et punkt og geopotensialet i havnivå, dividert med en konstant gitt ved normaltyngden i havnivå ved 45 graders bredde. Regnes positiv fra havnivå og oppover.

Det er snakk om små differanser mellom ortometrisk og normal høyde, og er bare nødvendig der høydene er oppgitt med stor nøyaktighet (presisjonsnivellement).

Skisse over sammenheng mellom definisjoner

Undisplayed Graphic

MV Midlere vannstand
MHV Midlere høyvannstand
Geoiden er stort sett sammenfallende med middelvannstand. Det vil imidlertid forekomme mindre avvik grunnet vannopphoping som blant annet skyldes coreolis kraft. Middelvannstanden kan være opp mot 1 meter fra geoiden.

Frihøyde:

Undisplayed Graphic

4.3 Område-definering

Hensikten med områdeangivelsen i hodet er at mottakere av data på SOSI-fila skal vite hvilket område data ligger innenfor slik at man kan utnytte dette ved base-genereringer e.t.c. Området angis i hele meter i det aktuelle koordinatsystem.

Formelt defineres OMRÅDE slik:

.DEF
..OMRÅDE *
...MIN-NØ *
....MIN-N H8
....MIN-Ø H8
...MAX-NØ *
....MAX-N H8
....MAX-Ø H8


Område skal alltid være med i hodet på en SOSI-fil, og skal se slik ut:

..OMRÅDE
...MIN-NØ 100000 10000
...MAX-NØ 102400 13200

4.4 Kartbladident (kartbladindeks)

Ofte vil en SOSI-fil bestå av et område avgrenset av et kartblad i en eller annen serie. Dette bør i så fall angis med SOSI-navnet KARTID. Ønsker du å angi flere kart, eller deler av kart kan dette gjøres med å skrive teksten inni " ". Husk at du har inntil 35 posisjoner til disposisjon innefor begrepet KARTID.

KARTID defineres slik:

.DEF
..KARTID T35

Merk ellers at kartbladindekser skal skrives uten mellomrom. Her er noen eksempler:

..KARTID CX035-05-50-4 ! Tekn. kart 1:500
..KARTID CX035-1-60 ! Tekn. kart 1:1000
..KARTID CX035-5-1 ! ØK 1:5000
..KARTID 1912-1 ! M711-serien 1:50000

4.5 Innholdsfortegnelse

Det er ofte aktuelt og nyttig å kunne angi innholdet av en fil på SOSI-format i form av hvilke geografiske objekter en kan vente å finne der. Dette er muliggjort ved HODE-opplysningen INNHOLD. Dette er informasjon som ikke kan legges ned på den enkelte objektene

.DEF
..INNHOLD *
...FKB-DATA *
....FKB-NAVN T8 Kapittelnavn
....FKB-STD T1 bokstav for FKB-standard (A,B,C,D)
....FKB-OPSJ T1 hvis opsjoner er med, er verdien O
....FKB-VERSJON
T5 F.eks FKB-VERSJON 2.1
...BEGRENSNINGER

....MAX_ELEMENT_PKT H5 Max antall punkter i grafisk element
....MAX_OBJEKT_PKT H5 Max antall punkter i grafisk objekt
....MAX_REF_OBJEKT H5 Antall referenser (i flate/trase)

FKB-versjon er lagt inn for å kunne skille mellom en syntaktisk og en innoldsmessig oppdatering.

Eksempelet med FKB-versjon over sier at innholdet er i overensstemmelse med DEL3 i SOSI-versjon 2.1. Dvs. at enkelte objekter som f.eks er standard i SOSI-versjon 2.2 forstatt ikke nødvendigvis finnes i fila dersom disse f.eks var opsjon i versjon 2.1.

Teksten i FKB-NAVN skal være navn på kapitler definert i objekt-katalogen.

Eksempler :
..INNHOLD
...FKB-DATA BYGG A O ! Bygn.data, standard A med opsj.
...FKB-DATA HDB A ! Høydedata, std. A uten opsj.
...FKB-DATA DEK ! Digitalt eiendomskartverk
! standard og opsj. ikke relevant ...FKB-DATA VSIT B * 2.0 ! VSIT innhold jfr ver 2.0

Begrensninger er bare nødvendig å føre opp hvis antall punkter / referenser overstiger følgende verdier:

MAX_ELEMENT_PKT 2000 MAX_OBJEKT_PKT 10000 MAX_REF_OBJEKT 500

Hensikten med denne mekanismen er å sikre at antall punkter og referenser ikke er så høyt at det skaper problemer ved konvertering til ulike systemer. Dersom antallet overstiger disse verdiene skal dette avtales mellom leverandør og mottaker og dokumenteres i hodet på SOSI-fila.

Eksempler :

..INNHOLD
...MAX_PKT_ELEMENT 3000
...MAX_PKT_OBJEKT 12000
...MAX_REF_OBJEKT 600

I henhold til dette eksempelet garanterer leverandøren at det ikke er flere enn 3000 punkter pr grafisk element, ikke mer enn 12000 punkter i et grafisk objekt, og ikke mer enn 600 referenser i et objekt.

4.6 Tegnsett

Denne egenskapen angir hvilken tegnrepresentasjon som er benyttet på fila. (Dvs. hvilke 8(7)-bits koder tegnene har). Dette kommer spesielt til anvendelse ved tolkning av ÆØÅ, samt valg av tegnsett som støtter samiske tegn.

.DEF
..TEGNSETT T10

Følgende verdier gjelder:

..TEGNSETT DOSN8 (MS-DOS norsk 8-bits) (Standard)
..TEGNSETT ND7 (Norsk Data 7-bits)
..TEGNSETT DECM8 (DEC Multinational 8-bits)
..TEGNSETT DECN7 (DEC Norsk 7-bits)
..TEGNSETT ISO8859-1 (Unix-tegnsett )
..TEGNSETT ISO8859-10 (Samisk tegnsett)
..TEGNSETT ANSI (Windows-tegnsett)

De særnorske tegnene ÆØÅ er plassert på følgende koder:


DOSN8

ND7,DEC
N7

ISO8859-10


146

91

198

Æ
157

92

216

Ø
143

93

197

Å
145

123

230

æ
155

124

248

ø
134

125

229

å

Hvis ikke tegnsett er angitt i filhodet gjelder DOSN8. Flere tegnsett kan defineres etterhvert.

4.7 Opplysning om eier og produsent

SOSI-formatet er tenkt benyttet til datautveksling og lagring av digitale data, og det er da ganske aktuelt å kunne gi opplysninger om produsent og eier av data.

Dette gjøres ved hjelp av basisnavnene PRODUSENT og EIER slik:

..PRODUSENT "Viak A/S"
..EIER "Statens kartverk"

Med EIER forstås her rettighetshaver.
Definert slik:

.DEF .DEF
..PRODUSENT T35
..EIER T35

Oftest vil dette være en opplysning som skal ligge i hodet på en SOSI-fil, men det kan også være aktuelt å spre det ut på de enkelte datagrupper for data med ulike produsenter - eiere.

4.8 Opplysning om SOSI-versjon

For å ha oversikt over hvilken versjon av SOSI-formatet som er benyttet ved produksjon av fila, er det definert SOSI-navnet SOSI-VERSJON som skal legges i hodet på fila.

Definert:
.DEF
..SOSI-VERSJON T5 ! Eksempel (..SOSI-VERSJON 2.2)


4.9 Opplysning om SOSI-nivå

SOSI-formatet gir anledning til å beskrive kompleksitetsnivået. Det er definert 4 ulike nivåer som data kan opptre i.

..SOSI-NIVÅ 1 :









..SOSI-NIVÅ 2 :






..SOSI-NIVÅ 3 :




..SOSI-NIVÅ 4 :

Dette er den enkleste form en kan
overføre data på i SOSI.
Her er det bare tillatt med en egen-
skapsopplysning pr. grafisk element,
og det er ikke lov med
punktinformasjon.
(Etter de kodeprinsipper som er brukt
i DEL-3 er denne metoden nærmest
ubrukbar selv til vanlige kart.)

Dette nivået dekker alt som har med
koding av data å gjøre.
I dette nivå finner en multiple
egenskaper samt punktinformasjon.
Nivået dekker ikke bruk av knutepunkt
og definering av grafiske objekter.

Dekker nivå 2, men i tillegg er knute-
punkt implementert. Data på SOSI-NIVÅ 3
indikerer altså at data er renset i
krysningspunkt, og at krysningspunktene
er etablert som ...KP

Dekker nivå 3. I tillegg er det
på dette nivå mulig å overføre grafiske
objekter. (FLATE, TRASE osb.)
I nivå 4 er bruk av serienummer/
referansenummer innført.

SOSI-NIVÅ legges inn i SOSI-filens hode, og angir høyeste kompleksitet som kan påtreffes i fila. Det er derimot ikke noen garanti for at alt i fila er på ønsket nivå.

Definert:
.DEF
..SOSI-NIVÅ H1 ! Eksempel (..SOSI-NIVÅ 2)

4.10 Merknader

Andre opplysninger som kan være bekvemme å ha i hodet på SOSI-fila kan enten legges inn som merknader, eller som verdier til egne definerte basiselementer. Merknader kan forøvrig komme hvor som helst i SOSI-fila hvis de er innledet med merknadstegnet "!".

Merknader kan legges hvor som helst i fila, men fortrinnsvis i hodet. Merknader andre steder i fila er vanskelig tilgjengelig for brukerne, og anbefales ikke benyttet.

Merknader er det eneste i SOSI som må avsluttes med linjeskifttegn; for alle andre steder oppfattes ‘blank’ som linjeskift

5 Geometrimodell

Figuren viser en fullstendig geometrimodell for SOSI , både med tanke på grafiske elementer og grafiske objekter.

 

Undisplayed Graphic

6 BESKRIVELSE AV GRAFISKE ELEMENTER

6.1 Innledning

Selve dataene i SOSI-formatet for beskrivelse av objektene består av grafiske elementer eller grafiske objekter.

Et grafisk element er et gruppeelement som består av et gruppenavn (eks. PUNKT, LINJE, KURVE etc) med serienummer, tilhørende koordinater og aktuell egenskapsinformasjon. Et grafisk element kan også beskrives som geometrisk element.

Hvert grafisk element definerer ved hjelp av koordinater en geometri som skal benyttes ved all databehandling. I tillegg til koordinatene benyttes i noen tilfeller noen spesielle egenskapsnavn til å beskrive geometriske forhold. (Eks. RADIUS i BUE).

6.1.1 Koordinater

Koordinater nede i fila (dvs. innen de grafiske elementer) er som før nevnt underlagt transformasjonsparameterene i HODE på fila. Det er et prinsipp at alle koordinater er heltall med en oppløsning lik den som defineres av ENHET. Med en ENHET=1.0 blir da koordinatene i hele meter (evt sekunder for geografiske koordinater), mens med ENHET=0.001 blir koordinatene i millimeter (millisekunder). (ENHET kan også som nevnt unntaksvis forekomme på enkelt-datagrupper.)

Koordinater kan angis med tre gruppenavn avhengig av om vi benytter to eller tre “dimensjoner”:

..NØ
...NORD 156466
...ØST 12476

..NØH
...NORD 156466
...ØST 12476
...H 1234
..NØD
...NORD 156466
...ØST 12476
...D 1234

Dette skal struktureres slik:

..NØ
156466 12476
..NØH
156466 12476 1234
..NØD
156466 12476 1234

eller når flere koordinater:


..NØ
156466 12476
156476 12477 156480 12476

..NØH
156466 12476 1234
156476 12477 1234
156480 12476 1234

..NØD
156466 12476 1234
156476 12477 1234
156480 12476 1234

 

Formelt er koordinat gruppe-elementene definert slik:

.DEF
..NØ *
...NORD H10
...ØST H10

.DEF
..NØH *
...NORD H10

...ØST H10

...H H8
.DEF
..NØD
*
..NORD H10
...ØST H10
...D
H8

 

Høydeverdien kan for enkeltpunkt, eller linjer/kurver med samme høyde (eks. høydekurver) angis med det spesielle egenskapsnavnet HØYDE som er definert til å være punktets høyde over høydereferensen angitt i meter med eventuelle desimaler.

Et punkt kan angis i de 3 “dimensjoner” på en av disse metodene:

..HØYDE 232.3
..NØ 1234567 1234567

..NØH
123456 123456 2323
..NØD
123456 123456 2323

For grafiske elementer med flere enn en koordinat (linje,kurve etc) og med samme høydeverdi (eks. høydekurver) eller dybdeverdi, skal en benytte HØYDE eller DYBDE.

Innen en og samme datagruppe tillates at koordinatene kan være både med og uten høyde, se følgende eksempel:

.LINJE 133:
..LTEMA 7001
..NØ
123456 12345
123460 12346
..NØH
123470 12350 123
123467 12345 123
123466 12365 124
..NØ
123489 12385


6.1.2 Knutepunkt

Knutepunkt er en spesiell opplysning (mekanisme) knyttet til i prinsippet alle de grafiske elementer.

• Med knutepunkt har vi i SOSI flere ulike mekanismer. Nodepunkt mellom 2 eller flere grafiske elementer. Disse elementene er sammenknyttet i nodepunktet, og har felles koordinater.

• Konnekteringspunkt. Dette er en geometrisk sammenknytning mellom to eller flere grafiske elementer, men konnekteringspunktet er ikke lagt inn på alle elementene. Et eksempel på dette er en bygningslinje som konnekteres mot en husvegg, uten at denne får lagt inn konnekteringspunktet.

• Kontrollpunkt med reservert betydning. både for ekstern og intern bruk.

• Lovlig endepunkt. Dvs. endepunkter i datagrupper som ikke skal knyttes mot andre datagrupper.

Punkt innen et grafisk element som er knutepunkt markeres med den spesielle punktinformasjonen ...KP samt et lagnummer som kan variere hvis fila inneholder flere lag med knutepunkt. KP er i SOSI definert slik:

.DEF
..KP H3
!<1 - 899>
Lagnummer for ulike nodepunkt-lag
!<900-989>
Konnekteringspunkter
!<990-998>
Kontrollpunkt/Reservert betydning
!<999>
Lovlig endepunkt/løs ende

Lagnummer har ikke definerte verdier i SOSI-databeskrivelseskapitlene. Disse må evt. avtales mellom avsender og mottaker.

Eksempel:

.LINJE 53: .
..LTEMA 4011
..NØ
123456 222222 ...KP 7
..NØ
233687 123589
256999 666666
333333 269875
..NØ
123589 999992
778899 588836
123544 555555 ...KP 8



---+
|
|
|
|
|
+----
LINJE 55:
..LTEMA 4021
..NØ
589698 369890
598777 639000
369555 444444
599999 699888
123544 555555 ...KP 9
..NØ
123456 222222 ...KP 7

Oftest vil data bare inneholde ett knutepunktslag, og da benyttes verdien ...KP 1. I andre tilfeller vil en kunne avgrense sammenknytning mot ulike knutepunktslag hvor f.eks. alle tellekurver tildeles lag 10, mens depresjonskurver tildeles lag 11.

Et nodepunkt representeres altså på SOSI-fila ved at punktet har ...KP med samme lagnummer og at punktet ligger lagret med eksakt samme koordinat på alle aktuelle datagrupper.

Kodene 990 til 998 er ment for intern bruk i en kvalitetskontrollprosess eller produksjonsprosess. Disse har ingen standard betydning, men benyttes ulikt av ulike aktører. Statens kartverk benytter følgende for internt bruk:

993 Samme knutepunkt har ulik punktinformasjon i de respektive datagrupper
994 Høydefeil i felles knutepunkt
995 Korte (små) datagrupper ( Antageligvis rusk)
996 Skjæring mellom linjer nær knutepunkt (småpolygon)
997 Parallelle linjer ut fra knutepunktet
998 Konsistensfeil / løs ende ved endepunkt.

Knutepunkt kan ligge enten på endene av datagruppene eller inni datagruppene. En datagruppe kan altså ha ingen, ett eller flere knutepunkt.

Kodene 990 - 998 skal ikke være benyttet på en SOSI-fil som distribueres, kun for internt bruk.

6.1.3 Sammenknytning i ulike dimensjoner.

I utgangpsunktet skal objekter knyttes sammen i den dimensjon de er representert i.. Objekter med 3 dimensjoner skal knyttes sammen i nord , øst og høyde, og objekter i 2D knyttes sammen i nord og øst.

Imidlertid vil det i enkelte tilfeller være behov for å knytte sammen 2D med 3D objekter, uten at høydene midles. I disse tilfellene vil punktene være knytta sammen kun i grunnriss. Eksempel på dette finnes i bygningsdata. I disse tilfellene trenger ikke 2D-objekter å arve høyden (*NB - Sjekk med syntaksen)

Objekter i enkelte sammenhenger knyttes sammen i grunnriss selv om høydene er ulike. Dette er da beskrevet i de respektive databeskrivelsekapitlene, kartleggingsstandarden (SOSI-DEL3) eller eventuelt registreringsinstruks(SOSI-DEL5), eller som merknad i hodet på SOSI-fila.

6.1.4 Tema- og egenskaps-informasjon

Egenskapsinformasjon legges inn i hvert grafisk element eller grafisk objekt etter behov ved hjelp av SOSI-formatets konkateneringsmekanisme. Dette kan gjøres både i form av gruppeinfo og punktinfo. Egenskapsopplysninger med tilhørende koder er nærmere behandlet annet sted i dokumentet.

6.2 Grafisk element: PUNKT

Det grafiske elementet PUNKT er et enkelt punkt ( frittstående) som kan være enten 3-”dimensjonalt” (nord,øst og høyde) eller 2-”dimensjonalt” (Nord og øst) . PUNKT kan ha både gruppeinfo og punktinfo, men mest vanlig er at PUNKT bare har gruppeinfo.

2-”dimensjonalt”

.PUNKT 5:
..PTEMA 1000
..KOMM 0412
..FMID KOMM 001210
..ENHET 0.001
..KVALITET 10 20
..NØ
123456 12345

.PUNKT 5:
..PTEMA 4011
..GID 512 7 5 .
..KVALITET 50 500
..NØ
123456 12345
3-”dimensjonalt”

.PUNKT 5:
..PTEMA 1000
..KOMM 0412
..FMID KOMM 001210
..ENHET 0.001
..KVALITET 10 20
..NØH
123456 12345 123

.PUNKT 5:
..PTEMA 4011
.GID 512 7 5
..KVALITET 50 200
..NØH
123456 12345 123

6.3 Grafisk element: SVERM

Det grafiske elementet SVERM benyttes for å angi flere frittstående punkt med nøyaktig samme gruppeinformasjon. Punktene i en sverm kan være enten 3- eller 2-”dimensjonale”. SOSI-layout på SVERM ligner på LINJE, men for SVERM skal altså ikke forbindelsen mellom punktene trekkes opp. For store enkeltpunktmengder med samme egenskaper vil SVERM kunne kompaktifisere SOSI-fila kraftig.

Her er et eksempel:

2-”dimensjonalt”

.SVERM 5:
..PTEMA 1000
..KVALITET 10 20
..NØ
123456789 12345678
123456781 12345678
123456782 12345678
123456783 12345678
123456784 12345678
123456785 12345678
3-”dimensjonalt”

.SVERM 5:
..PTEMA 1000
..KVALITET 10 20
..NØH
123456789 12345678 123456
123456781 12345678 123456
123456782 12345678 123456
123456783 12345678 123456
123456784 12345678 123456
123456785 12345678 123456


6.4 Grafisk element: LINJE

Det grafiske elementet LINJE består av flere punkt i en sekvens der hvert punkt har en bestemt posisjon. Hvert punkt i linja er kartlagt spesielt slik at en ikke uten videre kan flytte punkt langs linja, selv om geometrien (avbildningen) av linja ikke forandres.

LINJE kan være enten 3 “dimensjonal” eller 2 ”dimensjonal”.

En LINJE vil se slik ut

Undisplayed Graphic

LINJE kan ha både gruppeinfo og punktinfo. For LINJE er det spesielt vanlig med punktinfo for å fortelle om beskaffenheten til enkeltpunkt i linja. Det er også vanlig med knutepunkt på linjer.

Nedenfor er et eksempel på to linjer med tilhørende koding. Pilene angir i hvilken rekkefølge koordinatene ligger på fila.

Undisplayed Graphic

Dette kodes i SOSI slik:

.LINJE 37:
..LTEMA 4011
..KVALITET 10 13
..NØ
123456 12345
123450 12380
...PTEMA 4062
..NØ
123457 12420
...PTEMA 4052
..NØ
123452 12456
...PTEMA 4062
..NØ 123460 12496
...PTEMA 4062
..NØ
123461 12530
...KP 1
.LINJE 47:
..LTEMA 4011
..KVALITET 10 13
..NØ
123350 12620
...PTEMA 4062
..NØ
123360 12600
..NØ
123390 12580
..NØ 123425 12550
..NØ
123461 12530
...KP 1
...PTEMA 4062
..NØ
123470 12551
123500 12580
...PTEMA 4065
...KVALITET 50 200
..NØ
123530 12601
...PTEMA 4061

Legg her merke til hvor det er nødvendig å skrive gruppenavnet for koordinater (..NØ eller ..NØH). Dette følger av de kompaktifiseringsregler og konkateneringsregler som SOSI- syntaksen har.

6.5 Grafisk element: KURVE

Det grafiske elementet KURVE er en kontinuerlig krum linje som er representert med en punktsekvens hvor hvert enkelt punkt i linjen ikke har noen spesiell betydning. Et punkt i en kurve kan altså flyttes uten videre hvis bare den geometriske avbildning av kurven ikke endres. En KURVE vil det være naturlig å glatte ved uttegning.

KURVE kan være både 3- og 2-”dimensjonal”.

KURVE har gruppeinfo. Punktinfo på kurve har ingen mening. Derimot vil det i dataene kunne være aktuelt å merke enkelte "posisjoner" i en kurve som knutepunkt (både på enden og inne på kurven).

Nedenfor følger en kurve i begge “dimensjoner”.

.KURVE 59:
..LTEMA 3001
..KVALITET 50 200
..NØ
123455 123456
...KP 1
..NØ
123456 123457
123457 123460
123458 123463
123459 123464
123460 123466
123460 123468
123462 123470
123463 123478
...KP 1
..NØ
123464 123479
123465 123484
123466 123485
123467 123490
.KURVE 59:
..LTEMA 3001
..KVALITET 50 200
..NØH
123455 123456 1234 ...KP 1
..NØH
123456 123457 1234
123457 123460 1235
123458 123463 1236
123459 123464 1237
123460 123466 1238
123460 123468 1239
123462 123470 1240
123463 123478 1241 ...KP 1
..NØH
123464 123479 1242
123465 123484 1243
123466 123485 1244
123467 123490 1245

6.6 Grafisk element: BUE

Det grafiske elementet BUE definerer en sirkelbue mellom 2 punkt A og B. For å få dette til innføres to spesielle SOSI basiselementnavn, i tillegg til koordinater (NØ).

6.6.1 RADIUS

Radius angis i meter med passelig mange desimaler.

Hvis positiv radius krummer buen mot høyre mellom A-B. Hvis negativ radius krummer buen mot venstre mellom A-B. (Eller sagt på en annen måte: Hvis sentrum er til høyre for deg når du beveger deg fra A-B er radius positiv.)

RADIUS er basiselement og defineres slik:

.DEF
..RADIUS D10

6.6.2 STORBUE

Storbue benyttes bare når vi ønsker å angi at det er den største av de to mulige buene vi vil ha. Dette angis da med ..STORBUE 1.

STORBUE er basiselement og er definert slik.

.DEF
..STORBUE H1

6.6.3 Koordinater (NØ)

I prinsippet er bare to koordinater aktuelle i en BUE, endepunktene A og B. Imidlertid kan man tillate seg å forenkle sirkelbuen med enkelte punkt på denne hvis en ønsker dette. Slike punkt legges da mellom første og siste punkt, slik at det er første og siste punkt i datagruppa BUE som gjelder. Disse sammen med RADIUS og evt. STORBUE gir eksakt definisjon av sirkelbuen.

.BUE 598:
..LTEMA 4011
..RADIUS 50.05
..NØ
111111 111111
222222 222222

Figur med bue som svinger mot høyre

Fra A mot B

+B

Undisplayed Graphic


+ A


.BUE 599:
..LTEMA 4011
..RADIUS -50.20
..NØ
111111 111111
222222 222222

Figur med bue som svinger mot venstre

Fra A mot B

+ B
Undisplayed Graphic

+ A

.BUE 600:
..LTEMA 4011
..RADIUS 50.02
..STORBUE 1
..NØ
111111 111111
222222 222222

Figur med bue som svinger mot høyre, og

storbue valgt

+ B
Undisplayed Graphic
+ A

Hvis vi ønsker noen punkt på sirkelbuen blir altså dette slik:

.BUE 600:
..LTEMA 4011
..RADIUS 50.02
..NØ
111111 111111
123456 123456 !Ikke fornuftige verdier
123456 123456
123456 123456
123456 123456
123456 123456
123456 123456
222222 222222

6.7 Grafisk element: BUEP

Det grafiske elementet BUEP (BUEPeriferi) definerer en sirkelbue mellom 2 punkt A og B ved hjelp av 3 koordinater, inkl. koordinatene for A og B.

.BUEP 601

..LTEMA 4011

..NØ

11111 11111

22222 234

33333 11111

Figur med bue

fra A via N til B

Punkt A

Via Punkt N

Punkt B

 

Undisplayed Graphic

6.8 Grafisk element: SIRKEL

Det grafiske elementet SIRKEL definerer en full sirkel med en gitt radius omkring ett punkt med oppgitt koordinat. SIRKEL angis tilsvarende BUE slik:

.SIRKEL 533:
..LTEMA 7011
..RADIUS 50.05
..NØ
111111 1111
.SIRKEL 533:
..LTEMA 7011
..RADIUS 50.05
..NØH
111111 111111 111111

Her er RADIUS definert som i BUE, men her er bare positive verdier aktuelle.

6.9 Grafisk element: SIRKELP

Det grafiske elementet SIRKELP (SIRKELPeriferi) definerer en full sirkel ved hjelp av 3 koordinater.

.SIRKELP 1:
..LTEMA 6313
..NØH
111111 11111 11111
222222 22 11111
333333 11111 11111

Vi kan også generelt tilnærmet beskrive en sirkelbue/sirkel ved hjelp av mange koordinater på buen. Dette gjøres da v.h.a. grafisk element .KURVE eller .LINJE.

6.10 Grafisk element: KLOTOIDE

Klotoide er benyttet bl.a. innen veg- og jernbanebygging, og er en matematisk beskrivelse av en spesiell overgang mellom rettlinje og sirkelbue. For matematisk definering av klotoiden henvises til lærebok.

Klotoiden beskrives med et startpunkt og et sluttpunkt, samt en startradius og en sluttradius og en parameter som forteller om krumningen. Nedenfor gis et eksempel hvor klotoiden beskriver en eiendomsgrense.

.KLOTOIDE 511:
..KLOTRAD1 -140.0
..KLOTRAD2 0.0
..KLOTPAR 70.0
..LTEMA 4011
..NØ
111111 111111
222222 222222

På samme måte som for BUE er det anledning til å angi punkt på “buen” som klotoiden danner. I så fall vil første og siste punkt bli å oppfatte som de som eksakt beskriver klotoiden. (For klotoider er nok dette svært aktuelt, da de færreste systemer har spesialhåndtering av klotoider).

KLOTRAD1 og KLOTRAD2 defineres tilsvarende RADIUS slik: De angis i meter med passelig mange desimaler. Hvis positiv radius krummer buen mot høyre. Hvis negativ radius krummer buen mot venstre. KLOTRAD1 og KLOTRAD2 er basiselement og defineres slik:

.DEF
..KLOTRAD1 D10

.DEF
..KLOTRAD2 D10

KLOTPAR definerer klotoideparameteren som et desimaltall:
.DEF
..KLOTPAR D10

 

6.11 Grafisk element: BEZIER

Dette er en 4 punkts bezier-kurve.

Bezier-kurven beskrives med et startpunkt og et sluttpunkt, samt to hjelpepunkter som beskriver tangentvektorene til endepunktene. Disse hjelpepunktene ligger ikke på kurven. Lengden av vektorene styrer utformingen av kurven mellom endepunktene. For matematisk definering av bezier-kurven henvises til lærebok, Computer graphics, principles and practice av Foley, van Dam, Feiner og Hughes s 488.

Flere bezier-kurver kan henges sammen til lengre kurver. Hvis den sammensatte kurven skal få et ‘glatt’ utseende må det være felles tangent i overgangen mellom hver kurve. Antall koordinater i gruppen må være 1 + (3*n) , der n er antall bezierkurver i gruppen. Knutepunkt kan bare forekomme i første og siste punkt i datagruppen.

Nedenfor gis eksempler på enkle og sammensatte bezier-kurver.

.BEZIER 511:
..LTEMA 7002
..NØ
9 47 !(P1)
15 94 !(P2)
84 12 !(P3)
88 67 !(P4)

 

Undisplayed Graphic

.BEZIER 511:
..LTEMA 4011
..NØ
9 47 !(P1)
15 94 !(P2)
84 12 !(P3)
88 67 !(P4)
90 79 !(P5)
142 78 !(P6)
138 101 !(P7)

 

Undisplayed Graphic


6.12 Grafisk element: TEKST

Tekstdata forutsettes i det alt vesentlige generert fra primE6‘rdatasett, og der hvor det er nødvendig, editert for å passe til det aktuelle formål.

Det grafiske elementet TEKST kan deles inn i 2 hovedgrupper

• Tekst i form av en tekststreng
• Tekst i form av symbol

Se eksempler under presentasjonsdatakapitlet.

For å klassifisere teksten benyttes vanligvis egenskapsopplysningen TTEMA og da med de samme kodeverdier som for PTEMA/LTEMA/FTEMA. Disse egenskaper vil jo ofte definere hva slags objekt teksten er benyttet på (eksempelvis vann, elv, kommune, veger etc.)

Tekst som genereres ut fra egenskaper i en presentasjonssammenheng og som ikke benytter det grafiske elementet TEKST er ikke beskrevet i standarden.

Eksempel: Tekst generert for kartproduksjon fra SSR.

.TEKST 1:
..TTEMA 2102
..STRENG 124

Spesifikasjonen av tekstdata omfatter presentasjonsegenskaper knytta til tekst. Spesifikasjonen omfatter ikke fontvalg, eller helning på bokstaver etc. Dette forutsettes generert med tegneverktøy ut fra hva slags "tema" teksten omhandler. Alle tekster vil være grafisk element TEKST, og får SOSI-egenskapen TTEMA, med samme verdier som primærdatabeskrivelsene tilhørende PTEMA, FTEMA eller LTEMA.

6.12.1 Koordinaters betydning

Hvordan en tekst skal skrives på en presentasjon bestemmes av hvor mange koordinater det er på TEKST datagruppa.

6.12.1.1 1. Koordinat - Objektkoordinat

Objekt-koordinat er det punktet som angir det geografiske objektet som teksten står til, f.eks i bygningen for gårdsbruk. Dette er en målestokksuavhengig opplysning. Ved redigering skal objektkoordinaten tas vare på

Undisplayed Graphic

6.12.1.2 2. Koordinat - tekstplasseringskoordinat

Tekstplasseringskoordinat er der hvor teksten skal starte å skrives. (dvs der hvor tekstorigo er). Hvis datagruppa bare har en koordinat vil objektkoordinaten oppfattes som tekstkoordinat.

Undisplayed Graphic

6.12.1.3 3. Koordinat - retningskoordinat

Retnings-koordinat er et punkt som angir tekstens retning i forhold til tekstplasserings-koordinaten.

Merk at hvis en tekst skal ha dreiing må dette angis mellom punkt 2 og 3, slik at hvis en ønsker dreiing rett fra objektkoordinaten må denne gjentas som punkt nr. 2.

Undisplayed Graphic

6.12.1.4 De resterende koordinatene - Tekstkurve

Tekstkurve angir en kurve på hvilken teksten skal slynge seg. Teksten skal slynge seg når tekstdatagruppa har mer enn 3 koordinater. Da skal teksten starte i punkt 2, og slynge seg langs koordinatene. Hvis den kurva som punktene danner er for kort, fortsetter teksten langs samme retning som kurvens avslutning.

Undisplayed Graphic

Det grafisk element TEKST kan som nevnt ha 1, 2, 3 eller flere koordinater og dette bestemmer hvordan teksten skal lokaliseres. Den første koordinaten er alltid objekt-koordinat. Hvis det er mer enn en koordinat skal koordinat nr. 2 angi hvor tekst skal begynne, mens evt. koordinat nr. 3 bestemmer retning på teksten. Flere enn tre koordinater vil gi mulighet for å beskrive en kurve som teksten skal slynge seg etter.
6.12.1.5 Eksempler
.TEKST 99:

..TTEMA 4002

..STRENG Aust-Agder
..NØ
111111 111111

.TEKST 99:

..TTEMA 4002
..STRENG Hedmark
..NØ
111111 111111
222222 222222

.TEKST 99:
! en retning
..TTEMA 4002
..STRENG "Møre og Romsdal"
..NØ
111111 111111
222222 222222
333333 333333
! Det finnes bare en
! objektkoordinat. Denne er da tekstpl.
! og teksten skrives i forhold
! til denne


x Aust-Agder

! Her er det en egen
! tekstplasseringskoordinat (222)
! som teksten skal skrives ved
! o Hedmark
! x




! Her er i tillegg angitt
! mellom 2222 og 3333
!
! o Møre og Romsdal (skrå)
!
! x

 

6.12.2 SOSI -basisnavn definisjoner

De SOSI-basisnavn som er beskrevet i dette kapittel kan kun benyttes for objekter bekskrevet med det grafiske elementet .TEKST.

6.12.2.1 STRENG

Selve tekststrengen angis med SOSI-navnet ..STRENG.

Definisjon

Kodeverdi

Forklaring

.DEF
..STRENG T70

Eksempel:
..STRENG Godstolen

Hvis teksten består av mellomrom eller komma, må teksten omsluttes i " " eller ' '.

..STRENG Godstolen
..STRENG "Den gode stol"

Hvis teksten består av flere linjer repiteres STRENG

..STRENG Lesjaskogs-
..STRENG vatnet

STRENG er definert til lengde på max 70 tegn, noe som for kartformål er tilstrekkelig. SOSI kan imidlertid håndtere lengre tekster, men da må en definere og benytte brukerdefinerte navn.

6.12.2.2 DIM

DIM beskriver bokstavenes eller symbolenes bredde og høyde i millimeter på kartet pr. bokstav. Høyde regnes fra bunnlinje til øvre kant. Se TREF.

Definisjon

Kodeverdi

Forklaring

.DEF
..DIM *
...DIM-HØYDE D8
...DIM-BREDDE D8

Eksempel:

..DIM 6.2 4.0

F Dersom bredde ikke er oppgitt, benyttes standard bredde for den gitte teksthøyden jfr. fonten.

6.12.2.3 TDIM

TDIM dekker det samme behovet som DIM, men beskriver bokstavenes eller symbolenes høyde og bredde i terrengmål pr. bokstav.

Definisjon

Kodeverdi

Forklaring

.DEF
..TDIM *
...DIM-HØYDE D8
...DIM-BREDDE D8

Eksempel:

..DIM 56 67

6.12.2.4 TREF

Tekstens referansepunkt er det stedet på teksten hvor en tekstplassering referer seg til. Dette punktet er som default nedre venstre punkt til første bokstav i teksten eller symbol. Hvis teksten består av flere linjer er det fremdeles referert ut fra første del av strengen (dvs i første linje).

 

Definisjon

Kode-verdi

Forklaring

.DEF
..TREF *
...NORD
H1




...ØST H1



0
1
2
3

0
1
2

 

Undisplayed Graphic

Bunnlinja tangerer nedre del av nederste bokstav/symbol.

En innretning etter nedre venstre hjørne av første bokstav (R) vil bli:

..TREF 0 0

6.12.2.5 SPERRING/FRISPERR

Sperring regulerer avstanden mellom bokstavene i teksten. Dette kan enten gjøres ved forholdstall relatert til størrelsen på største bokstavblokk (SPERRING) eller som ren skriftlengde i cm på kartet.

Definisjon

Kodeverdi

Forklaring

.DEF

..SPERRING

L

 

M

 

S

Liten sperring=1 drittel, dvs 1/3 av "største bokstav-blokk" mellom hver bokstav.

Middels sperring=halvgefirt, dvs 1/2 av "største bokstav-blokk" mellom hver bokstav.

Stor sperring=1 gefirt, dvs 1 (største) "bokstavblokk" mellom hver bokstav.

Definisjon

Kodeverdi

Forklaring

.DEF
..FRISPERR H3

<verdi>

Skriftlengden i mm på presentasjonsmediet.

6.12.2.6 SYMBOL

Symboler er spesielle tekstobjekt. Istedetfor ..STRENG spesifiseres en egenskap i form av et nummer i et symbolbibliotek. Forøvrig benyttes de andre prsentasjonsegenskapene .

Definisjon

Kodeverdi

Forklaring

.DEF

..SYMBOL *
...SYMB-BIB T8



...SYMB-NR H3



FKB
SKTFSYMN

SKTFSYMP

SKTFSYMU

<0,255>



Grafisk standard for ØK og TKSymbolfont for friluftsliv og sport (negativ)
Symbolfont for friluftsliv og sport (positiv)
Symbolfont for friluftsliv og sport (uten ramme)
Nummeret på symbolet i bibl.

Et eksempel på henvisning til symbolnummer 112 i grafisk standard for ØK :

..SYMBOL FKB 112

Andre henvisninger til symbolbiblioteker og symbolnummer må avtales mellom partene.

Dersom det er flere symboler som skal presenteres i tilknytning til et objekt, benyttes ..SYMBOL over flere linjer. I motsetning til tekststrenger skal disse symbolene plasseres etter hverandre i en presentasjon.

F SYMBOL kan ikke benyttes sammen med STRENG på samme objekt.

6.12.3 SOSI-gruppe definisjoner

Nedenfor følger noen SOSI-gruppe definisjoner for TEKST.

Tekstdata - enkel tekst.

.TEKST <serienummer>:
..TTEMA <temanummer>
..DIM <høyde> <bredde>
..STRENG <tekststreng>
..NØH
<nord> <øst> <h> ! obj.koord
<nord> <øst> <h> ! tekstplasspkoord.
<nord> <øst> <h> ! retningskoord
<nord> <øst> <h> ! evt angi tekstkurve
<nord> <øst> <h> !





Streng er ofte generert av egenskaper fra primærdatasett. (eks. Gnr, Bnr)

Tekstdata - flere linjer.

.TEKST <serienummer>:
..TTEMA <temanummer>
..DIM <høyde> <bredde>
..STRENG <tekststreng>
..STRENG <tekststreng>
.......
..NØH
<nord> <øst> <h> ! obj.koord
<nord> <øst> <h> ! tekstplasskoord.
<nord> <øst> <h> ! restningskoord
<nord> <øst> <h> ! evt angi tekstkurve
<nord> <øst> <h> !

Symbol.

.TEKST <serienummer>:
..TTEMA <temanummer>
..DIM <høyde> <bredde>
..SYMBOL <bibliotek> <nr>
..SYMBOL <bibliotek> <nr>
..NØH
<nord> <øst> <h> ! obj.koord
<nord> <øst> <h> ! tekstplasskoord.

Eksempel kan være markslagssymboler som har flere presentasjoner pr. polygon.

6.12.4 Eksempler på det grafiske elementet TEKST

! Fastmerkenummer

.TEKST 17:
..TTEMA 1000
..STRENG "23/5,7,9"
..DIM 3.0 10.0
..NØH
<nord> <øst> <h>
<nord> <øst> <h>

!navn på innsjø

.TEKST 17:
..TTEMA 3101
..STRENG Lesjaskogs-
..STRENG vatnet
..DIM 2.0 7.0
..NØH
<nord> <øst> <z>
<nord> <øst> <z>

!Gnr,bnr

.TEKST 17:
..TTEMA 4011
..STRENG "23/5,7,9"
..DIM 3.0 10.0
..NØH
<nord> <øst> <z>
<nord> <øst> <z>

!Gnr,bnr

.TEKST 17:
..TTEMA 4011
..STRENG "23/5,7,9"
..STRENG “28/33”
..DIM 2.0 7.0
..NØH
<nord> <øst> <z>
<nord> <øst> <z>

Se også eksempler i SOSI-DEL 3

7 GRAFISKE OBJEKTER

Grafiske objekter består av egenskaper, og referanser til andre grafiske objekter eller til grafiske elementer. Kan også beskrives som geometriske objekter.

Referansenummer vil ligge som en del av gruppeinfo og peke til andre datagruppers serienummer. (se foran.)

Det er spesielt viktig å huske å oppdatere disse referansenummer hvis en renummererer serienummer på en SOSI-fil.

Det er definert 2 spesielle grafiske objekter, TRASE og FLATE. (Det generelle grafisk objekt STRUKTUR er tatt ut i påvente av bedre mekanismer.)

Traséer defineres som en sekvens av PUNKT, LINJE, KURVE, BUE, BUEP, KLOTOIDE, BEZIER som tilsammen danner en sammenhengende enhet med en-dimensjonal utstrekning. Defineringen foregår ved referering til de datagruppene som inngår i traseen. Gruppene refereres i en beskrivende rekkefølge. Det skal være knutepunkt og lik koordinat mellom de grafiske elementene.

TRASE kan ikke referere annen trase.

TRASE har ikke koordinater.

For eksempel kan et vegstykke beskrives som en TRASE som består av flere linjer/kurver.

Eksempel:

38:
------>------ + KP
|
^ 45:
|
KP +----->------
98:


.TRASE 436:
..LTEMA 7000
..REF :38 :-45 :98


Fortegnet på referansenummerne forteller retningen som punktene ligger lagret på i SOSI-fila (jfr. pilene).

7.1 Grafisk objekt: FLATE

FLATE er et sammenhengende areal begrenset av LINJE, KURVE, BUE, BUEP, KLOTOIDE, SIRKEL og BEZIER.

Defineringen foregår ved referering til de datagruppene som avgrenser flaten. Gruppene refereres i en beskrivende rekkefølge. Det skal være knutepunkt og lik koordinat mellom de grafiske elementene.

Fortegnet på referansenummerne forteller retningen som punktene ligger lagret på i SOSI-fila (jfr. pilene).

Datagruppene som danner avgrensningen av flaten skal ikke krysse.

En datagruppe kan bare inngå en gang i beskrivelsen av en flate.

En flate kan ha øyer (dvs. andre flater) inni seg. Dette blir da angitt ved at en refererene til hver øy ved å sette referansenummerene i parantes. Er øya et eget objekt, så kan en referere til .FLATE eller de grafiske elementene som beskriver “hullet”.

Alle referanser til grupper som danner ytre avgrensing av flaten skal komme som en sammenhengende enhet, og før eventuelle referanser til øyer i flaten.

Gruppeinformasjonen kan inneholde bare en linje med ..REF, og denne skal inneholde hele beskrivelsen av flaten. Hvis denne blir for stor til å skrives på en linje på SOSI-filen skal den fordeles over flere linjer, men da uten ..REF på de påfølgende linjene.

Eksempel på hvordan referansene fordeles over flere linjer på SOSI-filen:

.FLATE 679:
..FTEMA 3101
..REF :2 :-48 :5 :78 :-34 :238 :450 :356
:-26 :35 :-93 (:45 :-46 :47) (:52 :53 :54
:-56 :57) (:465 :-466 :467) (:352 :533 :334)
(:472 :473)
..NØ
123456 123456

I tidligere versjoner av SOSI ble “.. “ benyttet som referense-element. For å sikre bakoverkompatibilitet vil denne også bli tillatt benyttet i versjon 2.2.

FLATE skal ha en koordinat. Denne er et representasjonspunkt for flaten. Representasjonspunktet skal ligge inne på flaten. FLATE kan ikke ha mer enn en koordinat.

Eksempel på flate med løse ender:
Undisplayed Graphic
.FLATE 51:
..FTEMA 4201
..ATIL 11
..REF :47
..NØ
123456 123456
Merk at datagruppene 48, 49 og 50 ikke skal være med i beskrivelsen av flate 51

 

Eksempel på sammenhengende flater:


Undisplayed GraphicUndisplayed Graphic

Begge disse tilfellene skal handteres som to adskillte flater.

En øy kan tangere ytteravgrensingen av flaten. Dette skal beskrives som en øy og ikke som en del av flatens ytre avgrensing.

Den skraverte flaten beskrives på en av to følgende måter:

.FLATE 49:
..FTEMA 3101
..REF :47 :-48
..NØ
200 96

.FLATE 52:
..FTEMA 3104
..REF :50 :51 (:48 :-47)
..NØ
100 100

.FLATE 52:
..FTEMA 3201
..REF :50 :51 (:49)
..NØ
100 100

Undisplayed Graphic

 

8 GENERELLE EGENSKAPER

Under dette kapittel defineres en del generelle egenskapsnavn som benyttes gjennomgående for flere kategorier data. I og med at navnene er definert her kan de benyttes generellt i kodingsøyemed uten videre defineringer under hver anvendelse.

8.1 PTEMA, LTEMA, FTEMA og TTEMA

Som før nevnt benyttes xTEMA til en grovkoding av data. Dessuten er en del av de mest vanlige opplysninger i dagens standardkart detaljkodet med xTEMA-verdier.

Temakoding utføres med et 4-sifret tall og 4 basisnavn, ett for hver grafisk "dimensjon":

PunktTema
.DEF
..PTEMA H4
LinjeTEMA
.DEF
..LTEMA H4
FlateTEMA
.DEF
..FTEMA H4
TekstTEMA
.DEF
..TTEMA H4

Kodesystemet er bygd opp slik at samme fysiske objekt vil ha samme kodeverdi i de ulike “dimensjoner”:

Eksempel:
PTEMA 4011 : Sentralpunkt for en eiendomsteig
LTEMA 4011 : Eiendomsgrense
FTEMA 4011 : Den flata som danner en eiendomsteig.
TTEMA 4011 : Denne teksten gjelder en grunneiendom, f.eks. gårdsnavn.

Kodeverdier for xTEMA finnes forøvrig i SOSI-kodeliste.

8.2 ENHET

Med ENHET forstås den faktor som koordinatene nede på på SOSI-fila (FIL-N, FIL-Ø og FIL-H) må multipliseres med for å få meter.

.DEF
..ENHET D6 ! Enhet generelt
..ENHET-H D6 ! Enhet høyde
..ENHET-D D6 ! Enhet dybde

ENHET er også definert under TRANSPAR, men kan også forekomme på gruppenivå. For nærmere beskrivelser, se under TRANSPAR.

8.3 KVALITET

Det er ofte av stor viktighet å kunne angi nøyaktighet på digitale data både på filnivå, men ikke minst på datagruppe- og punktnivå.

Alle geografiske objekter i henhold til SOSI-standarden skal inneholde tilstrekkelig kvalitetsinformasjon, med unntak av flater

Flater representert ved et sentralpunkt trenger ikke kvalitetskoding. Kvaliteten på flate kan avledes fra de objektene som danner flata.

Kvalitetsbegrepet i SOSI består nå av fire begreper: MÅLEMETODE, NØYAKTIGHET,SYNBARHET og MAX-AVVIK, hvorav de to første er mest brukt.

MÅLEMETODE forteller hvordan data er fremkommet, NØYAKTIGHET forteller antatt nøyaktighet oppgitt i cm, og SYNBARHET benyttes hvis det kartlagte objektet ikke lot seg godt definere under registrering. MAX-AVVIK uttrykker absolutt toleransegrense for geometriske avvik.

KVALITET blir således et gruppe-element og defineres slik:

Definisjon

Kodeverdi

Forklaring

.DEF
..KVALITET
...MÅLEMETODE
...NØYAKTIGHET
...SYNBARHET
...H-MÅLEMETODE

...H-NØYAKTIGHET

...MAX-AVVIK


*
H2
H5
H2
H2

H5

H6



Målemetode for grunnriss
Nøyaktighet for grunnriss
Synbarhet for grunnriss
Målemetode for høyden, angis hvis annen målemetode enn for grunnriss.
Nøyaktighet for høyden i cm, angis hvis annen nøy. enn for grunnriss.
Maksimalt avvik fra korrekt verdi.

Koder for MÅLEMETODE:

Her klassifiseres hvordan koordinatene er fremkommet. Hovedgruppene (eks 10, 20 , 30 ) benyttes hvis en ikke er i stand til bedre spesifisering.

Målemetode
grunnriss

Målemetode
høyde

Forklaring

Målt i terrenget

10

10

Terrengmålt

11

11

Totalstasjon

12

12

Teodolitt med elektronisk avstandsmåler

13

13

Teodolitt med målebånd

14

14

Ortogonal-metoden

15

Nivellement

Annet

18

18

Tatt fra plan

19

19

Annet

Konstruksjonsinstrument

20

20

Stereoinstrument

21

21

Aerotriangulert

22

22

Analytisk plotter

23

23

Autograf - vanlig registrering

24

24

Digitalt stereoinstrument

Scanning

30

Scannet fra kart

31

Blyantoriginal

32

Rissefolie

33

Transparant folie, god kvalitet

34

Transparant folie, mindre god kvalitet

35

Papirkopi

Digitalisert fra foto/bilde

40

Digitalisert på digbord fra ortofoto/flybilde

41

Ortofoto - film

42

Ortofoto - fotokopi

43

Flybilde - monodigitalisert fra film

44

Flybilde - monodigitalisert fra fotokopi

Digitalisert fra kart

50

Digitalisert på dig. bord fra strek-kart.

51

Blyantoriginal

52

Rissefolie

53

Transparant film-god kvalitet

54

Transparant film - mindre god kvalitet

55

Papirkopi

Genererte data

60

60

Genererte data (Interpolasjon)

61

61

Generert i terrengmodell

62

62

Vektet middel

63

63

Generert sirkelgeometri

64

64

Generalisert

65

Generert sentralpunkt

66

66

Sammenknytningspunkt / randpunkt

Spesielle metoder

70

70

Spesielle motoder

71

Målt med stikkstang

72

Målt med Waterstang

73

Målt med målehjul.

74

74

Målt med stigningsmåler

Annet

79

79

Annet (spesifiseres i filhodet)

Frihånd

80

Frihåndstegning

81

Digitalisert fra krokering på kart

82

Direkte innlagt på skjerm.

GPS/Treghet

90

90

Treghetsstedfesting

91

91

GPS - Differensiell, pseudorange

92

92

GPS - Absolutt, pseudorange

93

93

GPS - Differensiell, fase

94

94

GPS - Absolutt, fase

95

95

Kombinasjon GPS/Treghet (Tidligere brukt 75)

Koder for NØYAKTIGHET:

Nøyaktigheten angis i cm som den nøyaktighet dataregistreringen forutsettes å ha . (Nøyaktighetskrav for kartserier f.eks). Med nøyaktighet menes punktmiddelfeil (standardavviket) i grunnris for punkter samt tverravvik for linjer (a).

Undisplayed Graphic

Den nøyaktighet som angis skal være så nær dataenes virkelige nøyaktighet som mulig. I enkelte situasjoner som ved digitalisering av strek-kart, må en benytte antatte verdier.

Nedenfor følger en tabell over nøyaktighetskrav i betydning middelfeil, for en del analoge kartserier. Men en må her være klar over følgende:

• Tallene inneholder ikke den ekstra unøyaktigheten som kommer fra en eventuell digitalisering på digitaliseringsbord.

• Tallene i tabellen gjelder for veldefinerte grunnrissdetaljer. Mindre godt detaljerte detaljer har større middelfeil. Dette bør helst gjenspeiles I nøyaktighetsangivelsene.

• Tallene for grunnriss og høyde behøver ikke å være like, slik de er i tabellen.

Ved direkte digital kartkonstruksjon I stereoinstrument er middelfeilene vesentlig lavere enn for tilsvarede analoge tall, anslagsvis halvparten av tallen I tabelle. For slike kart, bruk heller tallene som er angitt for ulike objekter I SOSI-del5, registeringsinstruks.

Koding av nøyaktighet er ikke begrenset til nøyaktighetskodene i tabellen.

Tilsvarende Kartmålestokk

Vanlig benyttede Nøyaktighetskrav

Nøyaktighet-

kode

H-Nøyaktighet-

kode

1: 250

0,13 m

13

13

1: 500

0,21 m

21

21

1: 1000

0,36 m

36

36

1: 2000

0,58 m

58

58

1: 5000

2 m

200

200

1: 10000

4 m

400

400

1: 20000

8 m

800

800

1: 50000

15 m

1500

1500

1: 100000

30 m

3000

3000

1: 1mill

300 m

30000

30000

1: > 1 mill

> 300 m

99999

99999

Koder for SYNBARHET:

Denne koden beskriver hvor godt den kartlagte detalj var synbar ved kartleggingen. Hvis synbarheten var god/normal utelates denne opplysning.

Synbarhet

Beskrivelse

0

Fullt ut synlig / gjennfinnbar (default)

1

Dårlig gjenfinnbar i terreng, men forøvrig grei å innmåle. (Benyttes bl.a for innmåling av ledninger på lukket grøft.

2

Middels synlig i flybilde/modell.

3

Dårlig / ikke synlig i flybilde / modell.

 

MAX-AVVIK er et kvalitetselement som uttrykker en absolutt toleransegrense for geometriske avvik. MAX-AVVIK er en opplysning som kan brukes i tillegg til eller i stedet for “nøyaktighet”, enhet cm. Den kan brukes når dataene er så godt kvalitetssikret at man vet at denne grensen ikke er overskredet.

Det stilles ikke krav om at kvalitetsangivelsen for de ulike objektene i databeskrivelseskapitlene i SOSI-versjon 2.2 skal inneholde MAX-AVVIK.

Her er noen eksempler på bruk av KVALITET:

Eksempel 1

Eksempel 2

.HODE 0:
..TRANSPAR
...KOORDSYS 31
...ORIGO-NØ 0 0
...ENHET 1.000
..OMRÅDE
...MIN-NØ 6450 -1200
...MAX-NØ 8060 11500
..KVALITET 55 200 2

.HODE 0:
..TRANSPAR
...KOORDSYS 31
...ORIGO-NØ 0 0
...ENHET 1.000
..OMRÅDE
...MIN-NØ 6450 -1200
...MAX-NØ 8060 11500
..KVALITET 20 100 1 61 100 600

Digitalisert fra papirkart, med nøyaktighet på 2 m og middels synlig i bilde. (Som før)

Registrert i stereoinstrument, med grunnrissnøyaktighet på 1m, dårlig gjennfinnbar i terrenget. Høydene er generert i terrengmodell med en nøyaktighet på 1m, max-avvik er 6m.

8.4 DATO

Med begrepet DATO skal det angis hvilken dato dataene er verifisert mot det virkelige objektet som beskrives. For kartdata vil en benytte flyfotodato, synfaringsdato eller evt. kontrolldato. Tidspunkt for ulike faser av bearbeiding av informasjon benyttes ikke.

NB Betydningen av begrepet DATO er noe endret fra versjon 2.1 !

Alle objekter beskrevet i henhold til SOSI-versjon 2.2 skal ha dato. En del eldre data vil vanskelig kunne tidfestes. For disse kan en benytte ..DATO *, dvs at dato er vurdert, men ikke tallfeste.

Dato oppgis i samsvar med NS-ISO 8601, “basic”-beskrivelse; med år, mnd og dag. (Ååååmmdd) og er definert slik:

.DEF
..DATO H8
Eksempel:

..DATO 19880515 !(15. mai 1988)

8.5 VFLATE

VFLATE er en mekanisme for å beskrive hovedflate / hjelpeflate når den fullstendige flate blir delt av en hjelpegrense, f.eks kartbladkant.


Definisjon


Kodeverdi


Forklaring

.DEF
..VFLATE H1


1





2


Den delen av flata som inneholder representasjonspunkt for hele teigen. (Dersom VFLATE ikke er angitt på objektet, betyr dette det samme som ..VFLATE=1.)

Den delen av den totale flata som ikke inneholder selve representasjonspunktet, men et hjelpepunkt.

Se forøvrig under randproblematikk

8.6 HØYDE

HØYDE er en opplysning som kan benyttes på grafiske elementer uten videre definering. HØYDE er også omtalt under koordinater foran og tas her med kun for fullstendighetens skyld. HØYDE angir det grafiske elements høyde over høydereferensen i meter, og oppgis som et desimalt tall hvis nødvendig.

Høyde er definert slik:

.DEF
..HØYDE D10

8.7 DYBDE

DYBDE er en opplysning som kan benyttes på grafiske elementer som ligger under en vannflate

DYBDE angir det grafiske elements dybde i henhold til dybdereferensen, og oppgis som et desimalt tall hvis nødvendig.

Dybde er definert slik:

.DEF
..DYBDE D10

8.8 HOB

Med HOB forstår vi det grafiske elements høyde over bakken. Dette er aktuelt i forbindelse med ulike typer objekter som telefonstolper, hus etc..

.DEF
..HOB D10
Eksempel:

.PUNKT 58:
..PTEMA 1000
..HOB 13.263 !Høyde på varde over bakken
..NØ
123456 133588

8.9 HREF

Det vil ofte være behov for å angi om registreringen er utført på topp eller bunn av et element, f.eks. en skråning, mur osv. For å angi dette, defineres navnet HREF.

.DEF
..HREF T3 (HøydeREFeranse)

Aktuelle kodeverdier er FOT og TOP.
Eksempel:
.LINJE 120:
..LTEMA 6001
..HREF TOP
..NØH123456 123456 1234

8.10 KOMM

Det er ofte behov for å identifisere digitale kartdata til den kommune de ligger innefor. Til dette er det definert det spesielle navnet ..KOMM for å angi hvilket kommunenummer dataene befinner seg i. Kommunenummer er definert til Statistisk Sentralbyrå's offisielle liste over kommunenummer hvor de to første siffer inneholder fylkesnummer og de to siste kommunenummer innen fylket.

Definisjon i SOSI:

.DEF
..KOMM H4 (NB skal ha ledende null)
Eksempel:

..KOMM 0412 ! Ringsaker kommune i Hedmark.

8.11 Status

Dette er en generell mekanisme for å beskrive status for et objekt.

.DEF
..STATUS T1

 

Denne er etablert med følgende koder :

E - Eksisterende (Default)
P - Planlagt
U - Under arbeid
O - Ombygd
K - Kondemnert
F - Foreldet
B - Brukes
N - Nedlagt

8.12 MEDIUM

Medium brukes som en generell mekanisme for å angi grovt om et objekt befinner seg over terreng ( i luft ), på terrenget, under terrenget eller i vann.

.DEF
..MEDIUM T1

Kodeverdier :

T : På terrenget
U : Under terrenget
L : I luft, dvs over terreng
S : På sjøbunnen
O : På vannoverflaten
V : Alltid i vann
D : Tidvis under vann
B : I bygning eller bygningsmessig anlegg
I : På isbre

8.13 Avblending

Avblendingsdata er kodet med en spesiell egenskap (..AVBLEND) som forteller hvilken primærdata som skal bli avblenda.

.DEF
..AVBLEND T6
Benytter kodrnavnet på databeskrivelseskapitlene:
DEK, VBASE, VSIT, ETC

8.14 Objekttype

Objekttype er et nytt SOSI-element for å gi en lettere klassifisering av objektet. I databeskrivelsene i versjon 2.2 er OBJTYPE definert entydig for alle objektene i databeskrivelseskapitlene ved sitt objektnavn, men kun som opsjon.

.DEF
..OBJTYPE T16

9 Beskrivelse av ikke - geografiske objekter / mekanismer

Ved registrering og beskrivelse av datasett har en ofte behov for en spesiell type objekter / mekanismer som ikke kan sies å være geografiske objekter. Det som kjennetegner disse objektene er at disse ikke er knyttet til et spesielt fagområde / databeskrivelskapittel. Dette er objekter som er nødvendige av presentasjonshensyn samt for å ivareta topologiske relasjoner innenfor et nærmere angitt geografisk område.

9.1 Rutenett, rammekant, m.m

Alle objektene får her en nærmere presisering. De objektene som både er flate, grense samt punktobjekter får bare en nærmere beskrivelsen av objektet som polygon (flate). Et eksempel på dette er objektet kommune, hvor selve begrepet kommume er forklart. Kommunegrense er da en grense som skiller kommuner, og RP_Kommune er følgelig representasjonspunkt for kommunen.

Rutenett: Administrativ inndeling av et geografisk område i ruter, ofte på bakgrunn av en offentlig kartbladinndeling.

Sonedele: Administrativ inndeling av et geografisk område i soner, ofte basert på en offentlig kartbladinndeling.

Kartbladkant: Avgrensningslinje for et kart som dekker et nærmere angitt geografisk område, ofte basert på en offentlig kartbladinndeling.

Kant_utsnitt: Kant for tilfeldig utsnitt.

Temakart_avgr Avgrensningslinje for et temakart

Dataavgrensning Generell avgrensningslinje, f.eks mellom datasett med ulik kvalitet (F.eks mellom kartleggingsstandardene FKB-A og FKB-B)

Diskontinuitet Diskontinuitetslinje, men lukket.

Gradnett Linje som beskriver et gradnett, generelt

Avblendingsomr Flate som benyttes for avblending i kartproduksjon

Avblendingslinje Linje som avgrenser en avblendingsflate

Isolinje Linje som sammenbinder punkter med samme verdi eller tilstand.

Isogon Linje som forbinder punkter med samme magnetiske misvisning.

Isoterm Linje som forbinder punkter med samme temperatur.

Fritekst_kart Fritekst på kart. Benyttes der teksten peker på et objekt som ikke er kodet

Spesiell_det Spesiell detalj. Brukes kun i nødsfall.

Objektklasse:

..OBJTYPE

SOSI-koding

Merknad

Grafisk

element/ objekt

SOSI-navn

- verdi

Rutenett

LINJE

LTEMA

9000

Rutenett_off

LINJE

LTEMA

9001

Rutenett_utm

LINJE

LTEMA

9002

Sonedele_off

LINJE

LTEMA

9011

Sonedele_utm

LINJE

LTEMA

9012

Kartbladkant

LINJE

LTEMA

9100

Kartbladkant_øk

LINJE

LTEMA

9101

Kartbladkant_utm

LINJE

LTEMA

9102

Kant_utsnitt

LINJE

LTEMA

9111

Temakart_avgr

LINJE

LTEMA

9121

Dataavgrensning

LINJE

LTEMA

9130

Diskontinuitet

LINJE

LTEMA

9131

Kartbladhjørne

PUNKT

PTEMA

9230

Gradnett

LINJE

LTEMA

9200

Avblendingsomr

FLATE

FTEMA

9800

Avblendingslinje

LINJE

KURVE

LTEMA

9800

Isolinje

KURVE

LTEMA

9400

Isogon

KURVE

LTEMA

9401

Isoterm

KURVE

LTEMA

9402

Fritekst_kart

TEKST

TTEMA

9599

Spesiell_det

PUNKT

PTEMA

9990

9.2 Tekst

10 Presentasjonsdata

I en presentasjon inngår objekter fra ett eller flere primærdatakapitler, ikke geografiske objekter og mekanismer samt presentasjonsdata i form av tekststrenger og symbler.

Undisplayed Graphic

Med presentasjonsdata mener her tilleggsdata som er nødvendig for å produsere presentasjoner, og som ikke lar seg fornuftig generere automatisk i en uttegningsprosess.

Eksempler på presentasjonsdata er tekstdata der tekst og symboler er ferdig plassert i kartbilde for et aktuelt kartprodukt.

Tekst på kartet som er generert automatisk i uttegningsprosessen fra f.eks primærdatasett omfattes ikke av det vi her kaller presentasjonsdata.

Beskrivelsesteknikker for presentasjonsdata er beskrevet under det grafiske element .TEKST.

Formålet med tekstdataspesifikasjonen er å ta vare på det redaksjonelle arbeidet ved manuell plassering og redigering av alt tekstmateriell i en produksjonsprosess. Med tekst forstås også utplasserte symboler (eks. markslagssymboler).

Tekstdata inngår ikke i primærdatabeskrivelsene, men er presentasjonsdata som er spesifikk for en enkelt kartserie (eller endog et enkeltstående kartblad).

Symboler i en presentasjon tegnes ut fra tekstobjekter (som ofte er generert fra primærdatabaser) eller tegnes direkte fra primærdatabaser.

I forbindelse med fotogrammetrisk konstruksjon har en bl.a behov for å legge ut markslagssymboler uten at en oppfatter dette som representasjonspunkt for flaten. Disse må da referes til et symbolbibliotek.

10.1 Randproblematikk

10.1.1 Merking av randpunkter

Med randproblematikk menes overgangen mellom to tilstøtende geografiske områder, ofte i form av filer med objekter som grenser mot hverandre, avgrenset av en kartbladkant.

Undisplayed Graphic

All handtering av geografisk informasjon skjer innenfor et nærmere angitt geografisk område. Selv for nasjonale sømløse baser vil man eventuelt få en randproblematikk , f.eks mot Sverige.

Behandlingen av geografiske data (knutepunktsgenerering, flategenerering, kvalitetskontroll, etc) skjer innenfor geografiske områder. På et eller annet ledd i denne prosessen må det også kontrolleres at et geografisk objekt regsistrert på to filer virkelig er knytta sammen. I tillegg genereres det punkter langs disse områdegrensene som egentlig ikke er punkter som representerer objekter. En eiendomsgrense som går på tvers av to kartblad blir tilført 2 ekstra punkter på kartbladgrensa, en i hver fil. Ved senere bruk og ,generering av sømløse databaser er det aktuelt å fjerne disse punktene, og disse trenger da en særskilt merking.

I utgangspunktet er det ikke behov for å merke randpunkter innenfor det grafiske elementet KURVE, da hvert enkelt punkt i kurven ikke har noen spesiell betydning. Merkingen er spesielt tiltenkt innenfor LINJE og BUE.

I SOSI versjon 2.2 merkes disse punktene ved å benytte en særskilt målemetode under KVALITET. (MÅLEMETODE 66)

10.1.2 Kopling av flater som går på tvers av randkanter

Beskrivelse av flater på tvers av randkanter.

Definisjon

Kodeverdi

Forklaring

.DEF

..VFLATE H1

1

2

Vindusflate

Den delen av flata som inneholder selve representasjonspunktet i en sømløs base.

Den delen av flata hvor representasjonspunktet blir fjernet i en sømløs base

Fordi det av produksjonstekniske hensyn ofte er aktuelt å etablere data kartbladvis, er det ønskelig å dele flateobjekter når de krysser kartkantene. Selv om vi deler flatene i flere kartbladteiger over kartbladkanten, må vi se på flatene som en enhet.

For at vi skal kunne danne flater innenfor et kartblad, må vi registrere et punkt i alle flatene. Men bare et av punktene i flatene skal være det virkelige representasjonspunktet for flata i en sømløs database.Vi bruker ..VFLATE koding for å skille ut de punktene som skal fjernes når vi tar bort kartbladkantene og danner en sømløs base. Kartbladspunktenene som skal fjernes i en sømløs base skal ha ..VFLATE 2, mens det virkelige represetasjonspunktet får koden ..VFLATE 1 eller ingen ..VFLATE-kode. Fjerning av kartbladkanter og representasjonspunkt merket ..VFLATE 2 kan senere gjøres automatisk.

Undisplayed Graphic

Bruk av ..VFLATE på fire ØK-kartblad

Her ser vi eksempel på bruk av ..VFLATE. Den delen av eiendomsflata som inneholder representasjonspunktet for hele teigen skal være kodet med ..VFLATE 1, eller ingen VFLATE-koding.

De (den) andre delene av flaten skal kodes med ..VFLATE 2.

All annen informasjon på disse delene av eiendomsteigen skal være lik som på hovedteigen.