QGIS och GeoPackage är en fantastisk kombination. Vektordata, och i viss utsträckning rasterdata, hanteras extremt enkelt i GeoPackage med QGIS. Har man en blandad GIS-miljö så kan även senare versioner av ArcGIS läsa GeoPackage utan större problem. Men QGIS är fortfarande kung!
QGIS har även funktioner för att bygga ut GeoPackage och göra formatet än mera användbart. Du kan exempelvis lagra mängder med stilar i en dedikerad tabell i databasen, vilket gör att alla stilinställningar följer med när man distribuerar datalagren. Standardstilarna i QGIS är extremt anpassningsbara, men om man vill ha skräddarsydda SVG symboler så kan även dessa bakas in och skickas med stilarna i geopackagefilen.
Detta är inte allt. Det går även att spara hela projekt i geopackagefilen. Detta betyder att projektinställningar också kan distribueras i paketet. Detta inkluderar exempelvis layouter för utskrift, rapporter, relationer, variabler, metadata med mycket mera.
Det går även att inkludera inställningar för QGIS Server om man vill att projektet skall publiceras som OGC-tjänst.
Om man väljer att associera *.gpkg med QGIS så får man direkt en fråga vilka lager man vill öppna, och här börjar vi komma in på sådant som skulle kunna göra geopackage i QGIS ännu bättre…
Om det exempelvis finns projekt i filen, så skulle det vara super om dessa också listades som startbara alternativ när man dubbelklickar på ett GeoPackage. Man skulle även kunna göra inställningar i QGIS så att projektfiler i GeoPackage öppnas som standard, om det finns ett projekt i filen. GeoPackage blir då en typ av ”projektpaket” för QGIS.
En funktion som skulle kunna bli bättre är ”Auxiliary Storage”. Det är här man sparar information om data i ett enskilt lager. Exempelvis anpassade etiketter, vilket fungerar väldigt bra. Men tänk på möjligheterna om man även hade aux-storage på projektnivå. Då skulle man kunna skicka med i princip vad som helst med projektet.
- Dokumentation för projektet (utöver metadata).
- Anpassade Pythonfunktioner*.
- Använda typsnitt.
- Anpassade stilbibliotek.
- Bildfiler, texturer och andra media.
- Med mera…
Det finns ett verktyg i QGIS för att paketera lager i ett GeoPackage, men det hade med tanke på ovanstående också varit bra med ett kommando för att paketera ett ”projekt”, inklusive data i ett och samma GeoPackage. Om det finns resurser som används, som inte kan skickas med i filen så bör man få en varning om det (om möjligt).
Är då inte allt detta utom standarden för GeoPackage? Inte alls! Även om man packar en GPKG full med extra tabeller som bara QGIS förstår, så kan man fortfarande hantera datatabellerna i andra program, exempelvis ArcGIS.
GeoPackage är så vida långt framför exempelvis Esri SHP att det bara finns en enda sak som gör att SHP fortfarande används omfattande i praktiken, nämligen att de stora programmen, som ArcGIS, fortfarande inte låter dig skapa och redigera data i geopackageformatet. Jag kan tänka mig att detta är ett affärsmässigt beslut, men ju bättre QGIS blir, desto fler ArcGIS användare kommer att överväga ett byte, och då är stödet för GeoPackage i och för sig bara en del i det övervägandet, men jag tror faktiskt att Esri förlorar ännu mera på att inte erkänna att GeoPackage är det enda rimliga geodataformatet för framtiden. Argumentet att GeoPackage inte passar i ”plattformen” som helhet utan att egna specialpaket är bättre, är ganska ihåligt när man ser vad QGIS gjort för att anpassa formatet till det egna behovet.
*) Det går att skicka med anpassade pythonuttryck (custom expressions) via projektfilens makrofunktioner. Detta kräver dock lite extra kodarbete och ganska många genade kurvor.
(Observera att fördelarna med GeoPackage framför allt gäller vektordata. Rasterdata är fortfarande bättre att hantera i filbaserade format, åtminstone så länge man pratar om stora datamängder och korrekt valda format, och inte gigantiska relationsdatabaser eller små datamängder där prestanda spelar mindre roll. Men det är ett ämne för ett annat inlägg.)