LÃ¸ype for omkoding av arealplandata fra SOSI-versjon 3 ... - Kartverket

Håndbok i produksjon og forvaltning av Plandata 

Statens kartverk Landdivisjonen Handbok i PROFF 3 

Dokument tittel: FYSAK – Plandata til SOSI ver4.0 Side 1 av 22 

Dokument nr.: SKLD/ Versjon: 1.0 

Filident: FYSAK - Plandata til SOSI ver40_20080915.doc Iverksettingsdato: 11.02.2008 

FYSAK 

Plandata til SOSI ver. 4.0 

Kommune- og reguleringsplaner 

1 Endringslogg 

DATO Utført av Kort beskrivelse av endring 

20080211 Berit Nordtug, SK Steinkjer Versjon 1.0 

20080304 Berit Nordtug, SK Steinkjer BUE og SIRKEL kan ikke konverteres direkte til .KURVE, kap 

9.3.1. Omkodingsmakro Plan_Omkod-34_40.mko tilpasset. 

Fremgangsmåte for rydding i doble temakoder (sosi 3.4)for 

objekttypene KpSamferdselLinje og RbJuridiskLinje. kap 

9.4.1 

20080307 Berit Nordtug, SK Steinkjer BUEP og SIRKELP er lagt inn som tillatt geometri og er inkludert 

i makro som legger objekttype på gruppene; Plan_40-Legg til 

objtyper.mko. 

20080915 Berit Nordtug, SK Steinkjer Lagt inn forslag med anbefaling om å sammenligne sluttresultat 

med plankartet, som er det juridisk riktige dokumentet (kap. 

9) 

1 ENDRINGSLOGG 1 

1.1 Hjelpemidler og dokumentasjon 3 

1.1.1 Standardene 3 

1.1.2 Endringslogger 4 

1.1.3 Makroer 4 

1.1.4 FYSAK-versjon 4 

1.1.5 Sosi-kontroll og definisjonsfiler 4 

1.1.5.1 Definisjonsfiler under SOSI 5 

1.1.5.2 Definisjonsfiler under AREALIS 6 

1.1.6 FYMASS-overbygning 6 

Statens kartverk 2007 Kap. 1 Plan Side 1


1.2 Anbefalinger før omkoding 6 

1.2.1 Skjematisk oversikt over arbeidsprosessen 6 

2 SOSI-VERSJON 3.0 (JULI 1997) 9 

2.1 Endringer fra 2.21 til 3.0 9 

2.1.1 Generell del 9 

2.1.2 Plankapittel generelt 9 

2.1.3 Manuelle operasjoner 9 


3 SOSI-VERSJON 3.1 (OKTOBER 1999) 9 




3.1.3 Endringer kommuneplaner 10 

3.1.4 Endringer reguleringsplaner 10 


4 SOSI-VERSJON 3.2 (JUNI 2000) 10 






4.1.5 Makroer og resultatfiler 11 

5 SOSI-VERSJON 3.3 (SEPTEMBER 2001) 11 







6 SOSI-VERSJON 3.4 (JUNI 2002) 12 






6.1.5 Manuelle operasjoner 12 


7 SOSI-VERSJON 4.0 (NOVEMBER 2006) 12 


7.1.1 Fra kap. ”Realisering SOSI/GML” 12 

7.1.2 Fra kap. ”Generelle typer” 13 






7.1.6 Om datoegenskaper i plandata versjon 4.0 13 

7.1.7 Nye firesifrede kodeverdier i sosi 4.0 14 


8 LISTE OVER HJELPEFILER 14 

8.1 Omkodingsmakroer 15 

8.2 Filer for andre oppgaver 16 

8.3 Tegneregler 16 

9 TYPISKE FEILSITUASJONER 16 

9.1 Feil i hode 17 

9.1.1 Feil tegnsett 17 

9.1.2 Feil sosi-versjon 17 

9.2 Feil i generelle egenskaper 17 

9.2.1 ..DATO og ..KVALITET 17 

9.3 Feil egenskapsinformasjon 18 

9.3.1 Doble eller multiple temakoder 18 

9.3.2 Feil bruk av kodeverdier 19 

9.3.3 Ustandardiserte egenskaper og egenskapskoder 19 

9.4 Feil i geometri 20 

9.4.1 Konvertering av .BUE og .SIRKEL 20 

9.4.2 Doble linjer 20 

9.4.3 FKB-data i planene 20 

9.4.4 Geometrikontroller og rydding 21 

9.4.4.1 KP/Konsistenssjekk 21 

9.4.4.2 Gap mellom linjer som avgrenser flate 21 

9.4.4.3 KP/Delområde 21 

1.1 Hjelpemidler og dokumentasjon 

1.1.1 Standardene 

I hver versjon av standardene er det tilknyttet en del som omhandler generelle egenskaper. I 

eldre versjoner av standarden het denne gjerne Del 1_2. Generell del (Praktisk bruk, 

geometri) og tar for seg regler for hodeinformasjon, tillat geometri og egenskapskoding av 

geometri i sosi-fila. Det inneholder også informasjon om bruk og koding generelle egenskaper 

som dato og kvalitet. 

I versjon 4.0 er standarden bygget opp annerledes. Del 1_2 Realisering SOSI/GML tar for 

seg regler for hodeinformasjon, geometri og koding av geometri. Kapitlet Generelle typer har 

informasjon om egenskaper i metadata og egenskaper som er benyttet i flere fagtema. Dette 

