När man jobbar med GIS så är det väldigt osannolikt att man inte hört talas om formatet ”Shape” för att hantera vektordata.
Men hur många är det som känner till SpatiaLite, mer än bara i förbigående.
I detta inlägg kommer jag att titta lite närmare på formatet och dra några paralleller till ESRI Shape (lanserat tidigt 1990-tal), så får vi se om det går att dra någon slutsats om framtiden för SpatiaLite.
SpatiaLite är för SQLite vad PostGIS är för Postgresql, eller för den delen motsvarigheterna hos Oracle eller Microsoft SQL. Skillnaden är att SpatiaLite inte baseras på ett klient-server förhållande. Hela SQL motorn som behövs är i stället inbäddad i klientapplikationerna och därför behövs det inte någon dedikerad server.
I praktiken så är det en enda binär fil som kan flyttas och kopieras som vilken fil som helst. Fördelen mot shape är uppenbar, då shape består av flera olika filer som måste hanteras tillsammans. Och säga vad man vill om shape, men det är ingen geodatabas.
Stödet för SQLite är kanske inte lika utbrett som shape, men QGIS har haft stöd för det mycket länge och från och med version 10.2 så har även ArcGIS stöd för det. Ett annat av mina favoritprogram professionellt Safe FME har naturligtvis också stöd för formatet och så även Global Mapper.
I QGIS är det lika lätt att skapa ett SpatiaLite lager som det är att skapa shape. Man har dock lite annorlunda valmöjligheter när det gäller exempelvis ”typ” av geometrier.
Skillnaden mellan ”punkt” och ”multipunkt” är att ett objekt med punkt är en enda punkt medan ett objekt av typen multipunkt kan bestå av många punkter.
På torget står det en staty i järn föreställande Gustaf Fröding.
På torget finns 12 st lampor av typen 20W LED, 120grader spridningsvinkel.
De båda objekten ovan representerar i första fallet en punkt och i det andra 12 (multipunkt).
En annan fördel mot shape är att eftersom det är en databas (på riktigt) så är det betydligt enklare att skapa och hantera index med en primärnyckel. Till skillnad från andra populära format som KML och GeoJSON som måste läsas från början till slut så går det att komma åt SpatiaLite-data helt dynamiskt.
I shape så definierar man attributens bredd, exempelvis texter kan vara upp till 254 tecken långa. I SpatiaLite så finns det ingen sådan begränsning. Den övre gränsen för hur mycket som kan lagras i en sträng är som standard satt till 1 miljard bytes (SQLite). Om detta inte räcker så går det dock att ändra… Heltal och decimaltal begränsas av vad som går att beskriva med 64-bitar (1,844674407×10¹⁹).
Någon kan invända att SpatiaLite inte har attributtypen Datum, men då säger jag att ”det har inte shape heller”. I shape så sparas allt som text/tecken, sedan tolkas innehållet som text, heltal, decimaltal och datum. Du kan göra precis samma sak i SpatiaLite. Om du sparar ett datum i ett textattribut (konsekvent) så kommer programmen att kunna tolka innehållet som just datum.
Shapefiler kan lagra maximalt 2 Gb med data, vilket är en begränsning i en del sammanhang. SpatiaLite filer börjar runt 4 Mb, även om de är i princip tomma, men kan svälla nästan hur mycket som helst. Kom ihåg att väldigt mycket av databasfunktionaliteten som normalt finns på en server är inbakad i den binära filen, därför så blir även filer med lite data ganska stora. Om man zippar en SpataLite fil så blir resultatet för små filer under 10% av originalstorleken. Maximalt kan en SpataLite (SQLite) fil lagra 140 Tb data, vilket borde räcka för de flesta behoven.
Att det inte finns någon tydlig definierad gräns för hur mycket data som kan lagras i SpatiaLite har ibland framförts som en begränsning, men som ersättare till shape så borde det inte vara några problem.
Har du hört talas om OGC GeoPackage? Det är i princip SpatiaLite, vilket kan förklara varför såväl ESRI som Safe inkluderat stöd för formatet i sina programvaror. GeoPackage är tänkt att bli ett enhetligt format för utbyte av vektordata och det går att läsa mer om OGC GPKG på OGC hemsida.
Slutsatser
Är då SpatiaLite vektorformatet för framtiden?
Det finns onekligen många fördelar gentemot shape och är det mycket data så går det inte ens att jämföra med populära sekvensiella format som csv, kml, geojson, etc, vilka i sammanhanget inte är kandidater som framtida vektordataformat.
Det finns också brister där en jag berört är de stora filerna även med lite data.
Utöver vad jag beskrivet här så finns det mängder av fördelar (och några nackdelar) när man börjar granska formatet i olika detaljerade sammanhang, standarden är ju trots allt 153 A4 sidor lång.
Jag tror dock att fördelarna överväger nackdelarna med bred marginal så det avgörande blir om marknaden kommer att ta till sig formatet. Att OGC satt sin stämpel på formatet och givit ut en dokumenterad standard för OGC GeoPackage kommer säkert att bidraga till att formatet blir framgångsrikt. Sedan är det ju ingen nackdel att stora kommersiella aktörer som ESRI stödjer formatet.
Jag tror att SpataLite är något att satsa på och jag kommer från och med nu att ha SpatiaLite, och inte Shape, som förval i QGIS när jag skall skapa nya vektordata.
GeoPackage ska onekligen bli intressant att titta närmre på. Känns som att det har stor potential och det ska bli spännande att testa ArcGIS 10.3 för att se om det verkligen är fullständigt stöd för GeoPackage. Om det funkar och inte har några stora nackdelar mot File Geodatabase så tror jag GeoPackage kan komma långt även hos de som normalt enbart använder ESRI-produkter.
Ytterligare en stor nackdel utöver det du nämner om Shape är att den inte kan hantera null-värden för attribut. Ett integer-attribut måste därför alltid ha ett värde vilket kan vara högst frustrerande.