Är ”COG” verkligen så bra, egentligen…

Rasterdata i GIS kan hanteras i många format. Det finns också lika många åsikter om dem som det finns format tillgängliga. Oavsett om man använder öppen källkod som QGIS eller kommerciell mjukvara som ArcGIS Pro, så hanteras rasterdata i mycket stor utsträckning av GDAL.

För många så är antagligen GeoTIFF ett naturligt val, bara för att man brukar använda detta format. För andra så vill man ha raster tiles som rådata (x, y, z tiles) eller i SQLite (MbTiles eller GPKG). Det finns sedan så många fler format som dessutom kan kombineras med komprimering och översikter (pyramider) för att förbättra upplevelsen av dessa data.

På senare tid så har ett ”nytt” format dykt upp, nämligen Cloud Optimized GeoTiff (COG). COG bygger dels på GeoTiff formatets möjligheter att strukturera lagringen av data internt på olika sätt, och dels på HTTP GET kommandon för att ”hämta” endast de data som behövs från en webbserver.

COG är strukturellt vanliga GeoTiff och mjukvara som inte stödjer COG hanterar dessa filer som vanliga GeoTiff. Men program och tjänster som stödjer COG, inte minst i webbapplikationer, kan optimera hanteringen på ett effektivt sätt.

Huruvida COG är lämpligt eller ej i olika tillämpningar, eller om det är det bästa alternativet får var och en själv bestämma, men jag är nyfiken på formatet i sig. Vad är egentligen COG i praktiken. Och hur står det sig mot raster i GeoPackage.

För att undersöka närmare så börjar jag med lite rasterdata från Lantmäteriets öppna data.

Jag hämtar ett antal rasterrutor i 1:50’000 och tacksamt nog så innehåller paketet GeoTiff samt VRT fil för att underlätta visning i såväl QGIS som ArcGIS Pro. Jag börjar helt enkelt med att lägga till dessa data i QGIS för att få en känsla för hur dessa data fungerar.

Visst, kartan visas, men det är väldigt långsamt. Det jag tidigare gjort för att snabba upp hanteringen har varit att spara om till GeoPackage med inbyggda pyramider. Det betyder en snabb visning, men data är komprimerat med JPG och PNG, vilket är ”förstörande” komprimering. Med COG (och GeoTiff) så kan man exempelvis använda LZW komprimering som är en ”icke förstörande” komprimering. På senare tid, och inte minst i webb-samanhang så har formatet WEBP seglat upp som alternativ. Likt JPG så är det en förstörande komprimering, men om man sätter ”QUALITY” till 100% så är det ett ”loss-less mode”. Med GDAL så kan man konvertera raster till COG med WEBP komprimering, så det tänker jag prova.

-co COMPRESS=WEBP
-co QUALITY=100

Med kommandot gdal_translate så görs många inställningar som standard. Dessa kan vara bra att känna till, om man exempelvis använder olika metoder för konvertering. Med GDAL så är följande inställningar standard, kopplat till konvertering till COG:

-co BLOCKSIZE=512
-co BIGTIFF=IF_NEEDED
-co OVERVIEWS=AUTO
-co RESAMPLING=NEAREST eller CUBIC (för pyramider om det är diskreta data eller inte)

Det finns fler standardinställningar, men de ovan kan vara av speciellt intresse. Jag tänker inte ändra dessa, men det kan vara på sin plats att redovisa dem. Inte minst inställningen för BIGTIFF är viktig, om man tror att den resulterande filen kommer att bli större än 4 Gb. IF_NEEDED fungerar nämligen inte för data som är komprimerade. Det finns inställningar som jag kommer prova att ändra och detta omfattar bland annat hur många trådar som datorn använder för att konvertera filerna.

-co NUM_THREADS=ALL_CPUS

Standard är att alla beräkningar görs i ”main thread” men med ALL_CPUS så kommer alla resurser att användas i de steg i bearbetningen som stödjer multithreading. I exemplet här så tog bearbetningen med en CPU 33 minuter och med ALL_CPUS tog det knappt 12 minuter. Olika delar av processen tjänade mer på flera trådar än andra, så det var inte en generell förbättring över hela tiden. De resulterande filerna var sedan identiska, så i slutändan så gjorde det inte någon skillnad.

gdal_translate mosaik.vrt skane.cog.tif -of COG -co NUM_THREADS=ALL_CPUS -co COMPRESS=WEBP -co QUALITY=100

I slutändan så är resultatet riktigt bra i QGIS. Det går snabbt och upplevs väldigt följsamt när man arbetar med dessa data.

För att jämföra ytterligare så konverterar jag också till GeoPackage med inbyggda pyramider. För att inte favorera något så väljer jag -co QUALITY=100 så att komprimeringen är så nära icke-förstörande som möjligt. Resultatet i QGIS när det gäller upplevelsen är väldigt snarlik och jag har svårt att märka någon skillnad mellan COG och GPKG. Bakom kulisserna så är det sedan skillnader. GPKG filen är 700 Mb jämfört med 500 Mb för COG, men om jag bara sätter QUALITY=75 så blir GPKG filen runt 250 Mb, men redan för QUALITY=95 så krymper storleken till under 500 Mb. Om man har data som kan komprimeras så kan man laborera lite med dessa inställningar.

Den största skillnaden är i den tid det tar att konvertera från VRT. Att använda GDAL för att generera GeoPackage från VRT tog ganska exakt 1 minut, och då är tiden för att bygga pyramider inräknat!

När COG och GeoPackage hämtas från en HTTP URL så fungerar dessa precis som utlovat. Ja, GeoPackage fungerar faktiskt lite bättre i mitt tycke. Som filkälla så fungerar COG lika bra, men jag är inte helt säker på att det är den bästa lösningen i alla situationer. Om man däremot är bekväm med både COG och GeoPackage, och har någorlunda koll på för- och nackdelar, så är båda dessa alldeles utmärkta alternativ för rasterdata.

Stödet för COG varierar, men generellt så är det omfattande i program som QGIS, men för ArcGIS Pro så får man gå lite omvägar för att dra nytta av alla fördelar. Ett sätt, som jag inte provat, är att tvinga ArcGIS Pro att använda GDAL genom att peka på COG filerna i en VRT fil, som gör att ArcGIS Pro använder GDAL och inte inbyggda rasterhanterare (som inte förstår COG som något annat än vanlig GeoTiff). För portalen i ArcGIS Enterprise så finns det vad jag känner till vare sig stöd för COG eller VRT… För raster data i ArcGIS Pro så kan GPKG vara ett bättre alternativ då dessa fungerar alldeles utmärkt… så länge det är trebandsraster och inte diskreta data (med färgpalett) eller enkelband i gråskala.