Forvaltning av ustandardisert data for bruk i kommunalt innsynssystem

Saksbehandling krever hyppig bruk av temadata, og med Origo Innsyn tilbyr vi et verktøy hvor det er enkelt å organisere og hente inn aktuell temadata for å bygge beslutningsgrunnlag. I tilegg kommer mulighetene for ad hoc-anvendelser. Her nevner vi utføring av uttrekk, sammenstillinger og analyser samt spesifisering av situasjonsbetingede temakart i ArcGIS Pro. Oppretting av spissede apper og storymaps i AGOL er også en del av dette. Hvis vi begrenser fokus til data som enten hostes av Geodata fordi de er valgt som DOK, er lagt til kommunens AGOL eller ønskes lagt dit, kan vi igjen dele disse inn i:

Data som er understøttet av en SOSI produktspesifikasjon, ref GeoNorge produktspesifikasjoner
Data som defineres av kommunen, for et spesifikt formål.

Det er den siste kategorien denne veiledninga dreier seg om.

Grunnleggende råd for planlegging og oppbygging av et ustandardisert temadatasett

GIS-utøvere har definert sine egne datasett på sine egne premisser i ArcGIS-produkter siden disse kom på markedet. Verktøyene for dette har vært tilgjengelige, og det har aldri vært noen holdning i vårt miljø at en skal sette seg ned og vente på ett eller annet standardiseringsorgan når det foreligger et behov for å beskrive et fragment av virkeligheten med et nytt romlig datasett. Samtidig har vi her i Norge, i hvert fall de første tiårene med GIS, vært flinke til å etablere modeller og prinsipper som grunnlag for et felles 'språk' for å uttrykke romlige forhold gjennom SOSI-arbeidet. Derfor er det hensiktsmessig og viktig å bruke SOSI-egenskaper som er definert for fagområdeuavhengig anvendelse der de passer. Se oversikten over SOSI_Objekt, som er en slags container for slike egenskaper, i kap. 11.6 i SOSIDel1.

Først og fremst: Vurdér om det virkelig er behov for å definere datasettet helt fra grunnen av. Ofte kan tematikken i datasett som er ferdig produktspesifisert være dekkende. Så vil navning og tilleggsinformasjon/-egenskaper definere det nye datasettet som lokalt og avvikende fra et noenlunde tilsvarende nasjonalt datasett. Om en i denne prosessen finner ut at nasjonal data som allerede finnes dekker behovet, kan en jo bare slå seg til ro med det.

En annen god regel er å låne egenskaper fra fagområdeproduktspesifikasjoner, som de som finnes tilgjengelige på Produktspesifikasjoner2. Men kravet er at de passer eksakt med det som ønsket uttrykt. Det vil først og fremst si at gjeldende kodeliste for aktuell egenskap kan brukes akkurat som den er. Å bruke en egenskap (definert pr navn og type) som er formelt definert i en spesifikasjon og så mekke egen kodeliste, er særdeles dårlig praksis. Dette vil føre til stor fare for misforståelser og feilbeslutninger der det dreier seg om et datasett som skal leve utenfor egen PC. Dessverre har en del nasjonale dataeiere agert slik i betydelig omfang og sluppet unna med det.

OBJTYPE er egenskapen som i størst grad definerer fenomenet som skal bli kartlagt. OBJTYPE for egne temadata bør ikke være eksakt lik en som allerede finnes i en produktspesifikasjon, men kan godt legge seg tett på en slik med tanke på ordvalg. Et annet, og av enkelte fagorgan oversett prinsipp, er at fenomener i samme temadatasett som er signifikant ulike skal gis ulike OBJTYPEr. Vi forbeholder oss retten til å kreve at temadata inneholder OBJTYPE-egenskap og -verdier når vi setter opp importløype for kommunale DOK-data.

Vi fraråder sterkt å bruke egenskaper som bæres av andre, flatedekkende datasett. Disse vil uansett kunne bli innhentet ved overlays for analyseformål eller forut for bruk til et spesifikt formål. Slik sikrer en seg mot at utdatert informasjon blir hengende i temadata og bruker GIS-metodikk på en hensiktsmessig måte.