gjelder bruk og koding av egenskaper som blant andre dato, kvalitet, kartbladkant, 

fiktivdelelinje, temakartavgrensning og kantutsnitt. Se figur i kapittel 6.2.1 for oversikt. 



Disse kapitlene må brukes i tillegg til selve Planstandarden for å få full oversikt over tillatte 

egenskaper og kodeverdier. 

1.1.2 Endringslogger 

I hver standard er det ett kapittel som opplister endringene fra forrige versjon. Dette er 

endringsloggen. Ikke alle endringer listet i endringsloggen har direkte betydning for 

omkodingsløypa. Enkelte endringer er heller ikke anført i endringsloggene. Endringer som er 

anført i endringsloggen og som har betydning for omkodingsløypa er gjengitt først i hvert 

kapittel under aktuell standard i dette dokumentet. 

1.1.3 Makroer 

Vår erfaring med plandata tilsier at de aller fleste kommuner etablerer og lagrer plandata som 

samlefiler. Makroene er derfor laget for samlefiler. Dette har gjort det betydelig enklere å lage 

en omkodingsløype. Alle objekter som skal omkodes til ny objekttype kan derfor omkodes i 

den samme fila. Objekter som blir flyttet ut er objekter som går ut, og som det i ny standard 

ikke har kommet ny egenskap/kode for. Disse er det ikke behov for å utføre etterarbeid på, 

men sjekk at det ikke er flyttet ut objekter som skal med i planen. Data kan være feilkodet. 

Ved utvikling av omkodingsmakroene er det tatt utgangspunkt i endringsloggen i de enkelte 

versjonene av standarden, men ikke alle endringslogger i de ulike versjonene er fullstendige. 

Makroene kan derfor ha mangler. 

Trolig vil det ikke være så stort behov for å benytte omkodingsmakroer for data etablert etter 

de eldste versjonene av standarden, men det er laget et opplegg for alle plandata fra versjon 

2.2 frem til siste versjon 4.0. For de eldste versjonene har det vært vanskelig å finne 

eksempeldata å teste makroene på og de kan også derfor ha feil. 

I arbeidet med tilrettelegging og testing av makroer i omkodingsløypa er det avslørt en god 

del feil og/eller mangler i etablerte plandata. Omkodingsmakroene kan ikke finne og korrigere 

feil i data, de kan ’bare’ omkode data som er kodet i henhold til standardene. 

Dokumentasjon, makroer, kommandofiler og andre hjelpemidler finnes i mappen Makroer og 

kommandofiler på H:\Land\Prod_Fag\Plan_Areal_Miljo\Plandata\Omkoding. Kommandofiler 

legges på standard katalog på (U:\Kommandofiler) eventuelt lokalt på C:\Kommandofiler. 

Husk å sette filsti til MKO (makroer) i FYSAK under Fil/Oppsett. 

Om det blir funnet feil eller mangler i makroer eller kommandofiler og disse må redigeres, gi 

beskjed til undertegnede. 

1.1.4 FYSAK-versjon 

Ved omkoding av plandata eldre enn versjon 3.4 kan man benytte FYSAK-versjon F 2.8. For 

omkoding og bearbeiding av data fra 3.4 til 4.0 bør FYSAK-versjon G benyttes. Ved kjøring 

av FYMASS-løype benyttes FYSAK-versjon G. 

1.1.5 Sosi-kontroll og definisjonsfiler 

Hvis datasett har mange feil, kan det være hensiktsmessig å kjøre noen manuelle kontroller og 

eventuelt rydde før kjøring av omkodingsmakro. Uansett bør doble/multiple temakoder 

fjernes, og .BUE og .SIRKEL omkodes til .KURVE før kjøring av makro eller FYMASSløype. 

Har datasettene få feil kan man vente med å kjøre sosi-kontroll og geometrikontroller 

til etter at makro er kjørt. Om det må kjøres omkoding i flere omganger, som fra versjon 3.1 



til versjon 4.0, kan det avdekkes feil ved å kjøre sosikontroll mellom hver makro. Har 

datasettene lite feil kan alle makroer kjøres før det utføres sosi-kontroll. Se flytskjema under. 

Det anbefales at sosikontroll kjøres på definisjonsfiler både fra SOSI og fra AREALIS der 

disse er utarbeidet. 

1.1.5.1 Definisjonsfiler under SOSI 

Under H:\Skfelles\SOSI-kontroll\def\ finnes definisjonsfiler for sosikontroll for de ulike 

versjonene. Det finnes to utgaver; En for generelle plandata under SOSI, og en for plandata 

med spesifikasjoner etter AREALIS. Det må presiseres at sosi-kontroll for plan for eldre 

versjoner under SOSI ikke er så gjennomarbeidet som de tradisjonelt har vært for FKB-data. 

For sosi-kontroll av plandata etablert før versjon 3.4 vil derfor sosi-kontroll ikke gi 

omfattende lister over feil i data. 

Figur 1. Oppsett i sosikontroll for å bruke definisjonsfiler under SOSI. 

Det finnes ikke definisjonsfiler for sosi eldre versjoner enn 2.21. Det betyr at man ikke får 

kontrollert omkodet sosifil fra versjon 2.2 med SOSI-kontroll. Eventuelle kontroller må gjøres 

manuelt. 

For sosi-versjon 3.1 er det ikke laget definisjonsfiler for sosikontroll. Dette skyldes at 3.1 

