Vi lever i osäkra tider igen har vi blivit påminda om. Om världen hade fogar så skulle de förmodligen knaka – om man lyssnade noga. Det är inte helt enkelt att veta säkert vilka av ens gamla vänner som fortfarande är vänner. En hel del gamla sanningar behöver utvärderas på nytt.
I Europa har dessa insikter om vikten av digital suveränitet medfört ett ökat intresse för till grön teknologi, prospektering av europeiska mineraler och preferens för europeiska digitala teknologier som bygger på öppen källkod och öppna standarder.
Både programvaror som bygger på öppen källkod och öppna standarder i sig spelar en viktig roll i digital suveränitet. Att överväga europeiska leverantörer och migrering till system som bygger på öppen källkod är ett steg som stöttar många av de strategiska beslut som redan fattats i många organisationer. Eftersom man kan välja leverantörer helt fritt från hela världen, minskar risken för vendor-lock effekter. Öppen källkod kan när som helst granskas av oberoende sakkunniga för att koden är öppen och tillgänglig för användare av koden till skillnad från en proprietär kod. Därmed kan man försäkra sig om att det inte finns gömda funktioner eller “bakdörrar” som skulle kunna ge tillgång till obehöriga att komma åt kritisk information eller personuppgifter.
Om din organisation inte än har fattat beslut om att börja överväga användning av programvaror som bygger på öppen källkod, är tiden nu definitivt mogen för det. I detta blogginlägg lyfter jag fram några frågor som kan hjälpa till under tankeprocessen.
Migration till system som bygger på öppen källkod
Faktum är att migration från ett befintligt system till ett nytt system kommer alltid att ta tid. Flytt tar alltid tid och kräver under en tid mer resurser jämfört med att “fortsätta som hittills ett tag till”. Man behöver ha is i magen, sammanställa genomtänkta argument och ta fram en tydlig plan innan man börjar med själva migrationen. Man måste ser sanningen i vitögat: den nya teknologin har möjligheter och begränsningar, data behöver flyttas från A till B, personalen behöver utbildas för att bara nämna några aspekter som man måste ta itu med innan man kavlar upp ärmarna och inleder själva migreringen.
Ganska länge var de viktigaste argumenten för öppen källkod framför allt ekonomiska och teknologiska. Man skulle slippa betala licensavgifter och man fick tillgång till verktyg och funktioner som inte fanns i traditionella programvaror som bygger på proprietär källkod. Ibland spelade besvikelsen på programleverantörens löften om tilläggs- och supporttjänsternas omfattning en viss roll.
Men nuförtiden väger ett annat argument tungt vid val mellan öppen och proprietär kod: behovet att ha makt över egna data idag och viljan att behålla sin handlingsfrihet även i morgon.
Vi pratar då om sk. “push- och pull”- faktorer som man inom varje organisation behöver väga mot varandra. Vilka fördelar och nackdelar finns i nuvarande system, hur ser de långsiktiga ekonomiska aspekterna ut och hur krävande skulle en migration bli? Innan man kan fatta ett grundat beslut måste dessa aspekter behöver vägas in.
Idag känner vi till att amerikanska myndigheter både kan och också begär ut data som lagrats på amerikanska servrar i molnet även om servrarna ligger utomlands, t ex inom EU med stöd av CLOUD Act (Clarifying Lawful Overseas Use of Data, 2018). Lagen kom ursprungligen till pga en tvist mellan amerikanska myndigheter och Microsoft som lagrade data på servrar på Irland.
Nu har vi redan konkreta exempel på hur data används i underrättelseverksamhet med stöd av CLOUD Act. I mars 2026 fick vi veta att användning av Google translate kan leda till tragikomiska följder för agenter hos främmande makt. Mindre komiskt är fallet med de elva domare och åklagare på ICC (International Criminal Court i Haag) som sanktioneras av den amerikanska administrationen 2025 pga sitt yrkesutövande. Därefter stängdes de sanktionerade personerna av bl a från alla amerikanska molntjänsterna. De berörda tjänstemännen har offentligt berättat hur livet plötsligt blev betydligt mer krångligt bl a pga stängda betalkort och bank- och epostkonton samt alla följdeffekter.
Medan man reflekterar över allt detta kan det vara bra att börja fundera på alternativ och migrering av sina egna data i tid, inte först när man är illa tvungen. Särskilt viktigt är det för organisationer som förvaltar kritiskt viktig information, personuppgifter eller annars vill inte ge obehöriga tillgång till egna data. Migreringen kommer att kosta och ta tid men är det värt besväret om man själv kan välja tidpunkten och behålla sin handlingsfrihet?
Tankar om digital suveränitet har funnits länge i Open Source GIS-kretsar och vi har kommit en bra bit på vägen redan. De största utvecklarna av open source GIS/FOSS4G (Free and Open Source Software för Geospatial) är ju redan europeiska företag. Använder man t ex QGIS, brukar man installera programmet direkt på egen dator och då behövs ingen serverinstallation. PostGIS och GeoServer däremot behöver installeras på en server. På serversidan finns numera en växande skara europeiska tjänsteleverantörer att välja mellan, t ex UpCloud, ett finskt företag som har datacenters Stockholm, Helsingfors, Köpenhamn och Stavanger som vi på Gispo har börjat testa i skarpt läge. Hur enkel eller krånglig kommer migrering från t ex Azure eller Amazon Web Services till UpCloud att bli? Det beror helt på hur automatiserad den nuvarande molntjänsten är. Alla verktyg kommer inte att finnas direkt tillgängliga utan man behöver byta ut eller bygga upp dem från scratch.
Både i Sverige och Finland diskuterar man flitigt myndigheternas vägval i frågan om molntjänster i olika medier. Förvaltningsmyndigheter är fristående från regeringen i båda länderna och därmed självständiga när det gäller enskilda beslut. Därför är det inte konstigt att olika myndigheter har valt olika tillvägagångssätt i frågan. Skattemyndigheten i Sverige fattade beslutet om att börja använda Azure, Microsoft 365 och Teams i sin verksamhet 2025 efter att länge haft en annan inställning. Många andra myndigheter har resonerat i liknande banor medan t ex Försäkringskassan har varit mycket restriktiv.
I Finland har både Valmyndigheten som under lyder under Justitiedepartementet och den finländska motsvarighet till Försäkringskassan, KELA/FPA (Folkpensionsanstalten) fått mycket kritik för sina beslut om att börja använda molntjänster som bygger på Microsoft Azure eller Amazon Web Services i sina verksamheter under 2026.
Generellt kan man säga att digital suveränitet seglat upp på agendan hos myndigheterna under det senaste året i båda länderna. Förutom hantering av personuppgifter tittar man också på geodata som spelar en mycket viktig roll vid förvaltning av kritisk infrastruktur. Många organisationer inom offentlig förvaltning använder sig av sk offentliga molntjänster (public cloud services). Missförstånd uppstår lätt här: dessa molntjänster är inte riktade mot “offentlig sektor” utan tjänsterna är “publika” dvs till för alla. Motsatsen till offentliga molntjänster är alltså privata molntjänster.
Den viktigaste utmaningen och vidare de största riskerna med offentliga molntjänster är kopplade till geopolitik och icke-europeisk lagstiftning. De mest kända offentliga molntjänsterna erbjuds av stora amerikanska företag som lyder under amerikansk lagstiftning (CLOUD Act mm). I dag vet vi att med stöd av den lagstiftningen kan europeiska data hamna hos amerikanska myndigheter även när servrarna geografiskt ligger inom Europa. Därmed kan det vara klokt att se över t ex installationen av PostGIS och GeoServer. Vill man minska riskerna, sätter man upp dem så att en flytt mellan olika europeiska molntjänstplattformar (multi-cloud strategy) är möjlig vid behov. Ett annat alternativ är naturligtvis att systemen sätts upp på organisationens egen server (“on-premise”). Man kan göra en hel del redan idag. Men vågar man hoppas på nya riktlinjer, bl a gällande offentlig upphandling för att uppnå digital suveränitet?
Vad kan man göra rent praktiskt?
Ett konkret sätt är att stötta och bidra till utveckling av europeiska programvaror. För oss som arbetar med GIS innebär det stöd till kritiskt viktiga programvaror som QGIS, PostGIS och GeoServer. Hur då? T ex genom att bli medlem – som en individ eller organisation – i en intresseförening som med hjälp av medlemsavgifterna stöttar den fortsatta utvecklingen av öppen källkod och open source GIS. Då kommer de europeiska behoven och EU-lagstiftningen beaktas och prioriteras vid utvecklingsarbetet och beroendet av icke-europeiska finansiärer.
Fina exempel på sådan föreningar har vi redan både i Sverige och Finland. QGIS Sverige användarförening och COSS förening i Finland är båda sk Flagship members i QGIS organisation och bidrar till fortsatt utveckling av QGIS. Båda organisationer räknar bland sina betalande medlemmar statliga myndigheter, t ex Lantmäteriet i Sverige och Lantmäteriverket i Finland.
När det gäller digital suveränitet och handlingsfrihet måste man konstatera att vi sitter faktiskt alla i samma båt. Vi är inte framme utan paddlar alla, på olika sätt. Även vi på Gispo använder fortfarande Googles verktyg och Amazon Web Services i vår egen verksamhet. Vi kan inte ta till brösttoner och påstå att vi redan löst allt och blivit digitalt suveräna. Men vi jobbar på det. Vi tar små steg åt det hållet. Helt konkret betyder det att vi i fortsättningen kommer att alltid i första hand rekommendera europeiska lösningar till våra kunder och leta aktivt efter nya alternativ med ökad digital suveränitet i siktet.
Vad ska man göra nu?
- Håll utkik och välj programvaror som bygger på öppen källkod alltid när det är möjligt.
- Utbilda dig för egen kompetensutveckling är en viktig del av digital suveränitet.
- Gå genom organisationens geodata och fundera på om det finns kritiskt viktiga data som idag finns på en s.k. offentlig molntjänst.
- Fundera på om det skulle kräva att migrera till europeiskt eller svenskt alternativ.
- Gör en road map/handlingsplan om migration: vad behövs, vad det kostar, när det kan göras.
- Behöver du hjälp, prata med vänner och specialister.
Ps. Medan jag skrev detta blogginlägg tog jag hjälp av AI, närmare sagt Gemini. Och då märkte jag än en gång att AI är både ett hjälpmedel och en del av problemet. Gemini hallucinerade en hel del men hittade också några av de länkarna till kända fall som jag hänvisar till i texten. Gemini föreslog också att fortsatt utbildning är en viktig komponent i förändringsprocessen och ökad finansiering till FOSS4G-programvaror förstärker digital suveränitet. Kanske hade jag kommit på det själv också efter att ha sovit på blogginläggets första utkast. Men nu kunde AI-partnern sparra mig redan idag.
Mitt i dagens AI-hype är det lätt glömma att maskininlärning har använts inom många branscher i årtionden. Ett typiskt exempel är tolkning av satellitbilder. Marktäckedata har under lång tid producerats med metoder motsvarande maskininlärning med satellitbilder som underlag. Tack vare AI får detta klassiska användningsområde hjälp på traven i fortsättningen..
Företaget DeepMind, som ägs av Google och arbetar med AI och djupinlärning, publicerade ett nytt dataset, Google Satellite Embedding Version 1 i slutet av juli 2025. Data har producerats av Googles AI-modell AlphaEarth Foundation och innehåller information som förädlats utifrån en enorm mängd data från optiska satelliter (Landsat, Sentinel), radarsatelliter och lidarmätningar och kombinerats med data från klimat-, gravitations- och höjdmodeller.
När den finska myndigheten Forststyrelsen (Metsähallitus), med kombinerad roll som både ett statligt affärsverk och myndighet, berättade via sitt dotterbolag Skogsbruk AB om behoven att automatiskt identifiera renlavar i Norra Finlands renskötselområden, visste vi genast att detta pilotprojekt skulle kunna ge en mycket intressant möjlighet att studera Googles data och dess tillämpningsområden.
Traditionellt har man identifierat områden med lavar genom manuell tolkning från s.k. felfärgsbilder, (false color image) som visar framför allt kortvågig infraröd elektromagnetisk strålning reflekterad av vegetationen. Processen är arbetsintensiv och kräver specialistkunskaper. Eftersom renskötselområdena är stora, kan befintliga klassiska ortofoton som underlag vara problematiska vid maskininlärning. Varför? Jo, därför att olika områden har fotograferats vid olika tidpunkter och med olika typer av instrument. Innan data kan användas som underlag vid träning av AI, behöver man processa data för att nå tillräckligt jämn kvalitet. Fördelen med data från Google Satellite Embedding är just dess globala enhetlighet och då kan man direkt utnyttja data som underlag vid träning av AI:t.
Google Satellite Embedding V1: ett nytt datasätt, färdigt underlag för analyser
Som vi konstaterade redan innan, består Google Satellite Embedding version 1 av en enorm mängd av befintliga mät-, modell- och bilddata som använts vid träning av AI-modellen AlphaEarth.
Data täcker hela jordklotet och dess spatiala resolution är 10 m. Värdet av varje pixel är ett komprimerat värde av alla indata inklusive tidsaspekten. Data har samlats in 2017-2024. Varje 10 m * 10 m pixel är kopplad till en vektor med 64-komponenter i inbäddningsrymd (embedding space). Man kan till viss mån få nytta av en förenklad analogi genom att föreställa sig en “virtuell” satellitbild som har 64 kanaler. Men analogin räcker inte hela vägen för att förklara hur vektorer och deras enskilda komponenter ska tolkas. Mer matematiskt uttryckt pratar vi alltså om att varje pixel är kopplad till en vektor som har längd och riktning i en rymd med 64 dimensioner.
För att underlätta bearbetning av data, har varje vektor fått en normaliserad längd på exakt en (1) enhet. Detta är nyttigt med tanke på kommande beräkningar för det innebär att vektorer bildar en enhetssfär (unit sphere) i en rymd med 64 dimensioner med radie av en (1) enhet. På motsvarande sätt skulle vektorer med längd av en (1) mätenhet som pekar i olika riktningar bilda en sfär i en 3-dimensionell verklighet.
Man kan, återigen, använda analogin med tredimensionell jordklot för att förstå begreppet ‘similaritet’. Man kan ta två olika pixlar på jordklotets yta med var sin vektor som beskriver en viss egenskap med sin riktning. Om två vektorer, kopplade till två olika pixlar, är väldigt “lika” dvs att de pekar i nästan samma riktning (=vinkeln mellan vektorerna är liten), betyder det att även själva pixlarna liknar varandra på något sätt, dvs de är lika eller “similar”. Utöver detta innehåller varje vektor också information om pixelns omgivning i en större kontext, i detta fall inom ett område på ca 1,28 km * 1,28 km.
Allt detta med en vektor med 64 dimensioner kan låta ganska abstrakt och komplicerat i början. Men om man reflekterar över den enorma mängden indata som nu finns samlats, kodats och sparats i detta dataset så börjar man så småningom förstå och uppskatta systematiken bakom arbetet. There is method in this madness, skulle gamle gode Polonius i Hamlet säkert säga.
Den bärande idén bakom Google Satellite Embedding V1 har varit att sammanställa komplexa globala indata så att resultatet blir ett enhetligt och färdigt paket som kan användas i olika typer av analyser. Då blir det möjligt att upptäcka både lokala och globala sammanhang och fenomen på ett sätt som inte tidigare skulle varit möjligt utifrån enstaka dataset och satellitbilder.
Google Satellite Embedding V1 är licensierat med CC-BY 4.0-licens och därför får man bearbeta det och distribuera resultaten om man anger källan. Man kommer åt data enkelt t ex via Google Earth Engine men man kan också ladda ned data och bearbeta det med hjälp av andra verktyg, t ex med OpenGeoAI-bibliotek.
Klassificering av renlavar: similaritetsanalys och maskininlärning i praktiken
Ett område i norra Finland, ca 40 000 ha, valdes som testområde i detta pilotprojekt åt Forststyrelsen. Det fanns tillgängliga ett antal ortofoton med färdigt tolkade områden som hade klassificeras i tre olika klasser: områden med stor sannolikhet för förekomst av renlavar, områden men viss sannolikhet för förekomst av renlavar och sist områden där förekomsten av renlavar bedömdes vara mycket osannolik. Dessa data användes sedan som träningsdata i analyserna. Programkoden skrevs för Google Earth Engine för att kunna köra olika typer av analyser, framför allt similaritetsanalyser och övervakade maskininlärningsalgoritmer (supervised machine learning algoritm).

