# GIS ## Hva det er Et GIS, kort for geografisk informasjonssystem, er kombinasjonen av data, programvare og arbeidsvaner som lar folk lagre, analysere og tegne ting som har en posisjon på jorden. QGIS-prosjektets egen innføring i faget passer på å si at begrepet dekker mer enn et program: den lister opp de digitale dataene og datamaskinene ved siden av programvaren, og behandler GIS som alt som inngår i å forvalte og bruke geografiske data. Fagfeltet tok form på 1970-tallet, på utstyr som bare universiteter og store selskaper hadde råd til. I dag kjører en bærbar maskin et GIS for skrivebordet, og en telefon viser et webkart bygd på de samme ideene. Alle GIS arbeider med to slags data. - **Vektordata** lagrer et objekt som geometri: et punkt for en brønn, en linje for en vei, et polygon for et sogn. Hvert objekt har en rad med attributter, så en vei vet hva den heter, hvilket dekke den har og hva fartsgrensen er, og kartet kan fargelegges etter hvilken som helst av dem. - **Rasterdata** lagrer et rutenett av celler som hver har én verdi: fargen på en piksel i et flyfoto, høyden på bakken i en terrengmodell, nedbøren over en måned. Zoomer du langt nok inn, viser cellene seg som klosser. Objekter av samme slag samles i lag, og lagene stables oppå hverandre. Det er i den stablingen det meste av verdien ligger. Elver over eiendomsgrenser over en flommodell besvarer et spørsmål som ingen av de tre besvarer alene. Det som får lagene til å ligge riktig over hverandre, er koordinatreferansesystemet. Hvert lag har ett, og det forteller programvaren hvordan tallene henger sammen med virkelige steder, enten de er grader bredde og lengde eller meter øst og nord for et nasjonalt nullpunkt. Et GIS for skrivebordet kan projisere lag om i farten, slik at data fanget i ulike systemer tegnes i ett, men det får det bare til for et lag der systemet er riktig oppgitt. Rundt disse ideene ligger fire slags arbeid: å fange inn data ved oppmåling, GPS, digitalisering eller laserskanning; å lagre dem i filer eller i en romlig database; å analysere dem med operasjoner som buffersoner, overlagring og interpolasjon; og å presentere dem som et trykt kart, et webkart eller en rapport. ## Hvorfor det er viktig Den første nyttige beslutningen er om et spørsmål i det hele tatt er romlig. Mange data har en kolonne med sted uten å trenge et GIS: å telle bestillinger per by er en gruppering på et tekstfelt. Et spørsmål blir romlig når svaret avhenger av hvor ting ligger i forhold til hverandre, slik at svaret ville endret seg om du flyttet en av dem. Hvilke husstander ligger innenfor flomsonen, hvilke kunder har mer enn en halvtimes kjøring til nærmeste lager, hvilke strekninger av et strømnett betjener flest nye tilkoblinger: slike spørsmål trenger geometri, et koordinatreferansesystem og operasjoner som forstår begge deler. Når et spørsmål først er romlig, blir neste beslutning hvor mye GIS som skal bygges, og det finnes omtrent tre nivåer. Et webkart som viser nåler og omriss fra en fil, trenger et kartbibliotek og lite annet. Et produkt som besvarer romlige spørsmål for brukerne sine, trenger en romlig database under seg, slik at spørsmålene kjøres der dataene ligger. En virksomhet som fanger inn og vedlikeholder sine egne geografiske data, retter dem, versjonerer dem og publiserer dem til andre, trenger analytikere, verktøy for skrivebordet og nedskrevne regler for datakvalitet, fordi dataene har blitt en verdi i seg selv. Hvert nivå koster mer enn det forrige, og hvert av dem er bortkastet hvis spørsmålet aldri trengte det. Et kart avslører dessuten problemer i dataene som tabeller skjuler. En kundeadresse som er geokodet midt ut i Nordsjøen, består hver kontroll i et regneark og er åpenbar i det øyeblikket den tegnes. Bare det gjør det verdt å ta en rask titt på dataene på et kart før noen romlig analyse får tillit. ## Slik ser det ut i praksis Bredden i fagfeltet viser seg på tvers av [mer enn tretti skreddersydde GIS-prosjekter](/nb/portfolio/led-the-development-deployment-and-support-of-over-35/) som ble bygget, satt i produksjon og deretter fulgt opp i drift. Stakken deres svarer til delene av et GIS som er beskrevet ovenfor. PostgreSQL med PostGIS lagret de romlige dataene. GDAL/OGR flyttet dem mellom formater, blant dem shapefiler, GeoJSON, GeoTIFF, KML og vektorfliser. QGIS og JOSM tok seg av selve dataarbeidet, og webkart bygget på Mapbox GL og Leaflet presenterte resultatet. Arbeidet spente fra kartlegging i 2D og 3D via LiDAR-behandling, georektifisering og vektorisering til innendørs kartlegging og navigasjon. GIS kan også være selve produktet og ikke bare verktøyet bak det. En SaaS-plattform for å følge med på fornybare energianlegg som solcellepaneler og vindturbiner manglet den geospatiale delen kundene trengte for å se hvor anleggene sto og hvordan de presterte. [En GIS-kartapplikasjon ble bygd inn i plattformen](/nb/portfolio/led-the-software-development-of-a-gis-map-24/) på en modulær arkitektur av GIS-biblioteker med åpen kildekode, valgt for å holde systemet lett nok til at et lite team kunne drive det. Den vokste fra en enkel prototyp til en hjørnestein i plattformen, med analyser og egne dashbord, og ga 10 ganger høyere inntekter gjennom mersalg, datalisensiering og nye kunder. ## Hvor det går galt **Lag som skal ligge oppå hverandre, havner ved siden av hverandre.** Veier fra én leverandør går ved siden av eiendommene fra en annen i stedet for langs kantene deres, eller et helt lag dukker opp i feil del av verden. Årsaken er nesten alltid et koordinatreferansesystem som mangler eller er feil: en shapefil levert uten `.prj`-filen sin, et regneark med koordinater uten et ord om hva de betyr, eller data på ett datum merket som et annet. Omprojisering i farten kan bare flytte et lag der den kjenner systemet. Rett det ved import: registrer systemet for hvert innkommende lag eksplisitt, projiser alt om til ett arbeidssystem for analysen, og sjekk resultatet mot et punkt med kjent posisjon i terrenget. **Målte arealer stemmer ikke med matrikkelen.** Et jorde eller en byggetomt målt på kartet blir større enn det offisielle tallet, og avviket vokser med avstanden fra ekvator. Målingen ble gjort i projeksjonen som brukes til visning. Webkart bruker ofte en variant av Mercator, som holder vinkler og former riktige lokalt og betaler for det ved å forvrenge arealet. Mål i en arealriktig projeksjon eller i det nasjonale rutenettet som er laget for området, eller la en romlig database regne ut arealet på ellipsoiden. **Nabopolygoner etterlater glipper og overlapp.** Kommunegrenser, leveringssoner eller jorder digitalisert ett om gangen møtes ikke helt: tynne sprekker åpner seg mellom dem, eller to soner gjør krav på den samme stripen. Linjer som skulle møtes, stopper for tidlig eller går forbi hverandre, noe QGIS kaller «undershoots» og «overshoots», og et rutesøk behandler da veinettet som brutt på det stedet. Objektene ble fanget inn hver for seg uten topologiregler. Digitaliser med festing til eksisterende hjørnepunkter, kjør en topologisjekk som flagger glipper og overlapp, og hold hver felles grense som én delt linje. **Attributtnavn kommer fram avkortet.** Et lag eksportert som shapefil kommer tilbake med `population_density` omdøpt til `population` og en annen kolonne omdøpt til `populati_1`. Formatet holder attributtene i en dBASE-fil, som begrenser et feltnavn til 10 tegn og bare støtter heltall, desimaltall, strenger og datoer, så klokkeslett og lister går også tapt. Utveksle data som GeoPackage, en OGC-standard som lagrer lag og attributter i én SQLite-fil, og bruk shapefiler bare for verktøy som ikke godtar noe annet. ## Les mer - [A Gentle Introduction to GIS](https://docs.qgis.org/latest/en/docs/gentle_gis_introduction/) — QGIS-prosjektets gratis kurs, fra vektor- og rasterdata til kartproduksjon og romlig analyse. - [Coordinate Reference Systems](https://docs.qgis.org/latest/en/docs/gentle_gis_introduction/coordinate_reference_systems.html) — kapittelet om projeksjonsfamilier, hva hver av dem bevarer, og omprojisering i farten. - [Topology](https://docs.qgis.org/latest/en/docs/gentle_gis_introduction/topology.html) — glipper, overlapp, «undershoots», «overshoots» og festeavstanden som hindrer dem. - [Shapefile driver](https://gdal.org/en/stable/drivers/vector/shapefile.html) — GDALs merknader om formatets grenser for feltnavn, typer og størrelse. - [GeoPackage](https://www.geopackage.org/) — OGC-kodingen som bærer vektorlag, fliser og attributter i én SQLite-fil.