versjonen ble utgitt på nytt av hensyn til endringer i Plan og bygningsloven, men endringene 

har ingen betydning for geometri eller egenskapsinformasjon. 



For versjon 4.0 er det i følge ryktene gjort et mer grundig arbeid med tilrettelegging av 

definisjonsfiler for sosikontroll, noe som betyr at sosikontroll er forbedret sammenlignet med 

tidligere versjoner. Bruk derfor definisjonsfiler fra SOSI/Plan for kontroll av planer i 

sosiversjon 4.0. 

1.1.5.2 Definisjonsfiler under AREALIS 

Under H:\Skfelles\SOSI-kontroll\def finnes også definisjonsfiler for de ulike fagdatalagene 

etter AREALIS. Disse finnes for sosi-versjon 3.2 til og med versjon 3.4. Når og om disse 

oppdateres til versjon 4.0 er fortsatt uklart. 

1.1.6 FYMASS-overbygning 

Det antas at de aller fleste har behov for tilrettelegging av omkodingsløype for plandata fra 

versjon 3.4 til 4.0. I første omgang er det derfor laget en overbygning for FYMASS for dette 

trinnet. FYMASS-løypa er tilrettelagt av Knut Reisæter ved SK Hamar. Har du spørsmål til 

FYMASS-løypa, ta kontakt med Knut. 

1.2 Anbefalinger før omkoding 

Omkodingsmakroene inneholder omkodingssyntaks for både kommune- og reguleringsplaner. 

En plan er etter vår erfaring oftest etablert som ei stor fil, og er ikke splittet i de enkelte 

fagdatalag slik vi er vant til å se de i Arealis. Alle makroer er derfor laget med hensyn på 

samlefiler. Ved kjøring av omkodingsmakro i FYSAK kan derfor mange samlefiler ligge i 

forgrunnen. 

I enkelte versjoner av standardene gjelder endringene objekter som får ny temakode og nytt 

objektypenavn. Objektet tilhører da et annet fagdatalag og ved lagring av plandata i egne 

fagdatalag må objektet flyttes til riktig fil. Ved omkoding i samlefil kan alle objekter omkodes 

i samme fil og man behøver ikke å tenke på flytting mellom fagdatalag. Plandata som er 

splittet i enkeltfiler bør sammenstilles til ei stor sosi-fil og eventuelt splittes etter omkoding. 

Før kjøring av makroene vil det være fornuftig å sjekke at sosi-fila faktisk foreligger i den 

sosi-versjon som er angitt i hode. Ofte viser det seg at informasjon i hode ikke stemmer med 

innholdet i fila. Sosi-kontroll vil avdekke om det er misforhold. 

Det har vist seg at elementer som skaper størst problemer under og etter omkoding er 

doble/multiple temakoder og .BUE/.SIRKEL. Fjern derfor doble temkoder og konverter 

.BUE/.SIRKEL til .KURVE før omkoding. Dette vil spare deg for mye arbeid etter omkoding. 

Se fremgangsmåter i kapittel 9. 

I kapittel 9 er det nevnt noen typiske feilsituasjoner som vi har støtt på under arbeidet med 

makroene. Se oversikten og rydd eventuelt før kjøring av manuell omkodingsløype med 

FYSAK eller med FYMASS. 

1.2.1 Skjematisk oversikt over arbeidsprosessen 

Nedenfor finner du en oversikt over de ulike trinnene i arbeidet med for å få datasettene 

gjennom omkodingsløypa hvis du gjør det manuelt ved bruk av FYSAK. 





Flytskjema for omkoding ved bruk av FYSAK 



2 Sosi-versjon 3.0 (Juli 1997) 

2.1 Endringer fra 2.21 til 3.0 

2.1.1 Generell del 

..TRANSSYS – Fantes også tidligere, men er nå lagt under TRANSPAR på treprikksnivå 

…TRANSPAR (HODE-informasjon). 

2.1.2 Plankapittel generelt 

Endringer skyldes tilpasninger til ny utgave av Plan- og bygningsloven og har ikke betydning 

for omkodingsløypa. 

2.1.3 Manuelle operasjoner 

I omkodingsmakroen er det ikke gjort tilpasninger for endring av TRANSSYS fra 

toprikksnivå til treprikksnivå. Det antas at denne egenskapen er lite eller ikke brukt i hodeinformasjon 

ved egenskapskoding av plandata. Hvis egenskapen mot formodning er benyttet, 

vil sosi-kontroll liste den ut som feil på toprikksnivå. For enkeltfiler vil det være enklest å ta 

fila inn i TextPad og legge egenskapen inn under ..TRANSPAR manuelt. 

..TRANSPAR 

…TRANSSYS 

…TILSYS 

..KOORDSYS 

osv. 

Sjekk eventuelle detaljer i standarden. 

2.1.4 Makroer 

Makrofiler 

Forklaring 

Plan-Omkod-22_221_30.mko Omkoder fra sosi-versjon 2.2 til versjon 2.21 til versjon 

3.0. 

3 Sosi-versjon 3.1 (Oktober 1999) 



Bruken av ".. " utgår fra og med versjon 3.1. Bruker ..REF. 

Nytt grafisk element er innført. Symboler kan ikke lenger spesifiseres under det grafiske 

elementet .TEKST. SYMBOL som gruppeelement med SYMB-BIB og SYMB_NR under 



.TEKST utgår. Det grafiske elementet skal være identisk med det grafiske elementet .PUNKT, 