Som vi konstaterade redan tidigare, är data lagrade och strukturerade så att varje pixel är kopplad till en vektor med 64 dimensioner. Genom att jämföra två olika vektorer med varandra, dvs hur stor vinkeln mellan vektorerna är, kan man sedan bedöma hur lika eller olika pixlarna är i ett visst avseende. Ju mindre vinkeln mellan vektorerna, desto mer lika är områden i pixlarna. Matematiskt pratar vi då om skalärprodukt (ibland även prickprodukt) i linjär algebra. Skalärprodukten är produkten av vektorernas längder multiplicerat med cosinus för vinkeln mellan dem. Beräkningen underlättades av faktumet att vektorerna längd har skalats till en (1) enhet.
Processen vad stegvis. Först valde valde ut bara de pixlar ut träningsdata som bedömdes med stor sannolikhet innehålla områden med renlavar. Med pixlarna kom också de vektorer som var kopplade till dessa pixlar. Vid nästa steg jämförde vi alla pixlar inom testområdet och deras vektorer till de utvalda pixlar och deras vektorer. Om skalärprodukten av två vektorer var över ett visst valt tröskelvärde nära siffran ett (Cosinus för 0 = 1 dvs om vektorer är likriktade), tolkade vi att pixeln innehöll renlav. Detta är similaritetsanalys i nötskal. Det är värt att notera att algoritmen inte behövde tränas utan analysdelen bestod av själva beräkningen av skalärprodukten.

Under övervakad maskininlärning behövde man knappt på förhand förbereda Satellite Embedding data. Själva bearbetningen var rätt så okomplicerat och vid klassificering använde vi KNN-klassificerare (K Nearest Neighbour) med olika K-värden. I praktiken små K-värden fungerade utmärkt och även med alla K-värden kunde vi oftast uppnå minst 90% noggrannhet.
Slutresultat och vad lärde vi oss: hur säkert hittade vi renlavområden?
För att kunna köra analyserna skrevs kod med hjälp av en kodeditor och programmeringsgränssnitt som finns i Google Earth Engine. Miljön är avsedd för analyser i en global skala och tack vare hög beräkningsprestanda kunde vi snabbt få resultat inom stora områden.
Vi bedömde resultaten och deras noggrannhet på två olika sätt: först numeriskt genom att använda en del av träningsdata i validering och sedan med hjälp av en sakkunnig specialist som granskade satellitbilderna efteråt och gjorde sin egen oberoende tolkning. Projektarbetet genomfördes under vintern och det var inte möjligt att kalibrera resultaten med hjälp av fältobservationer pga snötäcket. Detta skulle också varit mycket arbetsintensivt med tanke på att analysområdet var stort. Vi kunde ändå konstatera att resultaten från både similaritetsanalysen och övervakad maskininlärning pekade åt samma håll även om den mänskliga specialisten med sitt tränade öga hittade områden som ytterligare behöver analyseras. För att kunna få bra resultat ur Satellite Embedding-data behöver man välja noga sina träningsdata. Fältbesöken under den snöfria perioden kommer att vara till stor hjälp när beräkningsmodellen kalibreras och vidare förbättras i fortsättningen.
Allt som allt tycker vi att pilotprojektet var mycket lyckat. Vi fick en bra uppfattning om hur nya dataset som Google Satellite Embedding-data och ett öppet sinne kan bidra till nya lösningar inom klassiska forskningsområden.
Ett spatial tillägg för PostgreSQL. Blogginlägg slut.
Sakta i backarna! Man kan kanske svara på frågan i rubriken med en mening, men ifall man inte redan är invigd så väcker svaret bara fler frågor.
En sak i taget. Vi måste först reda ut begreppet databas.
En databas är en samling av organiserad information. Tidigare organiserade man information fysiskt i mappar med papper, kartotek, lertavlor och annat som mina barn aldrig hört talas om. Idag föredrar vi oftast digitala organiserade samlingar av information. Det är det vi kallar en databas i detta sammanhang.
Det finns olika system att organisera sina databaser, det är egentligen detta vi hänvisar till när vi talar om till exempel PostgreSQL, Oracle eller MySQL. Vi brukar kalla dem relationsdatabaser men det långa och krångliga namnet på dem är Relational Database Management Systems eller RDBMS. Som ni ser så är det alltså “system för att hantera relationsdatabaser”. Men vad då relationsdatabas? Vad har en databas för relationer? Nej, som du säkert redan gissat så är det inte kärleksrelationer, utan något aningen mindre spännande.

En relationsdatabas innehåller tabeller. Det är mellan dessa tabeller vi hittar relationer. Jag sa ju att det inte var så spännande…
Men lägg undan kärleksbekymren en stund. Om vi tänker oss att vi har en tabell med kärleksromaner och en tabell med författare. Då skulle vi upprätta en relation mellan romanerna och författarna. En författare kan skriva flera böcker, så det kan finnas en one-to-many relation. Men nu ska vi inte snacka relationer. Vi ska snacka PostGIS.
Okej så nu vet vi vad en relationsdatabas är. Ett populärt “relationsdatabassystem” är PostgreSQL.

