GIS
system för data som har en plats på en karta
Vad det är
Ett GIS, förkortning för geografiskt informationssystem, är kombinationen av data, mjukvara och arbetsvanor som låter människor lagra, analysera och rita sådant som har en position på jorden. QGIS-projektets egen introduktion till ämnet är noga med att begreppet omfattar mer än ett program: den räknar upp digitala data och datorerna vid sidan av mjukvaran, och behandlar GIS som allt som har med att förvalta och använda geografiska data att göra. Området tog form på 1970-talet, på utrustning som bara universitet och stora företag hade råd med. I dag kör en laptop ett GIS för skrivbordet, och en telefon visar en webbkarta som bygger på samma idéer.
Varje GIS arbetar med två sorters data.
- Vektordata beskriver ett objekt som geometri: en punkt för en brunn, en linje för en väg, en polygon för en socken. Varje objekt bär en rad med attribut, så att en väg känner till sitt namn, sin beläggning och sin hastighetsgräns, och kartan kan färgläggas efter vilket som helst av dem.
- Rasterdata beskriver ett rutnät av celler där varje cell håller ett enda värde: färgen på en pixel i ett flygfoto, markens höjd i en höjdmodell, nederbörden under en månad. Zoomar man in tillräckligt syns cellerna som block.
Objekt av samma sort samlas i lager, och lagren staplas ovanpå varandra. Det är i den staplingen som det mesta av värdet uppstår. Vattendrag ovanpå fastigheter ovanpå en översvämningsmodell besvarar en fråga som inget av de tre lagren besvarar ensamt.
Det som får lagren att hamna rätt i förhållande till varandra är koordinatreferenssystemet. Varje lager har ett, och det talar om för mjukvaran hur talen hänger ihop med verkliga platser, oavsett om de är grader latitud och longitud eller meter österut och norrut från en nationell origo. Ett GIS för skrivbordet kan projicera om lager i farten, så att data som samlats in i olika system ritas i ett och samma, men det klarar det bara för ett lager vars system är korrekt angivet.
Kring de idéerna finns fyra sorters arbete: att samla in data genom inmätning, GPS, digitalisering eller laserskanning, att lagra dem i filer eller i en spatial databas, att analysera dem med operationer som buffertzoner, överlagring och interpolation, och att presentera dem som en tryckt karta, en webbkarta eller en rapport.
Varför det spelar roll
Det första användbara beslutet är om en fråga över huvud taget är spatial. Många data har en kolumn för plats utan att behöva ett GIS: att räkna beställningar per stad är en gruppering på ett textfält. En fråga blir spatial när svaret beror på var saker ligger i förhållande till varandra, så att svaret skulle ändras om en av dem flyttades. Vilka hushåll ligger inom översvämningens utbredning, vilka kunder har mer än en halvtimmes bilresa till varje depå, vilka sträckor av ett elnät försörjer flest nya anslutningar: sådana frågor kräver geometri, ett koordinatreferenssystem och operationer som förstår båda.
När en fråga väl är spatial blir nästa beslut hur mycket GIS som ska byggas, och det finns ungefär tre nivåer. En webbkarta som visar nålar och konturer från en fil behöver ett kartbibliotek och lite annat. En produkt som besvarar spatiala frågor åt sina användare behöver en spatial databas under sig, så att frågorna körs där data finns. En organisation som samlar in och förvaltar sina egna geografiska data, rättar dem, versionshanterar dem och publicerar dem för andra, behöver analytiker, verktyg för skrivbordet och skrivna regler för datakvalitet, eftersom data har blivit en tillgång i sig. Varje nivå kostar mer än den föregående, och varje nivå är bortkastad om frågan aldrig behövde den.
En karta avslöjar också problem i data som tabeller döljer. En kundadress som geokodats mitt i Nordsjön klarar varje kontroll i ett kalkylark och är uppenbar i samma stund som den ritas. Bara det gör det värt att snabbt titta på data på en karta innan man litar på någon spatial analys.
Så ser det ut i praktiken
Områdets bredd syns i mer än trettio skräddarsydda GIS-projekt som byggdes, driftsattes och sedan fick support i produktion. Deras stack motsvarar de delar av ett GIS som beskrivs ovan. PostgreSQL med PostGIS lagrade geodatan. GDAL/OGR flyttade den mellan format, bland dem shapefiler, GeoJSON, GeoTIFF, KML och vektortiles. QGIS och JOSM användes för själva dataarbetet, och webbkartor byggda på Mapbox GL och Leaflet presenterade resultatet. Arbetet spände från kartläggning i 2D och 3D via LiDAR-bearbetning, georeferering och vektorisering till inomhuskartläggning och navigering.
GIS kan också vara själva produkten snarare än verktygen bakom den. En SaaS-plattform för att följa anläggningar för förnybar energi, som solpaneler och vindkraftverk, saknade den geospatiala del som kunderna behövde för att se var anläggningarna stod och hur de presterade. En kartapplikation för GIS byggdes in i plattformen på en modulär arkitektur med GIS-bibliotek med öppen källkod, vald för att hålla systemet lätt nog för ett litet team att driva. Den växte från en enkel prototyp till en hörnsten i plattformen, med analys och anpassade dashboards, och låg bakom att intäkterna blev 10 gånger högre genom merförsäljning, datalicensiering och nya kunder.
Var det går fel
Lager som borde överlappa ligger isär. Vägar från en leverantör löper bredvid fastigheterna från
en annan i stället för längs deras kanter, eller så hamnar ett helt lager i fel del av världen.
Orsaken är nästan alltid ett koordinatreferenssystem som saknas eller är fel: en shapefil som
levererats utan sin .prj-fil, ett kalkylark med koordinater utan ett ord om vad de betyder, eller
data i ett datum som märkts som ett annat. Omprojicering i farten kan bara flytta ett lager vars
system den känner till. Rätta det vid importen: registrera uttryckligen systemet för varje
inkommande lager, projicera om allt till ett och samma arbetssystem för analysen och kontrollera
resultatet mot en punkt vars position på marken är känd.
Uppmätta ytor stämmer inte med fastighetsregistret. En åker eller en tomt som mäts på kartan blir större än sin officiella siffra, och skillnaden växer med avståndet från ekvatorn. Mätningen gjordes i den projektion som används för visning. Webbkartor använder ofta en variant av Mercator, som bevarar vinklar och former lokalt och betalar för det med förvrängda ytor. Mät i en ytriktig projektion eller i det nationella koordinatsystem som är gjort för regionen, eller låt en spatial databas räkna ut ytan på ellipsoiden.
Angränsande polygoner lämnar glipor och överlapp. Kommungränser, leveranszoner eller åkrar som digitaliserats en i taget möts inte riktigt: tunna springor öppnar sig mellan dem, eller så gör två zoner anspråk på samma remsa. Linjer som borde mötas slutar för tidigt eller löper förbi varandra, vilket QGIS kallar undershoots och overshoots, och en ruttsökning behandlar då vägnätet som avbrutet på just det stället. Objekten samlades in var för sig utan topologiregler. Digitalisera med fästning mot befintliga brytpunkter, kör en topologikontroll som flaggar glipor och överlapp, och håll varje gemensam gräns som en enda delad linje.
Attributnamn kommer fram avkortade. Ett lager som exporterats som shapefil kommer tillbaka med
population_density omdöpt till population och en andra kolumn omdöpt till populati_1. Formatet
lagrar attributen i en dBASE-fil, som begränsar ett fältnamn till 10 tecken och bara har stöd för
heltal, decimaltal, strängar och datum, så klockslag och listor går också förlorade. Utväxla data
som GeoPackage, en OGC-standard som lagrar lager och attribut i en enda SQLite-fil, och använd
shapefiler bara för de verktyg som inte tar emot något annat.
Läs mer
- A Gentle Introduction to GIS — QGIS-projektets fria kurs, från vektor- och rasterdata till kartframställning och spatial analys.
- Coordinate Reference Systems — kapitlet om projektionsfamiljer, vad var och en bevarar och omprojicering i farten.
- Topology — glipor, överlapp, undershoots, overshoots och det fästavstånd som förhindrar dem.
- Shapefile driver — GDAL:s anteckningar om formatets gränser för fältnamn, datatyper och storlek.
- GeoPackage — OGC-kodningen som bär vektorlager, rasterplattor och attribut i en enda SQLite-fil.