bortsett fra at det kan ha plasserings- og retningskoordinat. Det er ikke angitt hvilke 

egenskaper fra .TEKST som skal være tillat for .SYMBOL. 


Alle objekttypenavn er endret. 

3.1.3 Endringer kommuneplaner 

OPLRESTR 

Kode 149 endret til 142 

3.1.4 Endringer reguleringsplaner 

REGFORM 

Kode 622 endret til 646 

TEMAKODER 

LTEMA 1205 endret til 1259 

3.1.5 Makroer 

Makrofiler 

Forklaring 

Plan-Omkod-30_31.mko Omkoder fra sosi-versjon 3.0 til versjon 3.1 

4 Sosi-versjon 3.2 (Juni 2000) 



Endringer har ikke betydning for omkodingsløypa. 


Endringer har ikke betydning for omkodingsløypa. 


Justeringer i innholder for Arealbruk og båndlegging under planbestemmelser. 

Båndleggingsområder er fjernet og objekttypene KP_Blegg og KP_BleggGr slettes og er ikke 

tillatt i versjon 3.2. 

OPLAREAL: Følgende koder er slettet og erstattet 

Kode 430 erstattes av OPLRESTR 400 Restriksjoner etter annet lovverk 


Kode 441 erstattes av OPLRESTR 410 Nedslagfelt drikkevann 



Kode 442 erstattes av OPLRESTR 411 Område for grunnvann 


Kode 451 erstattes av OPLRESTR 420 Flystøysone 

OPLRESTR 

Kode 149 er slettet (obs; koden var tidligere 142, se versjon 3.1) 


Endringer har ikke betydning for omkodingsløypa 

4.1.5 Makroer og resultatfiler 

Makrofiler 

Forklaring 

Plan-Omkod-31_32.mko Omkoder fra sosi-versjon 3.1 til versjon 3.2. 

Resultatfiler 

Objekter_utgår_32.sos 

Forklaring 

Objekter som etgår er flyttet ut til egen fil. 

5 Sosi-versjon 3.3 (September 2001) 



..OBJTYPE er påkrevet egenskap, mens temakode er opsjonell. 

Egenskapen RFLATE fjernes nå som OBJTYPE er påkrevet (tidligere benyttet for å merke 

.PUNKT som skulle flatedannes). 

PINFO på kurve har ikke mening og er ikke tillatt. 


Alle objekttypenavn er endret. 


TEMAKODER 

LTEMA 1199 (KPSamferdselLinje) er endret til 1162 

PTEMA 1199 (KPSamferdselPunkt) er endret til 1162 


REGFORM 

Kode 659 er endret til 652 



Kode 599 er endret til 646 


Makrofiler 

Forklaring 

Plan-Omkod-32_33_34.mko Omkoder fra sosi-versjon 3.2 til versjon 3.4 

6 Sosi-versjon 3.4 (Juni 2002) 





Geometritypen KURVE er fjernet fra alle objekttyper, men disse kodes ikke om til LINJE i 

omkodingsmakro siden KURVE gjeninnføres og erstatter LINJE i versjon 4.0. 





6.1.5 Manuelle operasjoner 

Det at KURVE ikke omkoder til LINJE vil gi feil i sosi-kontroll, men feilmeldinger på dette 

kan man overse. .KURVE erstatter .LINJE i versjon 4.0. 


Makrofiler 

Forklaring 

Plan-Omkod-32_33_34.mko Omkoder fra sosi-versjon 3.2 til versjon 3.4 

7 Sosi-versjon 4.0 (November 2006) 


7.1.1 Fra kap. ”Realisering SOSI/GML” 

All bruk av temakoder er erstattet med objekttypenavn. 

LINJE utgår, kodes om til KURVE (tilpasning til internasjonale standarder). Forskjellen 



mellom LINJE og KURVE har vi ikke i GML, det at KURVE kan glattes må ivaretaes på en 

annen måte. 

BUE utgår, erstattes med BUEP, for å gjøre overgangen til GML enklere 

SIRKEL utgår, erstattes med SIRKELP, for å gjøre overgangen til GML enklere 

Punktinformasjon (PINFO) er tatt ut. De punkter i en linje som tidligere hadde temakode som 

punktinformasjon blir skilt ut som egne objekttyper. Dette gjelder spesielt punkter i en 

teiggrense. 

7.1.2 Fra kap. ”Generelle typer” 

Det er i sosi-versjon 4.0 innført flere alternative egenskaper for å angi dato på SOSI_objekt i 

Plan. . ..DATO i plan for eldre versjoner blir omkodet til ..DATAFANGSTDATO. Hvordan 

datokodingen skal praktiseres for nyere plandata er foreløpig uklart. Det er satt i gang arbeid 

for å etablere en egen planspesifikasjon hvor disse tingene skal avklares. 


Alle objekter skal være kodet med ..KVALITET og dato. Dette betyr at objekter som mangler 

disse egenskapene skal påføres dette etter eventuell informasjon i sosi-filas hode. Når alle 

objekter er påført disse egenskapene vil det ikke gi mening å beholde denne informasjonen i 

hode. ..KVALITET og dato i sosi-hode kan dermed slettes. 


KpSamferdselLinje har fått ny egenskap TYPESAMFLINJE og verdidomenet til egenskapen 

er en kodeliste der kodene er de mulige verdiene objekttypen tidligere kunne ha som 

temakode. 