PostgreSQL, som ofta kallas bara postgres för att inte vricka allas tungor, är byggt på öppen källkod och fyller faktiskt 30 år i år (2026)! Det är alltså en etablerad spelare på databasmarknaden. PostgreSQL är fortsättningsvis en av de mest populära relationsdatabassystemen i världen. Här på Gispo gillar vi också PostgreSQL, framför allt för att det är öppen källkod och för att PostgreSQL har ett spatialt tillägg som heter PostGIS.
Nu har vi alltså nästan kommit fram till svaret. PostGIS är alltså ett tillägg som man installerar på sin PostgreSQL-databas. Utan PostGIS är PostgreSQL ganska handfallen när det gäller geografiska data. PostGIS möjliggör smidig hantering och analysering av stora mängder geodata. Du får tillgång till bland annat spatiala format och spatiala analyser för geodata. Ifall du blev intresserad så kanske du borde delta på Gispos PostGIS-kurs?
Bonusfråga: Vem behöver PostGIS?
Organisationer som vill ha ordning och reda på geodata och som inte vill betala licenskostnader för sin geodatabas.
Vi älskar öppna (geo)data. Men det tar sin lilla tid att leta runt efter öppna geodatatjänster och hitta rätt på www.geodata.se/geodataportalen, Digital Earth Sweden och hos olika myndigheter.
Under åren som gått har vi samlat länkar till olika typer av öppna geodatatjänster och uppdaterat länksamlingen i omgångar- och bevarat listan i den digitala skrivbordslådan. Men varför fortsätta ruva på den? Alla ska inte behöva uppfinna samma hjul på nytt. Vi vill dela den med dig!
För enkelhetens skull har vi valt att enbart ta med rikstäckande geodatatjänster och länkar till visningsportaler hos följande myndigheter:
- Boverket
- Havs- och vattenmyndighet (HAV)
- Jordbruksverket
- Lantmäteriet
- Länsstyrelserna
- Myndigheten för civilt försvar (tidigare MSB)
- Naturvårdsverket
- Riksantikvarieämbetet (RAÄ)
- Sjöfarsverket
- Skogsstyrelsen
- Sveriget hydrologiska och meteorologiska institut (SMHI)
- Statens geotekniska institut (SGI)
- Statens geologiska undersökning (SGU)
- Statistikmyndigheten (SCB)
- Svenska kraftnät (SvK)
- Trafikverket
- Vattenmyndigheterna
Listan är givetvis inte komplett och vi garanterar inte att allt funkar. Vi går igenom listan med jämna mellanrum och uppdaterar den vid behov, men det kan alltid slinka in fel. Om du ser att det saknas någon tjänst vi borde ha med, eller att någon inte fungerar så hör av dig till info@gispo.se!
Förutom öppna geodata älskar vi också QGIS och open source GIS. Det är ju i högsta grad hönan och ägget som det handlar om här. I sann open source-anda vill vi därför också passa på och dela med oss av ett par QGIS-tips.
Tips 1/3:
I QGIS är det enkelt att ta kontakt med alla dessa öppna geodatatjänster. Se till att välja rätt anslutningstyp, då funkar kopplingarna bättre 🙂 Här följer en snabbkoll över de olika tjänsterna.
| Förkortning | Namn | Förklaring | Öppen standard? | QGIS Data Source Manager |
WMS | Web Map Service | Visningstjänst för kartbild | Ja |
|
WFS | Web Feature Service | Nedladdnings-tjänst för geodata | Ja | |
OGC API Features | Open GeoSpatial Consortium Application Programming Interface Features | En nyare öppen standard för nedladdning, ett slags nyare variant av WFS | Ja | |
ArcGIS Rest Service | ESRIs REST-server som kan dela både kartor och geodata | Nej |
Här början listan: var så god!
Boverket
I sin nationella samordningsroll, tillhandahåller Boverket en karttjänst som ger en samlad bild över de nationella riksintressena enligt miljöbalken. Boverket hämtar in kartunderlag direkt från de centrala förvaltningsmyndigheterna. Mer info om myndighetens geoodata och visningsportal.
| De nationella riksintressena enligt 3 och 4 kap miljöbalken WMS: https://gis2.boverket.se/arcgis/services/Riksintressen___Februari_2025_WMS/MapServer/WMSServer ArcGIS Rest Server: https://gis2.boverket.se/arcgis/rest/services/ |
Hav-och vattenmyndigheten (HaV)
En förvaltningsmyndighet på miljöområdet som driver och samordnar arbetet för levande hav, sjöar och vattendrag. Mer info om myndighetens geodata och kartportal.
| Havsplaner samt underlagsdata till havsplanering: värdefulla vatten, limniska vattentypsregioner, fiske mm WMS och WFS: https://geodata.havochvatten.se/geoservices/ows |
Jordbruksverket
Jordbruksverket är regeringens expertmyndighet på det jordbruks- och livsmedelspolitiska området och har ett samlat sektorsansvar för jordbruk och trädgård. Mer info om myndighetens geodata och kartportal.
| Jordbruksblock, jordbruksskiften, ängs- och betesmarksinventering, markklass, produktionsplatser, skördeområden mm. WMS: https://epub.sjv.se/inspire/wms |
Lantmäteriet
Lantmäteriet kräver att alla registrerar sig på Geotorget. Dessutom ska det finnas ett systemkonto. Sedan måste du välja en produkt, lägga till den i din kundkorg, fylla i en hel del formulär med motivering och syfte. Data hittar du via geodataportalen.
Länsstyrelserna (LST)
Länsstyrelsernas regionala och nationella karttjänster (Lst-GIS) är redan ett begrepp hos gisare och en av de mest kända geodatakällorna i Sverige. I samband med att länsstyrelserna under 2025 skapat nya karttjänster och webbGIS har man även sett över vilka geodata som framöver kommer att distribueras via deras karttjänster. Bland annat har kopior av andra myndigheters geodata tagits bort. Huvudprincipen är att man ska hämta data direkt från källan, dvs från respektive ansvarig myndighet. Mer info om länsstyrelsernas öppna geodata
- Länsstyrelsernas geodatakatalog: karttjänster som innehåller länsstyrelsernas geodata indelade i ämnesområden.
- Planeringskatalogen: Länsstyrelsernas tjänst som förmedlar länsstyrelsernas och andra statliga myndigheters planeringsunderlag på ett ställe.Planeringsunderlag kan både bestå av geodata, publikationer av olika slag samt webbsidor.
- Geodataportalen: Nationell metadatakatalog för geodata och geodatatjänster i Sverige.
| Geodata länsvis (lokala visning) och geodata från olika myndigheter (nationella visning) ArcGIS Rest Servers: Lokal visning https://ext-geodata-lokala-visning.lansstyrelsen.se/arcgis/rest/services/ Nationell visning https://ext-geodata-nationella-visning.lansstyrelsen.se/arcgis/rest/services |
Myndigheten för civilt försvar (tidigare Myndigheten för samhällsskydd och beredskap, MSB)
Från den 1 januari 2026 är Myndigheten för samhällsskydd och beredskap, MSB, Myndigheten för civilt försvar. Myndigheten för civilt försvar ska leda, inrikta och samordna det civila försvaret och producerar kartor och andra geodata rörande risker för översvämningar, skogsbränder mm. Mer info om myndighetens geodata och kartportal.
| Översvämningsportalen WMS: https://gisapp.msb.se/arcgis/services/Oversvamningskarteringar/karteringar/MapServer/WmsServer ArcGIS Rest Server: https://gisapp.msb.se/arcgis/rest/services |
Naturvårdsverket
Naturvårdsverket är en statlig myndighet för klimat- och miljöfrågor och driver och samordnar Sveriges miljöarbete med ansvar för bl a biologisk mångfald, miljöövervakning och miljöforskning. Mer info om myndighetens geodata och kartportal Skyddad natur.
| Skyddade områden enligt miljöbalken och med stöd av internationella avtal, utbredning av arter och fåglar listade i Art- och Fågeldirektivet samt invasiva arter, Natura 2000 naturtyper, riksintressen för naturvård och friluftsliv, områden med särskilda restriktioner, Nationella marktäckedata (LandCoverRaster) mm. WMS: https://geodata.naturvardsverket.se/geoserver/wmshttps://geodata.naturvardsverket.se/andra_skydd/wms WFS: https://geodata.naturvardsverket.se/geoserver/wfs |
Riksantikvarieämbetet (RAÄ)
Den nationella kulturarvsmyndigheten med uppgift att bevara, använda och utveckla kulturarvet. Mer info om myndighetens geodata och Öppna data-portal.
| Lämningar (fornlämningar, övriga kulturhistoriska lämningar mm) samt arkeologiska uppdrag (uppdragsområden och grävda ytor). WMS: https://pub.raa.se/visning/lamningar_v1/wms? INSPIRE WMS: https://inspire-raa.metria.se/geoserver/ows WFS: https://inspire-raa.metria.se/geoserver/TEMA/wfs OGC API Features: ttps://inspire-raa.metria.se/geoserver/Tema/ogc/features/v1/ |
Sjöfartsverket
Ett affärsverk med uppdrag från regeringen att ansvara för tillgänglighet, framkomlighet och säkerhet till sjöss. Data är indelade i teman. Mer info om myndighetens geodata, karttjänster och Kartvisare Fyren
| Sjökort (Transportstyrelsen) WMS: https://geokatalog.sjofartsverket.se/MapService/wms.axd/Sjokort_TS Förteckning över de övriga teman WMS, WFS: https://geokatalog.sjofartsverket.se/mapservice/ |
Skogsstyrelsen
Myndigheten för frågor som rör skog med uppgift att verka för att skogen sköts så att de skogspolitiska målen nås. Skogsstyrelsen erbjuder flera karttjänster, bl a Skogliga grunddata, Skogens pärlor, och Skogsvattenkarta. Skogliga grunddata byggs på data som tagits fram av Sveriges Lantbruksuniversitet SLU (markfuktighet, trädhöjd, volym, biomassa mm). Mer info om myndighetens geodata och karttjänster.
| Sumpskogar, nyckelbiotoper, biotopskydd, utförda avverkningar mm. Obs: Data som tagits fram av SLU (markfuktighet, trädhöjd, volym, biomassa mm) är tillgängliga för aktörer som deltar i geodatasamverkan och kräver ett användarkonto. ArcGIS Rest Server: https://geodpags.skogsstyrelsen.se/arcgis/rest/services |
Sveriges lantbruksuniversitet (SLU)
Ett svenskt statligt universitet med ansvar för areella näringar, dvs näringar som använder biologiska och naturgeografiska resurser på land och i vatten. SLU är på uppdrag av Naturvårdsverket och Havs- och vattenmyndigheten datavärd för viss data som samlas in genom nationell och regional miljöövervakning. SLU Artdatabanken är ett kunskapscentrum för Sveriges arter och naturtyper med uppgift att kartlägga tillståndet för den biologiska mångfalden i Sverige. Vissa dataset är öppna geodata.
| Elfiske, skyddsvärda träd Se Länsstyrelsernas ArcGIS Rest Server Markfuktighet, trädhöjd, volym, biomassa Se Skogsstyrelsens ArcGIS Rest Server(för aktörer som deltar i Geodatasamverkan och kräver ett användarkonto). |
Statens Geotekniska Institut (SGI)
Statens geotekniska institut (SGI) är en expertmyndighet med uppdrag att arbeta för ett säkert och hållbart samhällsbyggande, bland annat genom att ta fram riskområden för ras, skred och erosion. Mer info om myndighetens geodata och kartvisningstjänster.
| Höjdprofiler, skreddatabas, nationella riskområden, kustlinjer (2015-2022) mm WMS: https://mapsext.sgi.se/geoserver/wms WFS: https://mapsext.sgi.se/geoserver/wfs |
Statens Geologiska Undersökning (SGU)
SGU är en myndighet som tillhandahåller geologisk grundinformation om berg, jord och grundvatten och utför miljöövervakning av grundvatten och havssediment.
SGU delar sina geologiska data efter ämnesområden. Varje tema (ämnesområde) har en egen WMS-länk. Därför behöver man veta vilket tema man vill se och sedan lägga temat i länken. Mer info om myndighetens geodata och kartvisare.
| Jordarter, berggrund, malmer och mineraler, jordarter, grundvatten, brunnar, geokemi, maringeologi, allmänt geologi och samt data kopplade till samhällsplanering: grus, ballast, markens genomsläpplighet mm. WMS: https://resource.sgu.se/service/wms/[AKTUELLT TEMA] Till exempel: Jordarter i skala 1:25 000 – 1:100 000 https://resource.sgu.se/service/wms/130/jordarter-25-100-tusen (TEMA = “130/jordarter-25-100-tusen”) INSPIRE WMS: https://resource.sgu.se/service/wms/inspire/[TEMA] OGC Api Features: https://api.sgu.se/oppnadata/[TEMA]/ogc/features/v1 |
Statistikmyndigheten Statistiska centralbyrån (SCB)
Myndigheten ansvarar för officiell statistik och annan statlig statistik. Befolkning, arbetsmarknad, export, import, BNP och inflation mm. Mer info om myndighetens öppna geodata.
| Befolkningsstatistik i 1 km2 rutor samt avgränsningar för andra statistikområden t ex tätorter, arbetsplats-, verksamhets-, fritidshus- och grönområden mm WMS: http://geodata.scb.se/geoserver/stat/wms WFS: http://geodata.scb.se/geoserver/stat/wfs |
Svenska Kraftnät (SvK)
SvK är ett statligt affärsverk som är systemansvarig myndighet för kraftsystemet och som förvaltar och utvecklar Sveriges transmissionsnät för el. Svenska kraftnät är också elberedskapsmyndighet och tillsynsvägledande myndighet i frågor om dammsäkerhet samt tillsynsmyndighet för elförsörjningens säkerhetsskydd. Mer info om myndighetens geodata.
| Stamnät (400 kV, 220 kV): kraftledningar, kraftledningsstolpar, transformatorstationer. WMS: https://inspire-skn.metria.se/geoserver/skn/ows |
Sveriges meteorologiska och hydrologiska institut (SMHI)
SMHI är en expert- och beredskapsmyndighet inom väder, vatten och klimat med uppgift att ta fram prognoser för väder, vind, vatten samt klimat och miljö. Data är uppdelade enligt teman. Mer info om myndighetens geodata.
| Vattendragslinjer, huvud- och delavrinningsområden, avrinningsområden för vattenförekomster, havsområden och vattenytor mm WMS: https://opendata-view.smhi.se/SMHI_vatten/wms WFS: https://opendata-view.smhi.se/SMHI_vatten/wfs |
Trafikverket
Trafikverket ansvarar för den långsiktiga planeringen av infrastruktur för vägtrafik, järnvägstrafik, sjöfart och luftfart samt för byggande och drift av statliga vägar och järnvägar. Mer info om myndighetens geodata.
| Nationella vägdatabas (NVDB): statliga, kommunala och enskilda vägar samt omfattande info om övriga attribut kopplade till vägarna. Nationell järnvägsdatabas (NJDB): järnvägsnätet och attribut. WMS Vägnät: https://geo-netinfo.trafikverket.se/MapService/wms.axd/NetInfo_1_8https://geo-netinfo.trafikverket.se/MapService/wms.axd/NetInfoRoad_1_3 Järnvägar: http://geo-baninfo.trafikverket.se/mapservice/wms.axd/BanInfo_1_4 WFS Bytes-och stoppunkter: http://geo-transfernode.trafikverket.se/mapservice/wfs.axd/TN_TransferNode ArcGIS Rest Servar: https://vektor.trafikverket.se/gis/rest/services/ https://vektor-pr.trafikverket.se/gis/rest/services INSPIRE WMS: http://geo-inspire.trafikverket.se/MapService/wms.axd/TN_RailTransportNetwork WFS: http://geo-inspire.trafikverket.se/MapService/wfs.axd/TN_RailTransportNetwork |
Vattenmyndigheterna
Sverige är uppdelat i fem vattendistrikt och en länsstyrelse i varje vattendistrikt är utsedd att vara vattenmyndighet med uppdrag att genomföra EU:s ramdirektiv för vatten.
Vattenkartan och databasen VISS (VattenInformationsSystem Sverige) innehåller flera myndigheters data och är Sveriges rapporteringssystem till EU-kommissionen.
| WMS: Se länsstyrelsernas Arcgis Rest Server i mappen VM. |
Saknas det någon öppen geodatatjänst? Hör av dig till oss på info@gispo.se så uppdaterar vi listan vartefter.
Nu är det dags att runda av detta blogginlägg med två återstående QGIS-tips.
QGIS-tips 2/3
Man kan skapa ett QGIS-projekt (“Fröet.qgz” kanske?) och lägga till de geodatatjänster man själv behöver och sedan komplettera projektfilen vartefter. Om man grupperar skikten i önskad ordning i Lagerpanelen får man en bättre överblick. Skulle någon av länkarna sluta fungera, får man en röd varningstriangel efter skiktets namn, se bild nedan. Data har nog inte försvunnit helt utan datavärden har flyttat tjänsten till en ny plats.

