| Kapittel-versjon |
Dato |
Merknad |
| Ver. 1.0 |
okt 1987 |
Første utgave |
| Ver. 1.2 |
mai 1988 |
Kap. 3.6 omarbeidet |
| 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.
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.
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.
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 |
.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 |
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.
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 |
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. |
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.
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).
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.
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 !<cm> Lokal
referenseflate, angitt i det ! ...DYBDE-REF T5 !HREF Høyeste vannstand i reg. vann !LREF Laveste vannstand i regulert vann ...FRISEIL-REF T5 !LREF Laveste vannstand i regulert vann ...HØYDE-TYPE T1 !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
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:
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 |
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 |
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.
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:
|
|
ND7,DEC |
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.
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.
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) |
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 :
|
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) |
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
Figuren viser en fullstendig geometrimodell for SOSI , både med tanke på grafiske elementer og grafiske objekter.
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).
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 |
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.
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.
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.
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: |
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 |
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
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.
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.
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 |
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Ø).
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 |
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 |
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: |
Figur med bue som svinger mot høyre Fra A mot B |
+B |
| .BUE 599: |
Figur med bue som svinger mot venstre Fra A mot B |
+ B + A |
| .BUE 600: |
Figur med bue som svinger mot høyre, og storbue valgt |
+ B |
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 |
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 |
![]() |
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.
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.
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 |
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: |
![]() |
| .BEZIER 511: |
![]() |
Tekstdata forutsettes i det alt vesentlige generert fra primE6rdatasett, 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: |
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.
Hvordan en tekst skal skrives på en presentasjon bestemmes av hvor mange koordinater det er på TEKST datagruppa.
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å
Tekstplasseringskoordinat er der hvor teksten skal starte å skrives. (dvs der hvor tekstorigo er). Hvis datagruppa bare har en koordinat vil objektkoordinaten oppfattes som tekstkoordinat.
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.
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.
| 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. |
| .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 |
De SOSI-basisnavn som er beskrevet i dette kapittel kan kun benyttes for objekter bekskrevet med det grafiske elementet .TEKST.
Selve tekststrengen angis med SOSI-navnet ..STRENG.
| Definisjon |
Kodeverdi |
Forklaring |
| .DEF |
Eksempel: |
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.
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 |
Eksempel: |
F Dersom bredde ikke er oppgitt, benyttes standard bredde for den gitte teksthøyden jfr. fonten.
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 |
Eksempel: ..DIM 56 67 |
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 |
0 |
![]() |
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
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 |
<verdi> |
Skriftlengden i mm på presentasjonsmediet. |
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-NR H3 |
SKTFSYMP SKTFSYMU <0,255> |
|
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.
Nedenfor følger noen SOSI-gruppe definisjoner for TEKST.
| Tekstdata - enkel tekst. |
| .TEKST <serienummer>: |
|
| Tekstdata - flere linjer. |
| .TEKST <serienummer>: |
| Symbol. |
| .TEKST <serienummer>: |
Eksempel kan være markslagssymboler som har flere presentasjoner pr. polygon. |
| ! Fastmerkenummer .TEKST 17: |
!navn på innsjø .TEKST 17: |
| !Gnr,bnr |
!Gnr,bnr .TEKST 17: |
Se også eksempler i SOSI-DEL 3
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).
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: |
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: .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:
![]() 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: .FLATE 52: ![]() |
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.
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.
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.
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 ...H-NØYAKTIGHET ...MAX-AVVIK |
H5 H6 |
|
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 |
Målemetode |
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).
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. |
| 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 2 |
|
| .HODE 0: |
.HODE 0: |
| 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. |
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) |
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 |
|
Den delen av den totale flata som ikke inneholder selve representasjonspunktet, men et hjelpepunkt. |
Se forøvrig under randproblematikk
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 |
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 |
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 |
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 |
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. |
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
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
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 |
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 |
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.
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 |
|
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.
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.
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.
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)
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.
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.