KpSamferdselPunkt har fått ny egenskap TYPESAMFPUNKT verdidomenet til egenskapen 

er en kodeliste der kodene er de mulige verdiene objekttypen tidligere kunne ha som 

temakode. 

I fila for objektdefinisjoner Plan_o.40 mangler verdien 590 som lovlig verdi for egenskapen 

..OPLAREAL. 


RbJuridiskLinje har fått ny egenskap TYPEJURLINJE, verdidomenet til egenskapen er en 

kodeliste der kodene er de mulige verdiene objekttypen tidligere kunne ha som temakode. 

RbJuridiskPunkt har fått ny egenskap TYPEJURPUNKT, verdidomenet til egenskapen er en 

kodeliste der kodene er de mulige verdiene objekttypen tidligere kunne ha som temakode 

7.1.6 Om datoegenskaper i plandata versjon 4.0 

I følge sosi-kapitlet om generelle egenskaper i versjon 4.0 er det nå totalt 6 mulige 

datoegenskaper som kan benyttes. I standarden heter det at ”VERIFISERINGSDATO er 

identisk med ..DATO i tidligere versjoner av SOSI”. Under definisjonen av egenskapen heter 

det at egenskapen kan benyttes når en har fastslått at objektet som finnes i basen fortsatt er i 

samsvar med virkeligheten. Denne definisjonen forutsetter at geometri kan endres slik at den 

fortsatt skal være i samsvar med virkeligheten, men dette vil ikke harmonere med realitetene 

med hensyn på forvaltning av plandata. Når planen er ferdig utformet blir den behandlet og 

vedtatt, og den blir ikke endret med mindre det skjer konkrete justeringer eller endringer i 



planen etter nye vedtak. Ikke alle mindre vesentlige endringer blir oppdatert i den digitale 

planen. 

Her er det mange muligheter, men ved omkoding av eldre plandata er det vanskelig å vite 

hvilken opprinnelse geometrien har. ..DATO i eldre planer blir foreløpig omkodet til 

..DATAFANGSTDATO. Vær oppmerksom på at det kan komme endringer når 

planspesifikasjonen er ferdig utarbeidet. 

7.1.7 Nye firesifrede kodeverdier i sosi 4.0 

I sosi-versjon 4.0 er det lagt til nye firesifrede kodeverdier for egenskapen 

..TYPESAMFLINJE (kommuneplan) og ..TYPEJURLINJE (reguleringsplan). Disse må ikke 

forveksles med tidligere temakoder. Nye koder her er 1143, 1155 og 1235, som koder 

henholdsvis skitrekk og taubane i kommuneplan og sikringsgjerde i reguleringsplan. 


Makrofiler 

Forklaring 

Plan-Omkod-34_40.mko Omkoder fra sosi-versjon 3.4 til versjon 4.0 

8 Liste over hjelpefiler 

I tillegg til omkodingsmakroene er det utviklet en del filer og makroer det kan være kjekt å ha 

i arbeidet med omkoding av plandata. Nedenfor finner du ei liste over alle og en kort 

forklaring til hva de ulike filene og makroene kan brukes til. 



8.1 Omkodingsmakroer 

Filnavn 

Forklaring 

Plan_Omkod-34_40.mko Omkoder fra sosi-versjon 3.4 til versjon 4.0; 

Konverterer .LINJE til .KURVE 

Fjerner all PINFO på .KURVE 

Konverterer .BUE og SIRKEL til .KURVE 

Omkoder .DATO til .DATAFANGSTDATO 

Legger på ..REGISTRERINGSVERSJON PLAN ”3.4 eller 

eldre” 

Grupper som mangler ..KVALITET, 

..DATAFANGSTDATO og ..OBJTYPE merkes med ..FEIL 

Kommuneplan 

Omkoder ..LTEMA til ..TYPESAMFLINJE for utvalgte 

temakoder 

Omkoder ..PTEMA til ..TYPESAMFPUNKT for utvalgte 

temakoder 

Sletter alle temakoder 

Reguleringsplan 

Omkoder ..LTEMA til ..TYPEJURLINJE for utvalgte 

temakoder 

Omkoder ..PTEMA til ..TYPEJURPUNKT for utvalgte 

temakoder 

Sletter alle temakoder 

Plan_Omkod-32_33_34.mko Omkoder fra sosi-versjon 3.2 til versjon 3.4. Brukes også til 

omkoding fra 3.3 til 3.4; 

Omkoder alle objekttypenavn 

Legger objekttype på objekter som mangler 

Kommuneplan 

Omkoder ..LTEMA 1199 til 1162 

Omkoder ..PTEMA 1199 til 1162 


Omkoder ..REGFORM 659 til ..REGFORM 652 

Omkoder ..REGFORM 599 til ..REGFORM 646 

Plan_Omkod-31_32.mko Omkoder fra sosi-versjon 3.1 til versjon 3.2. 

Kommuneplan 

Omkoder objektene og egenskapen ..OPLAREAL i 

KP_Blegg og KP_BleggGr til ..OPLRESTR i ..KP_Restr og 

..KP_RestrGr 

Plan_Omkod-30_31.mko 

Alle objekttyper er endret. 

Kommuneplan 

..OPLRESTR 149 omkodet til ..OPLRESTR 142 


..REGFORM 622 omodet til ..REGFORM 646 



8.2 Filer for andre oppgaver 

8.3 Tegneregler 


Forklaring 