Lange tekstegenskaper for å lagre avhandlinger om enkeltobjekter hører ikke hjemme i romlige data. Dette er stoff for linking til eksterne ressurser. Egenskaper som løpenumre utover det systeminterne som ikke peker på noen spesiell tilstand, arvede formatinterne egenskaper fra eventuelle kildefiler og egenskaper ved geometrien (lengde, areal) som uansett automatisk blir kalkulert av forvaltningsapplikasjonen, utelates.

Det anbefales at en-til-mange-forhold mellom objekt og egenskaper bare brukes der det er helt uunngåelig. Det kan være et alternativ å se kritisk på modellen en har valgt om bruk av objekt - egenskapsrelasjon ser uunngåelig ut.

Vi anbefaler filbasert geodatabase - FGDB, eller Geopackage, som forvaltningsformater for ArcGIS Pro. Webredigering på ArcGIS Online-ressurser er i rivende utvikling, og denne anbefalinga kan se annerledes ut på litt sikt. Lag/enkelttabeller som skal inngå i en leveranse MÅ avgrenses til temaet / scopet som er gitt for datasettet. Det er også ukurant å splitte et temadatasett på flere kilder (databasefoldere) eller å splitte dataelementer som er veldig tett assosiert og tenkes presentert samlet, dvs. i samme lag, på ulike tabeller. Der en velger å bruke overføringsdataformat (SOSI, GML) ved GeoNorge-tilrettelegging, forutsettes det at temadatasettet er representert ved ei og bare ei fil. Der dekningsdata til datasettet finnes, anbefaler vi at separat fil for dette blir generert.

Geodata forbeholder seg retten til å kreve at ukurant struktur, se eksempler over, rettes opp før vi importerer lokal DOK-data.

Kommunens egne temadata, innsynssystemet og Geodata

Lokal DOK

Der temadatasettet er valgt som lokalt DOK-datasett, vil Geodata hente inn dette og tilrettelegge det for de tre systemstøttede DOK-brukstilfellene:

DOK-analyse
DOK-karttjeneste
Uttrekk (kun unntaksvis - der kommunen eksplisitt ber om det)

Primær tilførselskanal for oss er GeoNorge. Når data er lagt ut til nedlasting, settes det opp nedlastingsløype, en konfigurasjon for DOK-brukstilfellene og en repetisjonshyppighet for kjøring av løypa. Sekundær tilførselskanal er døgnlig overkopiering av data, sammen med plandata men til annen folder ('Temadata') i datalageret for mottak. Merk at vi har en sterk preferanse for data på GeoNorge og for å kunne gjøre ting likt fra kommune til kommune. Aksepterte inn-formater er filbasert geodatabase - FGDB, Geopackage, GML og SOSI. De to første er bruksformater og krever dermed minst bearbeiding. Med tanke på endringer av datasett:

Større endringer av datasettet bør føre til oppretting av nytt datasett og valg av dette som lokalt DOK-datasett. Det gamle må da bli avvalgt. Mindre endringer av strukturen i samme datasett kan forekomme, men da må en varsle oss dersom det gir konsekvenser for kartografi eller egenskapssett for DOK-analyserapporten.
Geodata mottar varsel ved at vi overvåker kommunalt valgt DOK. Men det skader ikke å lage en forumpost der en introduserer og beskriver endringa.

Kommunal temadata som ikke er valgt DOK

Annen temadata skal, for kommunens bruk i Origo, AGOL-apper eller annen Esri programvare, lastes til kommunens AGOL. Dette blir primært utført av kommunen. Sekundært kan Geodata assistere i konvertering, utarbeiding av oppsett for - og opplasting til AGOL av lokal temadata på timebasis og etter avtale. Her er det større fleksibilitet med tanke på datakilder enn ved håndtering av DOK-data, på grunn av oppdragenes annerledesaktige karakter.

For at et kommunalt datasett skal kunne inngå i DOK-karttjenester eller -analyse, MÅ det bli valgt som lokal DOK.