QGIS tips 3/3
När du har lagt till geotatjänsterna i QGIS vill du kanske dela med dig av till din kollega de länkar som känns relevanta. Hur gör man det på ett smidigt sätt?
Jo, det finns en magisk liten funktion som är lätt att missa: “Save”, se bild nedan. Trycker man på den, får man välja enskilda eller alla kopplingar och exportera dem till en xmlfil.
Sedan behöver kollegan bara trycka på “Load” och hämta htmlfilen för att få tillgång till alla geodatatjänsterna.

Datacenter, dataförbindelser och molntjänsteplatformer är begrepp som numera dyker upp i huvudnyheter och i vardagsspråket. För i tiden var det bara några datanördar och nätverksspecialister som hade koll på el- och datakablar på sjöbotten i Östersjön. Men nu har vi alla fått upp ögonen för sjökablarna och känner till att de jämt verkar bli skadade (bl a i november 2024, under julhelgen 2024 och vid årsskiftet 2025. Vi har också lärt oss att till synes helt vanliga händelser kan orsaka oväntade kedjereaktioner. Katter som gillar värme alstrad av dataservrar kan direkt komma att påverka kryptovalutorna eller en elektriskt styrd säng kan fastna i fel läge när Amazon Web Services (AWS) håller på med att göra två saker samtidigt.
Molntjänsterna kan även strula till av mer abstrakta skäl. Råkar man representera fel organisation, kommer man kanske inte längre åt sitt Microsoftkonto. Vill man fortsätta främja mångfald, likabehandling och inkludering (DEI) inom sin egen organisation, kan relationerna till aktörer på andra sidan Atlanten tar skada vilket i sin tur leder till digitala konsekvenser i vardagen. Det är inte otänkbart att listan med dessa tragikomiska, absurda anekdoter blir längre under 2026.
En server är alltså inte längre bara en server. En datacenter är inte heller bara en teknisk anläggning där man lagrar och hanterar IT-system och data, och som t o m producerar lite mysig spillvärme på köpet.
Detta blogginlägg innehåller mina reflektioner kring vad man kan göra helt konkret för att undvika avbrott i molntjänster eller åtminstone komma lite snabbare på fötterna igen efteråt.
Vilka alternativ finns där ute? Varför borde vi ha ögonen öppna för dem?
Man kan betrakta IT-tjänsternas underhåll från många olika vinklar. Säkerhet, beredskap och självförsörjning debatteras numera flitigt på olika forum, inte bara på IT- och GIS-seminarier. Europas digitala suveränitet är ett begrepp som börjat klinga bekant, eller hur?
Flera organisationer har redan hunnit flytta sina IT-tjänster till det berömda molnet eller åtminstone håller på med det för fullt. Traditionellt har valet stått mellan två amerikanska leverantörer: AWS från Amazon eller Azure från Microsoft. Dessa två har varit så gott som de facto standarder inom branschen. Båda leverantörerna erbjuder också ett antal tilläggstjänster utöver själva datalagringen. Vid valet spelar också organisationens tidigare beslut en roll: använder man redan Microsofts tjänster, är det lätt att fortsätta på samma spår och komplettera med Azure också. Efteråt kan man motivera sitt eget val med att “alla andra gör likadant”.
Även om Amazon och Microsoft är företag med säte i USA erbjuder de ändå datalagring i datacenter i Stockholm och i centrala Europa (“region”). Det ger ju en känsla att servrarna ligger geografiskt ganska nära. Räcker det? Det beror på. Hur vill man se på saken? Kopplingen bildas ju inom EU men de finansiella flöden leder fram till andra sidan av Atlanten och det verkliga ägarskapet och därmed beslutsfattandet stannar kvar där.
Är man intresserad av Sveriges och EU:s suveränitet, är lösningen att börja främja svenska eller europeiska (inom EU) leverantörer. När det gäller GDPR vill man ställa frågan om det är motiverat att data ska hamna hos en amerikansk leverantör eller överhuvudtaget lämna Sverige. Microsoft har redan erkänt att de inte kan garantera att data stannar kvar inom EU utan kan hamna hos den amerikanska administrationen. De mest cyniskt lagda tror förstås att oberoende av system kommer alla data i slutändan ändå hamna i Kina.
Ett alternativ som man har som kund är att sprida risken genom att anlita flera olika leverantörer, t ex genom att sätta upp den primära instansen respektive reservinstansen hos två olika leverantörer. Får man avbrott och den primära instansen inte fungerar, kan datatrafiken ledas till reservinstansen.
Innan man fattar beslut om leverantör brukar man göra en risk- och nyttoanalys och se vad som behövs för att uppfylla kraven i de relevanta standarder som styr den egna verksamheten utifrån det bästa tillgängliga kunskapsunderlag.
Men det finns även anledning att reflektera över eget ansvar från ett ännu bredare perspektiv. Man är ju alltid något mer än bara en kund som har rättigheter och bråttom. Alternativa system och tjänster kommer aldrig kunna ta fart och lyfta om kunderna inte aktivt väljer att satsa på dem. Stora aktörer kommer annars fortsätta vara stora och små aktörer förblir små eller försvinner helt om pengaflöden fortsätter åt samma håll som tidigare.
I slutändan är det just kunden som beslutar om investeringen och vad det innebär, politiskt och etiskt. Tjänsterna måste underhållas någonstans. Beslut som har fattats – eller inte fattats – kan alltid motiveras på många olika sätt. Även med handen på hjärtat.
Vad har olika molntjänster för egenskaper och skillnader?
Frågan kan behöva ställas om. Vilka egenskaper och tjänster är relevanta för kunden respektive leverantören? Många leverantörer erbjuder olika saker: vissa tillhandahåller tomma servrar, andra ett stort utbud av datorer och olika typer av tilläggstjänster, allt från AI-verktyg till lambdafunktioner.
Om organisationen har redan satt upp en instans i molnet, är många av besluten redan fattade. Man har behövt ta ställning till hur man övervakar tjänsten, t ex med hjälp av en programvara som har installerats separat alternativt med en programvara som ingår i den valda tjänstens plattform. Man har också redan valt hur instansen har satts upp: i en container eller med hjälp av en script. De beslut som redan har fattats resulterar ofta i att man blir bunden till den valda plattformen. Om tjänsten är tänkt att fungera på en viss plattform och utnyttja plattformens egna verktyg kan en eventuell flytt till en annan plattform i framtiden bli en utmaning.
Om man fortfarande befinner sig mitt i processen och väljer plattform och tjänsteleverantör, brukar de två vanligaste frågorna vara: “Vad kostar det?” och “What’s in it for me?”
Svaret på den första frågan blir däremot klassikern “Det är lite komplicerat”. De slutliga kostnaderna ser man när först när den fakturan kommer. Mycket beror på vilka datorer man har valt från plattformen, vilka tjänster man använder och datatrafikens volym. Svaret på den sista frågan är mer filosofiskt och subjektivt men du har redan börjat klura på det eftersom du har läst så här långt.
Efter att man har valt en molntjänst från en viss leverantör kan man upptäcka så småningom att man har utvecklat leverantörsberoende (s k vendor lock-in). Detta händer lätt om tjänsten har skräddarsytts och satts upp på en molnplattform som bygger på plattformens egna specifika funktioner eller är direkt beroende av dem. Man kan göra en bedömning av hur beroende man är av en viss plattform genom att ta reda på om det är möjligt att sätta upp en motsvarande tjänst på någon annan plattform och hur snabbt det skulle kunna gå att ordna.
Vill man undvika leverantörsberoende och säkra sig om att molntjänsten kan snabbt sättas upp på en annan plattform rekommenderar vi att man använder programmeringsspråk (t ex Ansible, Terraform eller Open Tofu) för att definiera miljön på plattformen. Vi på Gispo har goda erfarenheter av dem när vi har satt upp instanser för våra supportkunder.
Det krävs arbete och uppdaterade kunskaper för att kunna sätta upp en automatiserad instans, men då har man en fördel om problem uppstår. En ny instans kan i bästa fall vara uppe så snabbt som på en dryg halvtimme. Fördelarna med script blir kännbara även till vardags: med ett kommando kan man köra uppdateringar, ändra inställningar i servermiljön eller sätta upp en helt ny instans för att kunna testa något. Ett välskrivet och väldokumenterat (!) script automatiserar arbetet och minskar behov för handpålägg den dag då inställningar ska köras om.
Några sista ord
Det som hänt under de senaste åren har öppnat alla våra ögon för något konkret: internet finns fysiskt någonstans, inte upp i det blå. Komponenterna som internet bygger på kan gå sönder. Det världspolitiska läget visar också att nästan vilken handelsvara som helst kan bli en bricka i ett politiskt spel.
Till sist och syvende är det kunden som bestämmer vad som gäller, hur beställningen ser ut och hur tjänsten levereras. Om organisationen redan fattat linjebeslut om t ex Azure som molnplattform, hjälper vi våra kunder i deras miljö så klart..
Men vill man välja en annan väg än de två största så finns det redan alternativ. Det är bra att komma ihåg att förändring sker endast om vissa vågar gå mot strömmen. Annars fortsätter allt rulla på som förut och vissa företag fortsätter ha en monopolställning utan att nya aktörer få möjlighet att visa vad de har att erbjuda för alternativ. I Europa och Finland finns redan leverantörer som erbjuder molntjänsteplattformer. Vi på Gispo vill gärna stötta kunder som är intresserade av att tänka om och vi hjälper till med kartläggning av alternativ. Entusiasterna som är nyfikna kan redan ta en titt här. När beslutet är fattat kan vi börja fundera på hur tjänsten kan sättas upp automatiskt för att slippa så mycket av manuellt arbete som möjligt i fortsättningen.
Ingen kan – eller ens behöva vara – bäst med en gång eller första hela processen i detalj. Att våga ta första steget är det viktigaste när man vill påbörja en resa.
Det händer ibland att någon kollega frågar “kan jag få en karta?”, varpå du svara “javisst, alltid kul att göra en karta”. Du gör en karta och skickar iväg den som en pdf-fil.Sedan kanske det händer igen. Och igen. Och igen. Du börjar kanske bli lite trött på att vara en kartmaskin i något skede och börjar fundera på om det inte finns något lättare sätt att sköta den här ruljansen. Vad du behöver är ett sätt att dela geodata på.
Kanske har du en hög med fina filer som du laddat upp i en databas. Du kan såklart ta direkt kontakt med databasen via till exempel Databashanteraren i QGIS och det fungerar fint på ditt jobb. Men nu vill din kollega (vi kallar honom Folke) också ha tillgång till samma geodata som ligger i databasen. Problemet är bara att Folke är ganska klumpig när det gäller datorer. Till exempel skickade han listan på allas “secret santa” per e-post till alla på kontoret, dagen före jobbets julfest.
För att vi ska kunna hantera olika personers tillgång till databasen kan vi såklart skapa flera användare och reglera deras rättigheter med olika SQL-kommandon, men det blir ganska omständligt att hålla reda på allt och alla. Dessutom anser IT-avdelningen att det alltid finns risker med direktkontakt med databasen, och de säger att de går i strejk om Folke får direkt tillgång till databasen.
Chefen (vi kallar henne Berit) har också bestämt att vi nu ska dela geodata även med andra avdelningar på jobbet. Grafikerna (Vincent och Cassiopeia) behöver färdiga snygga kartor som bakgrund för deras verk.
Du bestämmer dig för att du behöver en server som kan fungera som mellanhand mellan databasen och slutanvändaren. Där ska du ha möjlighet att reglera tillgången till data och dela ut användarroller. Men vad har du för alternativ?
Du behöver en tjänst av någon slag. Kärt barn har många namn, och det kan vara svårt att veta när det finns många namn för (ibland delvis) samma sak. Här är en lista på några begrepp man stöter på och en tolkning som enbart baseras på Gispos erfarenhet. Ifall du har några bra uppslagsböcker med GIS-relaterad vokabulär så får du väldigt gärna sända oss ett exemplar. Vi bjuder på fika åt den första.
| Begrepp | Vår tolkning |
| Geodatatjänst | Ett begrepp som innefattar nedladdningstjänster, direktåtkomsttjänster och visningstjänster för geografiska data. Ibland kan det även tolkas som enbart någon av de tidigare nämnda tjänsterna. |
| Gränssnittstjänst | Ett bredare begrepp som innebär en uppsättning definierade regler och protokoll som tillåter olika programvarusystem att kommunicera och utbyta information med varandra. Det finns många olika gränssnittstjänster, t.ex. REST och SOAP, men eftersom vi fokuserar på geodata så är vi mer bekanta med WMS, WFS och så vidare. |
| Karttjänst | En tjänst som levererar kartor. Till exempel WMS, WMTS men ofta nämns också WFS. Det kan kanske debatteras om WFS verkligen borde tillhöra den här familjen, för WFS levererar geodata och inte en kartbild. Vi har stängt av kommentarerna på detta blogginlägg så ni får gräla om det någon annanstans. |
| Kartdelningstjänst | Ett begrepp som vi stött på ganska sällan men skulle högst antagligen syfta på samma sak som “karttjänst”. |
| Nedladdningsstjänst | En tjänst för att ladda ner geografiska data, t.ex. STAC. Kan tolkas som att den inte ger direktåtkomst. |
| Visningstjänst | En tjänst för att se kartor, så t.ex. En WMS- eller WMTS-tjänst. |
Du kanske upplever att tabellen ovan inte gjorde dig smartare, utan snarare kollrade bort dig ännu mer. Ingen panik. Vi på Gispo delar den känslan. Kanske bäst att bara gå vidare?
QGIS Server eller GeoServer – hur ska man välja?
Det finns många alternativ till att dela geodata, men chefen påstår att marknadsläget inte tillåter höga utgifter, så du undviker alla alternativ med licensavgift. Istället kollar du in några som är byggda på öppen källkod. QGIS Server känns nära till hands, för du använder redan QGIS till det mesta. Men du har även hört gott om GeoServer. Vilken ska man då välja?
Valet av geodataserver kan vara svårt och man måste inleda med att klargöra sina egna behov. Här är några frågor du måste ställa:
- Vad behöver jag dela?
- Till vem behöver jag dela?
- Hur vill jag sköta konfigureringen?
- Hur mycket behöver jag dela?
- Hur ser framtidsplanerna ut?
- Hur ser vår IT-infrastruktur ut?


Vad behöver jag dela?
Ifall du vill dela kartor så behöver du en WMS, WMTS eller OGC API – Tiles- tjänst. Vänta lite, nu blev det kanske lite många förkortningar. Kolla tabellen nedanför för att få en överblick över tjänsterna.
| Förkortning | Hela namnet | Förklaring | Datatyp* |
| WMS | Web Map Service | Standardiserad visningstjänst som ritar en ny karta varje gång du ber om det. | Raster |
| WMTS | Web Map Tile Service | Standardiserad visningstjänst som tar färdiga “bilder av kartan” från ett lager och levererar dem. | Raster |
| OGC API – Maps | Open Geospatial Consortium Application Programming Interface – Maps | Standardiserad visningstjänst som är ett slags uppföljare till WMS | Raster |
| OGC API – Tiles | Open Geospatial Consortium Application Programming Interface – Tiles | Standardiserad visningstjänst som är ett slags uppföljare till WMTS | Raster |
| WFS | Web Feature Service | Standardiserad direktåtkomsttjänst. Du får alltså direkt åtkomst till geodata. | Vektor |
| OGC API – Features | Open Geospatial Consortium Application Programming Interface – Features | Standardiserad direktåtkomsttjänst som är ett slags uppföljare till WFS | Vektor |
| * Datatyp avser leveransformatet. Raster innebär en bild med pixlar, där varje pixel innehåller ett eller flera värden. Vektor innebär geometriska objekt innehållande attributdata. | |||
WMS och WMTS är alltså protokoll för hur man delar kartor som används väldigt brett världen över. Protokoll innebär ett slags regelverk för hur man ska dela kartan eller geodata. Men vill man vara ett steg i framtiden så bör man blicka mot OGC API – Maps och Tiles, för de för med sig samma funktionaliteter men i ett modernare format. I skrivande stund (december 2025) så verkar GeoServer ha moduler som redan stöder OGC API Maps och OGC API Tiles medan QGIS Server inte har det. Men vi kommer antagligen att se ett stöd för dessa protokoll i framtiden, eftersom arbetet för att inkludera dem redan verkar vara igång på Github.
Ifall du behöver dela geodata, alltså inte bara kartbilder, så behöver du WFS eller OGC API Features. Du kan alltså ladda ner data till din egen dator med dessa gränssnittstjänster. Med vektordata kan du sedan göra analyser och förädla data enligt behov.
WFS har ett brett stöd och du kan hitta det som standard på massvis av olika ställen, men vi kommer att se mer och mer av den nyare standarden OGC API – Features. Båda protokollen går att användas med både QGIS Server och GeoServer.
Men kanske du behöver dela något annat? Här är några till som du kanske kan ha nytta av:
| Tjänst | Stöds av QGIS Server | Stöds av GeoServer |
| CSW | Nej | Ja |
| WCS | Ja | Ja |
| WPS | Nej (finns ett föråldrat plugin) | Ja |
| OGC API – Coverages | Nej | Ja |
| OGC API – Processes | Nej | Ja |
| OGC API – Styles | Nej | Ja |
I vårt exempel (möjligen inspirerat av verkliga personer) så skulle till exempel kollegan Folke få tillgång till en WFS- och WMS-tjänst, medan grafikerna bara behöver tillgång till en WMS-tjänst.
Till vem behöver jag dela?
För att veta vilken geodataserver du ska välja så bör du veta ungefär vem du vill att ska få tillgång till tjänsterna. Kommer du att dela data öppet åt allmänheten, åt kolleger eller även utomstående, men bakom lösenord. Ifall du behöver mer rigorösa sätt att hantera användare och deras åtkomst så är GeoServer det mer naturliga valet. QGIS Server saknar ett inbyggt system för användarautentisering så då måste du lösa det utanför QGIS Server.
GeoServer har ett inbyggt användarautentiseringssystem där du kan konfigurera roller, grupper och använder. Dessutom finns modulen GeoFence som ger dig mer avancerade konfigurationsmöjligheter.
I exemplet så kunde man eventuellt luta mer mot GeoServer, där man kunde skapa en egen roll för användare som Folke, som behöver vektordata och bakgrundskartor, medan grafikerna kunde få mer begränsad tillgång till bara WMS-tjänster.
Hur vill jag sköta konfigurering?
Du kommer att hamna pilla på några inställningar nu och då, kanske lägga till eller ta bort någon tjänst och så vidare. Då kommer du att behöva konfigurera din geodataserver. Med QGIS Server så sker konfigureringen inne i QGIS. Det mesta hittar du under Projektegenskaperna.

GeoServer däremot har ett eget användargränssnitt som du öppnar upp i din webbläsare. Du kan tänka dig att du har en egen webbsida där du sköter alla inställningar. Visst, ifall du väljer GeoServer är du tvungen att använda en till grej förutom QGIS, men GeoServers användargränssnitt är ganska logiskt uppbyggt, så du kommer klara dig. För den riktigt inbitne så finns det faktiskt en möjlighet att konfigurera GeoServer med REST. Då kan man skapa skript som kan automatiseras och köras vid behov, istället för att göra konfigureringar via det grafiska användargränssnittet.
Hur mycket behöver jag dela?
Kommer servern att vara i bruk för ett begränsat antal personer, eller finns det en möjlighet att processen måste skalas upp så småningom? Finns det ett växande behov? Ifall du har behovet att skala upp så skulle antagligen GeoServer vara ett bättre alternativ. Det finns till exempel stöd för klusters och lastbalansering. Dessutom finns det ett inbyggt stöd för caching via GeoWebCache.
Du kanske inte riktigt hängde med vad caching är för något? Vi tar ett praktiskt exempel, först utan caching:
Folke vill ha en kopp kaffe med helmjölk så han skickar praktikanten Amir att hämta en kopp från fikarummet, men i fikarummet finns det inget färdigt kaffe och för att inte göra Folke besviken så kokar Amir en kopp kaffe och häller i en skvätt helmjölk och levererar den åt Folke. Det är så här en WMS-tjänst funkar. Med andra ord så gör Folke en förfrågan (request) på en kopp kaffe och för att få den så genererar WMS-tjänsten (i detta fall Amir) en kopp kaffe när Folke ber om det och levererar den till Folke.
Nästa dag är Amir förberedd. Han har kokat kaffet färdigt i en termos i fikarummet (på morgonen innan Folke anlänt). Igen sänder Folke iväg Amir för att hämta en kopp kaffe, men nu tar det mycket kortare tid för kaffet att komma, för Amir tar kaffet direkt från termosen och levererar en kopp åt Folke. Nu har Amir fungerat som en WMTS-tjänst där han lagrat (caching) kaffet i en termos, istället för att varje gång koka en ny kopp.
Caching i en geodatatjänst betyder alltså att man lagrar färdiga “bilder” på en karta som får en förfrågan, istället för att generera bilden varje gång på nytt. Det positiva är att själva leveranstiden blir kortare, men ifall data som bilden bygger på uppdateras så måste även cachen uppdateras. Ibland blir data föråldrat och även om vi uppdaterat datat men inte cachen så kommer vi att se “gamla bilder”. Till exempel så kanske Amir inte kan leverera samma termoskaffe nästa dag, eftersom data eller kaffet blivit föråldrat. Okej kanske inte världens bästa liknelse, men ni fattar galoppen!
Hur ser vår IT-infrastruktur ut?
Har ni redan QGIS och vill så snabbt som möjligt testa att dela data via en server så är QGIS Server ett behändigt alternativ. Det kräver inte särskilt mycket att komma igång. Ni kan behändigt konfigurera servern inuti QGIS (via projektegenskaperna).
Har ni redan IT-infrastruktur som bygger på Java och någon på kontoret som har annan bakgrund med Java-baserade program så kanske GeoServer är det naturliga alternativet. Om ni däremot gärna vill ha GeoServer men inte kunskapen så finns det kurser man kan gå.
Det finns inte heller något som hindrar er från att testa båda två. Båda bygger på öppen källkod så de är bara att ta i bruk, eftersom det inte kräver några extra kostnader.
Hur ser framtidsplanerna ut?
Vad har ni för visioner? Både GeoServer och QGIS Server kommer regelbundet med uppgraderingar och båda används världen över. Kommer era behov att ändra så kan det hända att ni får ställa samma frågor som vi ställt ovan på nytt, och ge dem nya svar.
Behöver ni hjälp?
Vi på Gispo erbjuder er vägledning och hjälp med att båda ta i bruk och upprätthålla geodataservrar. Hör av er för att diskutera mera. Ni når oss på info@gispo.se!
GeoServer är en serverprogramvara byggd på öppen källkod som är gjord för att dela geodata. GeoServer publicerar data från många olika geografiska datakällor med hjälp av öppna standarder. Den ger användare möjligheten att se men också redigera data. Ett utmärkt sätt alltså att få ut det mesta av geodata!
Se bilden nedan för att få en översikt om vad GeoServer kan göra. GeoServer fungerar som en slags förmedlare mellan geodatakällan och slutanvändaren.

Vem behöver GeoServer?
För alla som vill få ut det mesta av geodata och dess delning via gränssnitt! GeoServer är, trots all sin mångsidighet, ändå mycket lätt att använda. GeoServer kan utnyttjas av bland annat kommunanställda, utvecklare, konsulter, forskare och medborgare! GeoServer anpassar sig alltså till behoven inom många olika sektorer som använder geodata, vare sig det handlar om att skapa och analysera geodata eller att dela den.
Trevligt användargränssnitt
Som en lätt introduktion presenterar vi strukturen i GeoServers grafiska användargränssnitt. Här ser vi en bild av GeoServers startsida innan vi har loggat in med användaruppgifter. Redan här kan man få en bra överblick av GeoServers struktur. I gränssnittet syns dock ännu inte GeoServers många olika funktioner, men efter inloggning blir dessa tillgängliga. Låt oss alltså jämföra hur GeoServer ser ut efter inloggning!
Så här ser GeoServer ut före inloggning:

Och så här efter inloggning. Som vi kan se har en mängd olika funktioner dykt upp i den vänstra sidomenyn! Sidomenyn är markerad med rött i bilden.

Då är det dags att dyka djupare in i GeoServers värld
Börja med arbetsytor och förråd!
Först är det bra att behärska det lokala språket. Centrala begrepp i GeoServer är: arbetsytor (workspace), förråd (store) och lager (layer). Arbetsyta är precis som namnet antyder ett “ställe” man jobbar på, alltså en enhet där man kan hantera data. Säg till exempel att vi jobbar på den fiktiva kommunen Gispoholm och har en arbetsyta för stadsplanerare som heter “stadsplan” och en för trafikplanerare som heter “trafik”.

Inom en arbetsyta kan det sedan finnas flera förråd, alltså datakällor. Stadsplanerarna behöver detaljplaner och trafikplanerarna trafikmängder, så datakällorna är olika i respektive arbetsyta. I praktiken kan ett förråd vara exempelvis en PostGIS-databas, en GeoPackage-fil eller till och med en WFS-tjänst. Från ett förråd kan man sedan skapa ett eller flera lager.
I GeoServer finns även lagergrupper (Layer Group), en grupp som innehåller flera lager. Dessa skapas i GeoServer, alltså kommer de inte direkt från datakällan. På Gispoholms kommun används lagergrupper när man skapar bakgrundskartor som består av flera lager (vägnät, vattendrag, byggnader, grönområden, osv.). Bakgrundskartan, delas till kommunens webbkarta som en WMTS-tjänst.
Släpp loss kreativiteten med stilar!
För att visualisera geodata används olika stilar. Egentligen kan stilar skapas och redigeras på flera sätt i GeoServer. Det inbyggda sättet är att skapa stilar enligt SLD, alltså Style Layer Descriptor-standarden. Vissa tycker att det kan vara lite krångligt att redigera SLD (det finns många <taggar> här och där) och föredrar därför att göra stilar CSS som enkelt kan användas via ett tillägg. CSS, alltså Cascading Style Sheets, är lite lättare för människor att läsa och förstå, så det är värt att pröva om man vill leta sig fram till den perfekta stilen.
Hurdana data gillar GeoServer?
Låt oss nu titta på vilka dataformat och standarder GeoServer stöder.
Vektor & raster
GeoServer kan smidigt hantera både vektor- och rasterdata. För att fräscha upp minnet: vektordata är data som består av punkter, linjer eller polygoner, medan rasterdata består av pixlar och blir snabbt ganska tunga att arbeta med om området som täcks är stort och/eller noggrannheten är hög. Vektordata används till exempel för att beskriva byggnader, vägar eller naturskyddsområden. Rasterdata lämpar sig däremot för att beskriva kontinuerliga ytor som till exempel höjddata.

Här lägger vi till ett förråd, alltså en datakälla för vektor- eller rasterdata.
Som nämnts tidigare kan GeoServer läsa flera olika format. I skrivande stund så kan GeoServer (version 2.27.2) läsa följande vektorformat*:
- GeoPackage
- Shapefile (som enskild fil eller katalog)
- Java Properties
Samt följande rasterformat:
- GeoTIFF
- WorldImage
- ImageMosaic
- GeoPackage
GeoServer kan också hämta data från följande geodatabaser:
- PostGIS
- H2
Data kan även hämtas via följande gränssnitt (engelska: cascaded WFS/WMS/WMTS):
- WFS
- WMS
- WMTS
*Men observera! Detta är dock inte hela bilden, eftersom GeoServer har många tillägg (plugins) som enkelt ger stöd för ytterligare format. Listan är lång, så antagligen finns ditt favoritformat med på listan.
Stödda OGC-standarder
GeoServer stöder många standarder från OGC (Open Geospatial Consortium):
- Web Map Service (WMS) – gränssnitt för kartbilder
- Web Feature Service (WFS) – gränssnitt för vektordata
- Web Coverage Service (WCS) – gränssnitt för rå rasterdata
- Web Processing Service (WPS) – gränssnitt för geoprocesser
- Catalog Services for the Web (CSW) – gränssnitt för metadata-kataloger
- Web Map Tile Service (WMTS) – gränssnitt för kartbilder med “tiles” (d.v.s. färdiga rutor som bygger upp kartbilden)

Tile caching
Ibland laddas informationen från gränssnittet långsamt (det vill säga kartan uppdateras långsamt). Då är ett sätt att snabba upp laddningen att skapa “färdiga kartrutor”. Utan dessa färdiga bitar genereras en ny bild varje gång man zoomar eller flyttar kartan. Med Tile caching så delas kartdata upp i bitar, alltså rutor, och gränssnittet hämtar bara information från de kartrutor som behövs i det aktuella kartvyn. På så sätt visas kartan snabbare för slutanvändaren, eftersom hela datasetet inte behöver hämtas och ritas varje gång.
Nackdelen är att när data uppdateras måste nya kartrutor skapas, och om datasetet är stort och många kartrutor behövs kan det ta lång tid att generera nya rutor. I GeoServers användargränssnitt finns en egen sektion för Tile caching som heter GeoWebCache. Det är ett separat program som är integrerat i GeoServer, därför ser gränssnittet på GeoWebCachen annorlunda ut.

Blev du intresserad?
Ifall du vill lära dig mer kan du anmäla dig till vår kurs “Introduktion till GeoServer”. Om du behöver GeoServer men inte orkar eller vill fixa allt själv så finns vi här för att hjälpa dej! Vi hjälper även till med underhåll!
PS. GeoServer 3 är på väg! Ifall ni behöver stöd med uppgraderingen så finns vi här!
Artikelförfattare: Anni Jusslin
Insamling av geodata ute i fält är idag möjligt med hjälp av GIS-verktyg som bygger på öppen källkod. I detta blogginlägg tittar vi närmare på två QGIS-kompatibla alternativ: Mergin Maps, utvecklad av Luttra Consulting och QField, utvecklad av Open GIS.
Båda programvarorna utvecklas vidare och detta något som vi på Gispo bevakar med stort intresse. En hel del har hänt sedan vårt senaste blogginlägg (2023) och därför är det dags att uppdatera läget.




Nyheter i Mergin Maps
Det grafiska användargränssnittet i Mergin Maps har gjorts om. Dessutom har man lagt till nya möjligheter att anpassa applikationen efter användarorganisationens behov, nya format som stöds har lagts till och arbetsytor kan administreras bättre i projekt där flera team arbetar.
Nyheter i QField
QField är inne i 3.7.x- serien och för skrivande stund heter den senaste versionen Haida Gwaii 3.7.3. Man ser ett ständigt flöde av förbättringar och nya egenskaper i QFIeld. När Ebo-serien (3.4.x) kom i hösten 2024 och introducerades GeoFence, dvs möjlighet att definiera ett aktuellt område som polygon och låta QField larma om man korsar gränsen när man är ute i fält. Övriga nyheter är förbättrade digitaliseringsverktyg som fäster mot objekt (snapping) i förutbestämda vinklar, t ex 90 graders vinklar vid inmätning av byggnader.
Värt att nämna är också möjligheten att man numera kan spara kartan som PDF direkt i QField utan att man behöver synkronisera arbetet och öppna projektet i QGIS.
Jämförelse
Ibland kan en tabell säga så mycket mer än tusen ord i löpande text. Därmed se nedan – en överblick i nötskal.
| Applikation | Mergin Maps | QField |
| Operativsystem som stöds | Android, iOS, Windows | Android, iOS, Windows |
| Format som stöds | GeoPackage, Delimited Text, Shapefile, PostGIS, Virtual Layer, WMS, WFS, MBTiles, XYZ-Tiles, GeoTIFF, JPEG, PNG, COG, GeoPDF. | GeoPackage, Delimited Text, Shapefile, PostGIS, SpatiaLite, WMS, WFS, MBTiles, WFS-T, Tiff, JPEG2000, WEBP, COG |
| Dataöverföring | Synkronisering:via molnet.Möjligt att även arbeta i offlineläge. | Synkronisering: antingen med USB-kabel eller via molnet.Möjligt att även arbeta i offlineläge. |
| Möjlighet att skapa egna plugins | Nej | Ja |
| Extern GNSS/GPS sensor? | Mergin Maps stödjer ett antal externa sensorer, se förteckning | En egen sensorHappy Q mini Stöd för externa sensorer finns med Bluetooth, TCP, tai UDP, behöver utredas från fall till fall. |
| Alternativ vid synkronisering | JaMöjligt att ställa in vilka kartor som ska synkroniseras | JaMöjligt att synkronisera alla eller endast lokala filer |
| Storlek på bildfiler | Fyra alternativ: Original, High (2-4mb), Medium (1-2 mb), Low (0.5 mb) | Möjligt att ställa maximal storlek för bildfiler |
| Avancerad hantering av arbetsytor | Ja | Nej |
| Synkronisering av mediafilerna mot databas | Ja | Inget separat verktyg |
| ArcGIS kompatibel | Ja | Nej |
| White-labeling* | Ja | Okänt |
* Företaget tillåter att man gör en egen version av applikationen och distribuerar den med eget namn via appbutik (Google Play Store, Galaxy Store, App Store).
En viktig skillnad mellan applikationerna är att QField-användare har möjlighet att programmera egna plugins. Mer info här.
Om fältarbetet kräver väldigt hög noggrannhet, är det bra att känna till att QField stödjer externa instrument (GPS/GSNN sensorer) som kopplas till mobil enhet för att förbättra noggrannhet på mätresultat.
Stöd finns för många dataformat i båda applikationerna. Man kan dock notera att endast QField för närvarande stödjer WFS-T medan Mergin Maps är bättre på att hantera virtuella kartskikt, t ex när man vill skapa vyer i QGIS med hjälp av SQL-uttryck.
Fotografering av inventeringsobjekt efterfrågas så gott som alltid i fältarbetet. Applikationerna skiljer sig något åt vid hantering av bilderna. Mergin Maps ger möjlighet att komprimera foton i fyra olika storleker: Originalstorlek, High (2-4 MB), Medium (1-2 MB) och Low (0,5 MB). Man kan även synkronisera mediadatafiler (bild, text, ljud) mellan mobil enhet och en server (t ex Google Drive eller Amazon S3) genom att använda verktyget Media-sync. I QField kan användaren ange maxstorlek (bredd och höjd) till bilden.
Skillnader i digitaliseringsverktyg
När man är ute i fält och vill digitalisera kartobjekt, behöver man tillgång till digitaliseringsverktyg som är lätta att hantera. Vissa arbetsmoment kan bara göras på plats medan andra moment man vill kanske spara tills man är tillbaka på kontoret och har tillgång till en stor skärm.
Nedan jämförs verktyg som är tillgängliga i Mergin Maps respektive QField.
| Mergin Maps | QField | |
| Geofence | Nej | Ja |
| Höjdprofil | Nej | Ja |
| Digitaliseringsverktyg | Dela objektets geometri Rita om objektets geometri Tracking (följ efter) | Dela objektets geometriOmforma objektets geometri Bearbeta (suddgummi) Digitalisering av hål i objekt Bearbeta/ändra flera attribut samtidigt Tracking (följ efter) |
| Snapping (fästa mot objekt) | Tre alternativSnapping avQFields grundinsställning för snappingSnapping enligt inställningar i QGIS | NoderSegmentVanligt förekommande vinklar |
Sammanfattningsvis kan man konstatera att QField har ett större utbud av avancerade digitaliseringsverktyg vilket är nyttigt när man behöver rita komplexa kartobjekt ute i fält.
Om man istället föredrar ett avskalat användargränssnitt med fåtal bra, enkla verktyg så att man lätt kommer igång med fältarbetet kan man välja Mergin Maps.
Användargränssnitt
Båda applikationerna mycket i gemensamt. Det finns dock vissa skillnader värt att nämna när det gäller användargränssnittet. I QField får man växla mellan två lägen: antingen tittar man på kartan eller redigerar den. I Mergin Maps redigerar man objekt direkt.
När man använder QField, får man känslan att man har QGIS i “fickstorlek”. Man kan ändra inställningar som styr enskilda kartlager (bl a transparens, etiketter, snapping) direkt i QField. Ett långt tryck på ett kartlager ger åtkomst till flera verktyg. Däremot i Mergin Maps gör man dessa inställningar i QGIS vid datorn.
Generellt kan man säga att Mergin Maps är kanske lite lättare att komma igång med, tack vare sitt mer avskalat användargränssnitt. Detta är en fördel särskilt om man inte har så mycket tidigare erfarenhet av mobila GIS-applikationer. Mergin Maps är en rätt så renodlad fältapplikation utan stort antal kartografiska inställningar. Tanken med arbetsflödet är att man anger inställningar i QGIS under förberedelserna inför fältarbetet.
När det gäller webbgränssnittet, är Mergin Maps en aning mer avancerad. Man har också en webbkarta vilket underlättar livet för dem som vill följa framdriften av arbetet men kan inte av olika skäl använda QGIS på datorn. Versionshantering i Mergin Maps är också något lättare än i QField. För övrigt är de grundläggande funktionerna i webbapplikationen i princip identiska i QField och Mergin Maps.
Här hittar man en demo på Mergin Maps.

Nedan finns en demo på QField.

QField: kartskikten och inställningar finns till vänster i användargränssnittet.
Synkronisering av data via molnet
QFieldCloud är en molnbaserad tjänst som möjliggör överföring och delning av data till och från QField. QFieldCloud bygger på PostgreSQL- och PostGIS-databaser. Man kan köpa en färdig molntjänst från OpenGIS eller sätta upp en egen instans.
Mergin Maps erbjuder också en molntjänst för datalagring och synkronisering mellan fältapplikationen och QGIS. Man kan köpa en färdig molntjänst från Luttra Consulting eller sätta upp en egen instans.
Se nedan en sammanställning. Prismodellerna kan naturligtvis komma att ändras efter att detta blogginlägg har publicerats. Därmed kan det vara en bra idé att kontrollera leverantörernas hemsidor för dagsaktuell information.
| Mergin Maps | QField Cloud | |||
| Namn på molntjänst | Premium | Community | Pro | Organization |
| Pris / Användare | 15,80 € /dataproducent Obegränsat antal användare med endast läsrättighet | Ingen kostnad Lagrings-utrymme begränsat | 12 €/ användare*15 €/ användare | 16 €/ användare*20 €/ månad |
| Lagrings-ytrymme | 1 Gtb/ dataproducent | 100 Mb | 1 Gb** | 1 Gb** |
| Tillgång till versions-historik | Inte begränsat | 3 versioner | 10 versioner | 10 versioner |
| Gratis provperiod | 28 dagar | Utan kostnad | 28 päivää | |
| Pris | 15,80 €/mån | Ingen konstnad | 12 €/ användare*15 €/ användare efter 6 månader15 €/ käyttäjä 6 kk jälkeen | 16 €/ användare*20 €/ användare efter 6 månader |
* Prissättning: EarlyBee möjlig under de första 6 månaderna.
** Mer lagringsutrymme möjligt att skaffa, prissättning, 1 Gb för 5 €/månad.
Köpa en molntjänst med månadsavgift eller sätta upp en egen?
Både Mergin Maps och Qfield bygger på öppen källkod. Därför är det möjligt att sätta upp en egen molntjänst (instans) på en egen server som en sk on-premises lösning eller köpa en färdig molntjänst från Luttra Consulting (Mergin Maps) resp OpenGIS (QField).
Vad ska man tänka på innan man väljer?
Fördelen med en färdig tjänst är att det är enkelt och smidigt. Den avgörande frågan inför valet handlar om egna datas känslighet och sekretessklassning. Båda molntjänsterna har är skyddade men vissa typer av känsliga data kan inte lagras i en databas hos tredje part.
Prissättning av tjänsterna skiljer sig åt mellan Mergin Maps och QField. Inför valet behöver man göra en uppskattning på antalet användare och hur mycket lagringsutrymme man kommer att behöva samt hurdana behov man har kring versionshantering.
Grundfilosofin med öppen källkod medför att man har tillgång till koden och får modifiera den efter eget behov. Därför kan man utgå från koden i QField Cloud eller Mergin Maps Cloud och sätta upp tjänsten själv så att den ingår i den egna organisationens IT-infrastruktur. Då slipper man tänka på månadsavgiften och begränsningar gällande lagringsutrymme, antalet användare och versionshistorik. Innan den egna tjänsten är igång, behöver man satsa på utvecklingen av tjänsten vilket i sin tur förutsätter kompetens, tid och resurser.
QField eller Mergin Maps?
Hur ska man tänka nu när valet står mellan två alternativ? Å ena sidan finns det två GIS-fältapplikationer med lite olika inriktningar och specialfunktioner med var sin kostnadsbild beroende på antalet användare. Båda erbjuder en möjlighet att synkronisera data via molnet medan i QField är synkroniseringen möjlig även med en USB-kabel.
Å andra sidan kan man inte riktigt välja helt fel heller. Både Mergin Maps och QField bygger på öppen källkod och de är QGIS-kompatibla. Båda applikationerna är bra verktyg för mobil insamling av geografiska data.
Mergin Maps har ett mer avskalat användargränssnitt och kan därför kan tröskeln att komma igång med vara låg, särskilt för användare som inte i början behöver vara rutinerade GIS-användare. Små team kan också använda verktyget Work packages i Mergin Maps för att dela data mellan teammedlemmar utan att synkroniseringen riskerar bli fel.
QField erbjuder avancerade digitaliseringsverktyg som man kan använda i fältarbetet. QField är också ett bra val om man behöver hantera stora bildfiler. Vill man använda kostnadsfri synkning med USB-kabel i stället för molntjänster, är QField det rätta valet.
Innan man fattar det slutliga beslutet, är det värt att ta en stund och fundera på antalet framtida användare inom den egna organisation, det generella arbetssättet på kontoret och i fält och hur man vill synkronisera
Vi på Gispo ordnar kurser i QField och Mergin Maps och hjälper också med övriga frågor angående mobil insamling av GIS-data. Ta gärna kontakt med oss på info@gispo.se.
Artikelförfattare: Anni Jusslin
I början av juni hände något historiskt: för första gången någonsin stod Sverige och Norrköping stod som värd för en årlig internationell QGIS användarkonferens. Konferensen sålde slut på rekordtid men drygt 300 deltagare hann boka sin plats. Européer var kraftigt representerade medan den längsta resvägen hade deltagarna från Madagaskar. Men QGIS-konferensen i Norrköping är inte ett minne blott! Alla som vill kan ta del av presentationerna – virtuellt!

Norrköping samlade både nya och erfarna QGIS-användare och utvecklare runt om i världen under fem intensiva dagar. Och föga förvånande var stämningen – i sann Open Source anda – öppen, generös och prestigelös. Arrangörerna från QGIS Sverige användarföreningen hade gjort ett hästjobb och lyckats med råge med både programmet och lokalerna. Och man ska inte glömma det abstrakta men så viktigt: den fina stämningen. Även härligt sommarväder lyckades arrangörerna att ordna i början av juni vilket imponerade på alla skandinaver. Det spekulerades en hel del att SMHI kunde ha haft ett finger med i spelet.

En tumregel för att kunna orientera sig bland olika typer av regionala och internationella konferenser: på en QGIS användarkonferens brukar fokuset ligga på QGIS till skillnad från FOSS4G-konferenser (Free and Open Source Software for Geospatial) som samlar användare och utvecklare av öppen källkod inom GIS med alla sina varianter. Konferenser som dessa kombineras ofta med en särskild utvecklarträff antingen före eller efter konferensdagarna då utvecklare (developers) kan sitta ner tillsammans och fila på källkoden, sk. code sprints.
QGIS var verkligen den gemensamma nämnaren i Norrköping. Det fanns en hel del matnyttigt för alla oavsett hur många månader eller år man hade har bakom sig som QGISare. Presentationerna handlade om olika användningsområden, nya egenskaper i QGIS, kompatibilitet med andra programvaror och idéer om hur man främjar samhörighet och bygger upp långsiktiga gemenskap. Utöver presentationer erbjöd konferensen ett antal workhops så att man kunde vässa sina kunskaper helt konkret.
Team Gispo från Finland och Sverige var med i Norrköping under alla dagar, höll två presentationer, träffade intressanta människor och vi lärde oss massor. Det känns bra när man både kan ge och ta!
- Eemil Haapanen: The Killer Features of QGIS Server
- Pekka Sarkola och Eeva-Maria Viljakainen, Finavia: Using QGIS to Manage Airport Data

Team Gispo: Eemil, Pekka, Mari, Mari och Juho
Vad minns vi bäst?
Det var så mycket bra saker som hände. Men om man nu måste lyfta fram något i nötskal så säger vi: början och slutet. Key Note talare som berättade om visualisering av data och implementering av Open Source på SMHI.
Konferensen inleddes med Key Note Speaker, Anders Ynnerman, professor i vetenskaplig visualisering på Linköpings universitet och direktör på Visualiseringscenter C gjorde ett intryck. Han berättade om det långsiktiva arbetet på mellan Linköpings universitet och campus Norrköping som har resulterat bl a i en digital twin för staden Norrköping men mycket annat också inom genom att visualisera och öka förståelsen av jordklotet, rymden och det mikroskopiska i människan. Lägg termen Wisdome och Geodome på minnet och börja planera nästa resa till Norrköping. Visualiseringscenter C var en av de konferensens organisatörer och dess lokaler, belägna centralt i Norrköping blev en naturlig träffpunkt för deltagarna.
Generellt kan man säga 3D-visualisering var ett av teman som var starkt närvarande under konferensen med tanke på att möjligheterna för 3D fortsätter utvecklas och förbättras för QGIS-användare.

En röd tråd som löpte genom fria samtal och många presentationer var Open Source på frammarsch inom offentlig sektor. Många deltagare från kommunal förvaltning ville veta mer om hur QGIS används inom deras verksamhetsområde. Ett av konferensens föredrag hölls av Eero Hietanen, senior IT-specialist om hur den statliga myndigheten Lantmäteriverket i Finland nu har gått över till öppen källkod vid produktion och underhåll av all terrängdata.
Konferensen sista Key Note Speaker, Rasmus Ewehag, GIS-systemutvecklare på SMHI (och en av konferensens organisatörer), berättade om organisationens resa mot öppen källkod. Arbetet kulminerade under våren 2025 i en övergång proprietär till öppen källkod i all GIS-verksamhet.
Vad lärde man sig?
När fem olika personer från en och samma organisation – i vårt fall Gispo – deltar i en konferens, kammar man hem väldigt olika erfarenheter och lärdomar. Lika fascinerande varje gång. Även om många av oss har deltagit i ett antal olika GIS-konferenser under årens gång var det här för oss alla första gången någonsin på en QGIS användarkonferens.
Juho ja Eemil byggde vidare på sina tidigare kunskaper om QField och QFieldCloud och Eemil fördjupade sig även i den andra applikationen inom mobilt GIS, nämligen Mergin Maps. Båda lärde sig en hel del om QGIS Action. Och Juho fick träffa i verkligheten personer som man samarbetat med virtuellt.
Meri tyckte att det var extra givande med lunchlotteriet. Man fick gå med sin bricka, välja en fri plats (lott!) och hamnade gång på gång bland trevliga, främmande människor och mitt i diskussioner om planering av laddningsstationer för elbilar eller säkerhet inom öppen källkod eller historiska kartornas betydelse i moderna översvämningsanalyser.
Mari minns extra tydligt SMHI:s presentation om resan mot öppen källkod. Idéer och konkreta tips fick hon med sig efter att ha lyssnat på en presentation av QField inom forskning rörande tropiska vattenområden. Och workhoppen om nya verktyg för hantering av punktmoln, utvecklade av Luttra Consulting, var en pärla.

Med tanke på att detta var vår första QGIS användarkonferens var det naturligt att fundera på vad som gör den här konferensen speciell. Pekka tyckte att användarperspektivet väger tungt här både hos talare och lyssnare medan FOSS4G-konferenser (Free and Open Source Software for Geospatial) samlar mer utvecklare.
Hur ser framtiden ut?
Alltid när QGIS Community samlas, pratar man om vägen framåt. Så även denna gång när avslutningssessionen kulminerade i en paneldiskussion på scenen och aktivt deltagande från publiken allt i sann, prestigelös Open Source-anda.

En hel del pratades om användargränssnittet i QGIS och hur det kan förbättras och moderniseras – men vad det sedan innebär är än så länge en öppen fråga. Ska man fortsätta men den klassiska huvudmenyn, är en bred “ribbon” med stora ikoner ett alternativ eller ska man börja röststyra QGIS var frågor som kastades i luften. Det som är säkert är att en ny version av QGIS (4.0 serien) kommer att publiceras i 2026 och övergången till Qt 6 kommer att innebära en hel del förbättringar under motorhuven och påverka vissa plugins.
FME (Feature Manipulation Engine) är en fråga som berör många. Alternativ till FME diskuterades flitigt under paneldiskussionen och input hämtades från publiken. Än så länge verkar det vara svårt att hitta en pusselbit inom Open Source som helt och hållet skulle kunna ersätta FME. Även SMHI som nu övergår till Open Source inom sin GIS-verksamhet behåller en programvara med en proprietär licens: FME. QGIS har dock en modul, Model Designer, som har ett grafiskt användargränssnitt och skulle kunna utvecklas i framtiden för att kunna ersätta funktioner i FME. Slutna dataformat och konverteringar kommer dock fortsätta vara en utmaning.
Utvecklarträffen efter konferensen
Ungefär 50 utvecklare av QGIS stannade kvar i Norrköping efter att själva användarkonferensen var avslutad. Ett antal av de personer som räknas som “usual suspects” i QGIS-kretsar var med i träffen men glädjande nog även nya ansikten. Tanken bakom dessa träffar är att farmför allt främja gemenskap och ge möjlighet för utvecklare som annars ofta jobbar rätt så ensamt i sina kammare att träffas “på riktigt In Real Life”. De där berömda synergieffekterna uppstår ju ibland (!) när man hittar likasinnade och sitter ner tillsammans i små grupper för att prestigelöst diskutera gemensamma problem och idéer. Och tröskeln blir lägre för att ta kontakt på nytt i framtiden, virtuellt eller på nästa träff.
Några sista ord för dagen
I ett nötskal: Norrköping och QGIS användarkonferensen levererade. Oavsett om vilken nivå man befann sig, fick man ta med hem en hel del matnyttigt och minnen från gamla och nya prestigelösa, kloka GIS-vänner.
Många av deltagarna kom från offentliga sektorn och jobbade inom forskning, utbildning och utveckling medan GIS-användare från privata företag var i minoritet. Detta speglades i programmet i Norrköping denna gång. Men fortsättning följer i Schweiz sommaren 2026. Datumen kommer snart. Hoppas att vi ses där!
Årets nybakade QGIS LTR (Long Term Release) är här. Varsågod och njut!
Sedan Prizren 3.34 (LTR 2024) släpptes i februari 2024 har utvecklingen gått vidare. Bratislava 3.40 (LTR 2025) innehåller både nya funktioner och buggfixar som har tillkommit tack vare återkoppling, önskemål och finansiering från QGIS-användare. Allt detta gör LTR-versionen till den bästa tillgängliga versionen av QGIS. Vi rekommenderar därför att man laddar ner och börjar använda den senaste LTR-versionen.
Man får hålla hårt i hatten om man vill hänga med. För att underlätta resan har vi samlat de förändringar som vi tycker är de allra nyttigaste och mest relevanta. Kom ihåg att detta dock endast är ett axplock av godis.
Vill du läsa mer om hur planeringen ser ut och ha koll på när nästa version släpps, så hittar du mer generell info på QGIS.org och tidplaner i Roadmap. Vill du fördjupa dig i uppdateringar som gjorts under 2024 kan du läsa mer här:
- https://changelog.qgis.org/en/qgis/version/3.36/
- https://qgis.org/project/visual-changelogs/visualchangelog338/
- https://changelog.qgis.org/en/qgis/version/3.40/
Förbättringar i användargränssnittet
Man känner sig trygg när QGIS Bratislava 3.40 kör igång. Användargränssnitt ser ut som en gammal vän och man behöver ingen Roadmap för att hitta hem och ut igen. Men några små, fiffiga förbättringar har dock lagts till:
- De ofta använda geobearbetningsverktygen kan markeras som favoriter – behändigt om man råkar glömma bort namnet på det där verktyget som man använde för en liten stund sedan.. Det kan ju hända, särskilt om man kör QGIS både på engelska och svenska.
- Modelldesignern kan köras en del i taget och testas om det fungerar på önskat sätt, dvs. man måste inte längre alltid köra hela modellen
- Uttrycksbyggare (Expression Builder) kan öppnas med “mittenklick” på datormusen.
- När kartobjekt har relationer visas de i panelen Identifieringsresultat när man klickar på objektet med i-verktyget (Identifiera objekt).
- Möjlighet att välja mellan “Skapa databas” och “Skapa databas och lager” har lagts till som alternativ för att underlätta när man arbetar med databaser.
- Kopplingar i Datakällor (Browser) kan dupliceras – nyttigt när man har flera nästan likadana kopplingar. Nu kan man ändra de parametrar som behövs utan att man är tvungen att skapa kopplingen helt från början.
- Ordningen på fälten i attributtabellen kan ändras medan man skapar ett nytt vektorskikt, t.ex. i en GeoPackagefil. Man är alltså inte längre låst i “skapelseordningen”.
- Attributtabeller med många, olika stora fält blir lättare att överblicka tack vare en ny inställning som automatiskt anpassar bredden efter innehållet. Det behövs dock några klickar innan man är framme vid rutan som behöver kryssas i, dvs Inställningar – Alternativ – Datakällor – Anpassa storleken på kolumner.
- I Datakällor (Browser) kan man göra en uppkoppling mot molntjänster, se bild nedan:

Hantering av vektordata
Brister vid hantering av höjdsystem i koordinatreferenssystem har plågat många lantmätare. Men från och med nu är det möjligt att ställa in höjdsystemet för varje vektorskikt (Egenskaper -> Höjd). Därefter fungerar de verktyg som hanterar höjddata, bl. a. 3D-kartvyer, höjdprofiler och i-verktyget (Identifiera objekt) mycket bättre och visar korrekta resultat i z-led.

Familjen Diagram har fått en ny medlem. Sedan lång tid tillbaka har man kunnat skapa ett antal olika typer av diagram när man har velat visualisera vektordata. Nu finns en ny variant som heter “Staplade diagram” och kan användas till exempel vid visualisering av befolkningsstatistik som klassiska befolkningspyramider.

Hantering av rasterdata
En hel del förbättringar har tillkommit för att underlätta hantering av rasterdata. En av dem är möjligheten att filtrera rasterdata och visualisera resultatet dynamiskt med ett nytt, smidigt verktyg. Begreppet filtrering kan leda tankarna till en gul trattsymbol, bekant från filtrering av vektordata men då får man leta länge och förgäves. Ta istället raka vägen till Visa-> Datafiltrering och välj antingen Tids– eller Höjdkontroll, se bild nedan.

Har man höjddata i rasterformat och arbetar med översvämningsanalyser eller till exempel studerar historiska strandlinjer, kan man nu använda funktionen Höjdkontroll och välja vilka höjdnivåer eller intervaller som ska visas på kartan. Genom att flytta på de vita rektangulära spakarna kan man enkelt visualisera en stegvis förändring, se bild nedan.

Om rasterdata istället innehåller temporala (tidsmässiga) värden, kan man använda funktionen Tidskontroll för att skapa en dynamisk visualisering över en händelse i tid. Pixlarna visas när värden ligger inom angiven tidsintervall vilket kan vara vid visualisering av förändringar i tid, till exempel:
- Förändringar i markanvändning
- Utbredning av översvämning
- Transport- och resekostnader (t. ex. GRASS’ r.walk)
En liten godbit är värd att nämna: kopiera stil. En uppskattad funktion i QGIS har ju länge varit möjligheten att kopiera stil från ett vektorskikt och klistra in stilen på ett annat vektorskikt. Nu är kan man göra samma mellan två rasterskikt och även spara inställningarna som en egen stilfil.
Symbologi
Flera uppdateringar och förbättringar har gjorts för verktygen som styr symbologin för punkt-, linje- och polygonskikt.
En intressant nyhet är “Linjär referering” som också skulle kunna heta längdmätning. Man blir alldeles lycklig när man kan välja mellan flera alternativ: intervall räknat som kartesiskt 2D-avstånd, höjdskillnader eller motsvarande (z- respektive m-värden) eller avstånd mellan varje brytpunkt.


Linjeobjekt har fått ett nytt symbollager som saknats av många: “Fylld linje”. Äntligen slipper man trixandet med dubbla linjer, se bild nedan.

Några till nyheter om symbologihantering:
- Punktmoln kan renderas som yta (trianguleras).
- En rasterbild som fyllnad i en polygonsymbol kan justeras i bredd och höjd.
- Ny renderingstyp rasterskikt: “enfärgad”
- Wind Barb (vindriktning) för meshlager för att visualisera ändringar i vindriktning och styrka.
- Intensitetskartans (Heatmap) teckenförklaring visas nu i panelen Lager.
- En enkel punktsymbol kan ritas med en buffert: inställningen finns bakom “Avancerat”, se bild nedan.
Hantering av etiketter
Den eviga resan mot perfekta etiketter fortsätter. Många kommer säkert glädjas åt HTML-stöd för etiketter som nu finns i QGIS.
För övrigt har nya regel lagts till för att förbättra styrningen av automatisk placering av etiketter. Man kan konfigurera dessa regel på fyra olika sätt: dra etiketten mot kartobjekt eller trycka iväg den, trycka iväg etiketten från andra etiketter eller hindra överlappning, se bild nedan.

Etiketter för punktskikt har fått en ny inställning som gör det möjligt att ställa in ett maximalt tillåtet avstånd mellan etiketten och kartobjektet vilket ökar läsbarheten. Inställningen hittar man under tema Placering – Generella inställningar – Läge och kan användas vid både “Kartografisk” och “Runt punkt”.
När man väljer Placering -> Läge -> Kartografisk kan man ytterligare styra etikettens placering med inställningen Positionsprioritet, se bild nedan:

Kartlayout
En liten ändring, önskad av en bred publik, har lagts till i Layouthanteraren. Inställningar för sidegenskaper var tidigare varit en aning undangömda men har flyttats till ett logiskt ställe dvs direkt under Layout på huvudmenyn. Njut en stund innan du börjar ta det för givet, se bild nedan.

Det nya verktyget för datafiltrering i QGIS kartfönster får genomslag även i layoutfönstret. Inställningen finns i Layouthanteraren -> Karta -> Elementegenskaper -> Höjd/Tidsintervall, se bild nedan.

Skalstock är något som behövs i varje karta värt namnet. Nu kan man välja mellan fyra olika metoder för hur kartans skala ska räknas ut, närmare sagt i vilken del av kartan.

Att få vara med och utveckla QGIS är kul!
Tack vare ett samarbetsprojekt med finska Lantmäterimyndigheten har vi fått möjlighet att vara med och bidra till utvecklingen av QGIS, något vi på Gispo är glada och stolta över. Den nya QGIS-versionen har fått tre nya funktioner rörande digitaliseringsverktyg och hantering av attributdata som Gispo har utvecklat.
Attributinformation bevaras när ett kartobjekt delas
När man delar ett kartobjekt i två delar, kommer det större objektet automatiskt att ärva attributvärden. Detta förbättrar hanteringen av kartobjekt och försäkrar att attribut från det ursprungliga objektet alltid bevaras.

Uppdatering av defaultvärden vid hopslagning av objekt
När man vill slå ihop två kartobjekt, uppdateras defaultvärden i attributtabellen omedelbart förutsatt att man har ställt in ett defaultvärde i databasen. Detta effektiviserar arbetsflödet och minskar risken för fel och förbättrar kvaliteten på data.
Tidigare:

Nu:

Brytpunktsverktyg påverkar alla redigerbara skikt
Nu kan man lägga till en brytpunkt på ett segment på ett kartskikt och med samma klick skapa en identisk brytpunkt på alla underliggande skikt som har ett motsvarande segment. Då krävs naturligtvis att de övriga skikten också är i redigeringsläge. Man sparar både tid och risk för topologiska fel minskar.