Plan_40-Polygoniser.kom Gjør utvalg på enkelt objekter og danner flater. For 

flatedanning av filer på sosi-versjon 4.0 

Plan_40-Flytt-FKB-data.mko Gjør utvalg på objekttyper i plan og gjør motsatt utvalg. 

Gruppene i utvalget flyttes til egen fil. OBS! Gjøres i 

samråd med eier av planen(e). 

Plan_40-Legg til objtyper.mko Legger objektyper på grupper som ikke har det. Gjør utvalg 

på temakoder, legger på objtype og sletter temakodene. 

Plan_40-Kopier-tilfagdatalag.mko 

fagdatalag etter Arealis. 

Gjør utvalg på objekttyper og kopierer objekter til eget 

Plan_40-Flytt-tilfagdatalag.mko 

etter Arealis. Om det gjenstår noe i fila det er flyttet fra, 

Gjør utvalg på objtyper og flytter objekter til eget fagdatalag 

hører ikke disse til i plandatafila. 

Plan-40-Utvalg_temakoder.txt Gjør utvalg på temakoder som bør skjekkes for doble 

temakoder. 


Tegneregler-regplan_40.kom 

Tegneregler-regplan_40_utentekst-regform.kom 

Tegneregler-komplan_40.kom 

Tegneregler-regplan_34.kom 

Tegneregler-komplan_34.kom 

Forklaring 

Tegner ut reguleringsplan etter sosi-versjon 4.0 i FYSAK, 

med automatisk tekst på de ulike reguleringsformålene (ikke 

alltid like praktisk når planen er etablert med egen tekstfil) 

Tegner ut reguleringsplan etter sosi-versjon 4.0 i FYSAK, 

men uten tekst på de ulike reguleringsformålene. 

Tegner ut kommuneplan etter sosi-versjon 4.0 i FYSAK 

Tegner ut reguleringsplan etter sosi-versjon 3.4 i FYSAK 

Tegner ut kommuneplan etter sosi-versjon 3.4 i FYSAK 

9 Typiske feilsituasjoner 

Standardene har opp gjennom årene vært utformet slik at det har gitt rom for tolkning og/eller 

misforståelser. Ved etablering av digitale data har det derfor vært mange muligheter for å 

gjøre feil. Noen har dessuten funnet det hensiktsmessig å lage egne koder og egenskaper som 

de benytter ved fremstilling av sine planer. Det er derfor mange forhold som kan bidra til at 

omkodingen ikke går som den skal. 

I arbeid med omkodingsløypa er det avslørt en del feilsituasjoner som er enkle å forutse. 

Mange feil er det imidlertid vanskelig å forutse, og det er nettopp disse det er vanskelig å 

håndtere med automatiske operasjoner. 

Det kan være vanskelig å se hva som er feil kodet før du starter makroen. I alle tilfelle 

anbefales det at du har en papirutgave av planen(e) foran deg før du starter. Bruk 

kommandofil for uttegning av planene etter koding, og sammenlign sluttresultatet med 



papirutgaven. 

9.1 Feil i hode 

9.1.1 Feil tegnsett 

Sosi-standarden lister opp flere alternativer for tillatte tegnsett i sosi-fila. Om du får 

feilmelding om tegnsett, kan det likevel være brukt tegn i fila som som resulterer i 

feilmelding. Bruk evt. funksjonen FxTsDos8, FxTsIso eller FxTsND7 for å konvertere fila til 

annet tegnsett. Alle program konverterer fra et vilkårlig tegnsett. 

9.1.2 Feil sosi-versjon 

Ofte stemmer ikke hode-informasjon med det som er innholdet i fila. Sosi-kontroll vil 

avdekke feilen. 

FYMASS-løypa håndterer konvertering til ny sosi-versjon (3.4 til 4.0) og omkoder i filhode. 

9.2 Feil i generelle egenskaper 

9.2.1 ..DATO og ..KVALITET 

Hvis dato og kvalitet mangler på gruppene i fila kan disse legges på etter omkoding. Dato og 

kvalitet fra hode kan overføres til objektene nede i fila. Det finnes ikke en enkel måte å gjøre 

dette på i FYSAK, så her må det gjøres en manuell operasjon. 

Fremgangsmåte sosi 3.4 og eldre 

Sjekk datoen i hode på sosifila. 

Gjør utvalg på ..DATO ! (alle objekter som mangler 

..DATO) eller på ..FEIL = ”Mangler DATO”(etter 

omkoding) 

Mred/Omkod-GINFO (se figuren til høyre) 

Fremgangsmåte sosi 4.0 

Sjekk datoen i hode på sosifila. 

Etter omkoding 

Gjør utvalg på ..DATAFANGSTDATO ! (alle objekter 

som mangler ..DATAFANGSTDATO) 

eller ..FEIL = ”Mangler DATO” 

Mred/Omkod-GINFO (se figuren til høyre) 

Gjør tilsvarende operasjon for å legge ..KVALITET på objektene nede i fila. 



9.3 Feil egenskapsinformasjon 

9.3.1 Doble eller multiple temakoder 

Temakoder fra FKB + temakode for plan 

I plandata er geometrien ofte kopiert fra FKB-data, og man man har ikke alltid brydd seg med 

å omkode til riktig linjetema eller objekttype slik at de følger Planstandarden. Doble 

temakoder vil skape problem hvis de ikke blir fjernet før kjøring av makroer eller FYMASSløype. 

Sjekk derfor om det finnes grupper som har doble temakoder i datasettet. Har du 

temakoder fra FKB-data sammen med temakoder fra plan kan temakodene fra FKB-data 

fjernes helt. Hent inn fila Utvalg-temakoder.txt i Utvalg/Egenskap for å velge ut temakoder 

det er viktig å rydde i før makroen kjøres. 

Fremgangsmåte 

Ved bruk av M-Red/OmkodGInfo vil man ikke kunne bruke 

operatorer som > (større enn) og < (mindre enn) for å slette 

temakoder. Det betyr at man manuelt må skrive syntaks for hver 

enkelt temakode for å slette. 

Temakoder fra plan + temakode for plan 

Enkelte grupper kan ha doble/mulitiple temakoder 

som alle tilhører plan. Her kan man ikke slette 

temakoder ukritisk. Dette gjelder tilfeller der det er 

doble/multiple temakoder på objekter med følgende 

temakoder i kommuneplan (se filen Plan-40-utvalgtemakode.txt); 

..LTEMA = 1120 

ELLER ..LTEMA = 1121 
















ELLER ..LTEMA 1120 1122 









I kommuneplan vil disse temakodene i 4.0 omkodes til ..TYPESAMFLINJE og får objekttype 

..KpSamferdselLinje. Hvis disse temakodene i tillegg har temakodene 1102 

(KpArealbrukGrense), 1104 (KpRestriksjonGrense) eller 1110 (KpRetningslinjeGrense) vil 

det skape problem ved flatedanning og ved uttegning av planen. Hvis temakode 1102 fjernes 

fra gruppen vil den tilgrensende flaten ikke få en avgrensingslinje, og fjernes 1120 vil det se 

ut som vegen stopper ved grensen til flaten. Dette skyldes at KpSamferdselLinje ikke kan 

avgrense flaten KpArealbrukOmråde. Samme problemstilling oppstår med temakodene 1104 

og 1110. 

For reguleringsplan vil tilsvarende problem oppstå ved doble/multiple temakoder fra plan på 

følgende temakoder; 

..LTEMA 1203 1204 

..LTEMA 1210 1215 

..LTEMA 1221 1227 

..LTEMA = 1235 

..LTEMA = 1252 

..LTEMA = 1254 

..LTEMA = 1259 

Temakodene omkodes til til egenskapen ..TYPEJURLINJE og får objekttypen 

..RbJuridiskLinje. Doble/multiple temakoder sammen med verdiene 1202 (RbFormålGrense), 

1205 (RbFareGrense), 1206 (RbRestriksjonGrense), 1207 (RbBevaringGrense), 1208 

(RbFornyelseGrense) og 1209 (RbRekkefølgeGrense) må ryddes før omkoding. 


Siden hverken ..KpSamferdselLinje eller ..RbJuridiskLinje kan være avgrensingslinjer for 

flatene til nevnte grenser må det lages en nøyaktig kopi av linjene. Hvis vi i for eksempelet 

har en linje som både har temakode 1120 og 1102, lages det en kopi av linjen. Den ene linjen 

beholder opprinnelig koding, men man fjerner dobbel temakode (1102). Den nye kopierte 

linjen får temakode 1102 og ..OBJTYPE KpArealbrukGrense med tilhørende egenskaper. Sett 

ny dato på linjen. Alle temakoder vil bli fjernet ved omkoding til SOSI-VERSJON 4.0. 

9.3.2 Feil bruk av kodeverdier 

Egenskapene ..OPLAREAL og ..REGFORM har lange lister med kodeverdier, men 

kodeverdiene kan bare benyttes på bestemte objekttyper. Av de eldre versjonene av 

standarden kan det være vanskelig å skjønne hvilke koder som skal benyttes på de enkelte 

objekttypene. Får du feilmelding på kodeverdier eller objekttype kan det være nyttig å se i 

objektdefinisjonsfilene for den enkelte egenskapen. 


På fellesområdet H:\Skfelles\SOSI-kontroll\def\sosi finner du mapper med definisjonsfiler for 

sosi-kontroll for den enkelte versjon av sosi-standarden. Gå inn på mappa for den aktuelle 

standarden, kopier fila Plan_o.nn til ei lokal mappe og åpne den i TextPad. Søk ut den 

aktuelle egenskapen og sjekkk hvilken kodeverdi de enkelte objekttypene har som lovlige 

9.3.3 Ustandardiserte egenskaper og egenskapskoder 



I mange plandata er det benyttet egenskaper og egenskapskoder som ikke er tillatt etter 

standarden. Dette gjelder spesielt temakoder. Mange har, i mangel av passende koder, laget 

egne temakoder. Disse vil makroene naturligvis ikke gi tilslag på når man for eksempel skal 

legge objekttyper på geometri etter temakoder. Geometri som har feil temakoder må evt gis 

riktig temakode før bruk av makro eller FYMASS-oppgave. Makroene er bygget opp omkring 

tillatte temakoder og egenskaper etter sosi-standarden. 

9.4 Feil i geometri 

9.4.1 Konvertering av .BUE og .SIRKEL 

BUE og SIRKEL er ikke lenger tillatt. I makro for omkoding av buer og sirkler i FKB-data 

har man konvertert slik geometri direkte til .KURVE. For PLAN og DEK er dette ikke bra. 

Ved omkoding direkte til .KURVE vil man tape informasjon som er viktig i disse to 

datasettene. Geometri av denne typen som er riktig etablert og som ikke har feil vil håndteres 

av omkodingsmakro, og konverteres til BUEP og SIRKELP. .BUEP og .SIRKELP er lovlige 

geometrityper i SOSI 4.0. 

BUE og SIRKEL som er etablert feil vil ikke konverterteres automatisk. Disse må det gjøres 

en manuell operasjon på etter at omkodingsmakro er kjørt. Buer og sirkler som ikke er 

konvertert riktig i omkodingsløypa vil bli merket ..FEIL 

GEOMETRITYPE_IKKE_OMKODET. 

BUE og SIRKEL konverteres først til BUEP/SIRKELP og siden til .KURVE med 

MRed/Omkod geometri. For radier mindre enn 15 meter anbefales en nøyaktighet på max 5 

cm i avvik fra bue etter konvertering. 

9.4.2 Doble linjer 

Doble linjer blir ikke varslet i sosi-kontroll som kritiske feil i datasettene i nyere versjoner. 

Om man ønsker å rydde må alle flater fjernes før funksjonen Ordne/Fjern doble kurver kan 

benyttes. Husk da at det kan bli vanskelig å danne flater igjen. Det er laget en makro som 

danner flater i 4.0 data. 

Makrofiler 

Plan_Polygoniser-40.kom 

Forklaring 

Makro som gjør utvalg på linjer og punkt for en og en 

objekttype og danner flater. 

I plandata vil det forekomme doble flater. Sammenlign original fil og omkodet fil og 

kontroller om flatedanning er gjennomført riktig der det finnes doble flater. 

9.4.3 FKB-data i planene 

Svært mange planer inneholder geometri fra FKB-data. De er ment som tilleggsopplysninger 

til selve planen, men FKB-data som ikke er omkodet i henhold til Planstandarden og som ikke 

er beskrevet spesielt i dokumentasjonen til planen behøver ikke å ligge i planene. Hvis de er 

ment å være en del av planen (henger sammen med linjer med temakode/objtype etter 

planstandarden) skal de omkodes i henhold til Planstandarden og uttegnes etter tilhørende 

norm for fremstilling av planen. Om vedkommende data er ment som tilleggsopplysninger til 

planen kan de flyttes ut til egen fil og omkodes i henhold til reglene om fremstilling av 

illustrasjonsplan i Planstandarden. Dette vil ikke endre planens utseende ved rastrering og 



konvertering til evt. pdf, når illustrasjonsplanen legges i bakgrunnen før konvertering. I 

planforskriftens § 2 heter det at basiskart ikke er gjenstand for vedtak og i merknad til § 3 (i 

veiledende merknader til forskriften) heter det at tilleggsdata som er nødvendig for å 

produsere kartbilder (presentasjonsdata) skal holdes separat fra de enkelte primærdatasettene 

(basiskart). 

Beslutningen om å eventuelt flytte FKB-data ut fra planen skal tas i samråd med eier. Se 

kapittel 7.1.9 for koding (http://www.statkart.no/sosi/PDF/Plan.pdf ). 

Det er laget en egen makro som flytter FKB-data ut til egen fil. 

Makrofiler 

Plan-40-Flytt_FKBdata.mko 

9.4.4 Geometrikontroller og rydding 

Forklaring 

Makro som gjør utvalg på alle plandata, snur utvalget og 

flytter disse ut til egen fil. Operasjonen skal ikke gjøres uten 

i samråd med eier. 

I sosi-kontroll er det innebygd funksjonalitet for å kontrollere både egenskaper og geometri. 

Kontroll på egenskaper fungerer tilfredstillende, men på geometri er det fortsatt noe som kan 

gjøres. Følgende kontroller kan utføres i tillegg til sosi-kontroll; 

9.4.4.1 KP/Konsistenssjekk 

Funksjonen kontrollerer knutepunkt mellom tilgrensende linjer. Bruk funksjonen uten 

endringer i standardoppsettet, men hak evt. av for å lage feilrapport. Feilrapporten hentes frem 

i funksjonen Vis/Arbeidsliste - KP- feilliste konsistenssjekk. 

Knutepunktsfeil angis med en KP-verdi og kan bli vist grafisk ved å stille inn tegneregler i 

Tegn/Oppsett - Marker KP lag. 

Kp-verdi (-kode) Type (feil): 

900 Konnektert punkt. 

993 Feil punktinformasjon (ikke lik PINFO i Kp). 

994 Feil Z-verdi. 

995 Korte (små) datagrupper. 

996 Skjæring mellom linjer i nærheten av Kp, småpolygon. 

997 Parallelle linjer ut fra Kp. 

998 Vanlig konsistensfeil - løs ende. 

999 Lovlig ende. 

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

9.4.4.2 Gap mellom linjer som avgrenser flate 

Knutepunkt med avvik i x, y eller z-retning meldes som feil. Endekoordinaten til linjer som 

møtes i knutepunktet skal ha identisk koordinat. Bruk funksjonen Flate/5-feil (gap) for å 

kjøre kontroll. Feil blir vist grafisk. 

9.4.4.3 KP/Delområde 



Funksjonen henger sammen linjer som er nærmere hverandre enn søketoleransen. Bruk 

standard oppsett i KP/Oppsett ved valg av søketoleranse. Kjør KP/Delområde for å rydde i 

feil avslørt ved konsistenssjekk og gap mellom linjer.

LÃ¸ype for omkoding av arealplandata fra SOSI-versjon 3 ... - Kartverket

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?