Då har jag kunnat använda min egen blogg för ett av syftena med den. Jag har nyligen byggt en ny dator och då skulle såklart PostGIS installeras. Det i sig finns dokumenterat på bloggen med allt man behöver exempelvis för att skapa ett dedikerat tablespace på en separat disk. Kommandon för hur man läser in rasterdata i PostGIS kunde också användas för att snabbt få igång servern som jag vill ha den.
Jag fick en del tips under arbetet, och gjorde en del förändringar, och detta handlar detta inlägg om.
Optimera för snabbhet
Datorn har en AMD CPU med 12/24 kärnor och rejält med Ram och en extremt snabb NVMe disk. I och med att jag ersätter en tidigare dator så fick jag dessutom ett par traditionella SSD diskar över som jag satte upp som MD/RAID 0. Den enheten monterades direkt i roten av datorn via fstab för att helt användas för PostGIS installationen. Jag hade tänkt att använda disken till lite mera, men PostGIS tablespace visade sig behöva finnas på enheter som är direkt i roten, så det enkla valet var att använda hela disken till PostGIS och inget annat.
$ sudo chown postgres:postgres /ssd_raid $ sudo -u postgres psql postgres=# create tablespace ts location '/ssd_raid'; postgres=# create database geodata with tablespace = ts; postgres=# \q $ sudo -u postgres psql -d geodata geodata=# create extension postgis; geodata=# create extension postgis_raster; geodata=# \q
Ovanstående kommandon utgår från att PostGIS redan är installerat och att pg_hba.conf samt postgresql.conf är grundkonfigurerade (sök bland tidigare inlägg).
När jag läst in vektordata så var jag inte speciellt imponerad av prestanda på servern, tills jag insåg att jag inte hade några spatiala index i mina lager. När dessa väl var byggda så gick allt ruggigt snabbt.
Jag fick även tipset att optimera serverns inställningar för att anpassas till datorns prestanda. Via https://pgtune.leopard.in.ua/#/ så kan man mata in värden för den hårdvara och det syfte man har med servern, och få optimeringsförslag som man sedan kan redigera i postgresql.conf eller så genereras ett SQL skript som kan köras mot servern som lägger till inställningarna ”ovanpå” inställningarna i konfigurationsfilen.
Jag märkte inte någon enorm skillnad efter denna optimering, mer än att fläkten i datorn jobbade lite mer, vilket är ett tecken på att saker faktiskt går lite fortare.
Ytterligare ett tips jag ännu inte testat är att klustra efter spatialat index. Detta innebär att data ordnas i samma ordning som indexet är ordnat. Att hitta data går snabbt med ett spatialt index, men om de data som skall hämtas är utspridda på en disk så är det inte optimalt. Jag inbillar mig att detta framför allt påverkar databaser med mekaniska diskar och inte i lika stor utsträckning SSD.
För att bygga dessa kluster använder man ST_GeoHash som i sig kräver data i EPSG:4326, men det skall enligt utsago gå att skapa kluster med on-the-fly ST_Transform så att man kan behålla originalgeometrin i geometrikolumnen.
Jag har som sagt inte testat klustring av data, men jag kan tänka mig att det är en bra idé framför allt om man lagrar data på mekaniska diskar.
Raster i PostGIS
Även detta har jag som sagt skrivit om tidigare, men nu gjorde jag en del justeringar, så det var dags att uppdatera bloggen.
QGIS är inte lika bra på att hantera raster i PostGis som vektordata. Att ladda raster till PostGis får man exempelvis göra med ett terminalkommando och inte via GUI i QGIS. Anledningen till detta är antagligen att nuvarande GDAL endast kan läsa PostGIS raster. Det första man behöver göra är att lägga till raster som extension i PostGIS, om man inte redan gjort det när man skapade databasen.
$ psql -U postgres -d databas databas=# CREATE EXTENSION postgis_raster;
Sedan använder man raster2pgsql för att ladda rasterdata från terminalen. Som tidigare så måste det schema som man vill lägga in rasterdata i existera innan man kör kommandot nedan. Jämfört med tidigare lägger jag nu även till pyramider vid inläsningen av raster, och några ytterligare justeringar. Kommandot som utförs från katalogen där alla mina *.tif filer finns blir då:
$ raster2pgsql -d -C -t 512x512 -s 3006 -I -l 2,4,8,16 *.tif schema.tabell | psql -U användare -d databas -h localhost -p 5432
I den första delen skapas ett sql kommando där -d ”droppar” tabellen om den redan finns. -C är en kontroll av att data registreras korrekt och -I bygger index. Det som jag lagt till den här gången är -l med de nivåer som det skall byggas pyramider för, samt -t som anger hur stora ”tiles” som skall skapas. Jag har även provat att lägga till -Y som istället för INSERT använder COPY för att lägga in data, vilket går snabbare framför allt när man har mycket data.
Den andra delen tar den genererade sql strängen och applicerar den på den utpekade databasen med psql kommandot.
Hantera PostGis raster i QGIS
Även inläsning ar PostGIS raster i QGIS är lite problematiskt. Det går exempelvis inte att lägga till PostGIS raster från ”Browser”, det måste man göra från ”DB Manager”.
Om man läst in raster med indexerade färger, så behöver man även fixa färgerna. Det kan man göra genom att kopiera stilen från en originalfil till PosgGis lagret. Stilen kan man sedan spara som ”standard” i datakällan, vilket gör att färger visas korrekt i QGIS senare. Vill man kunna använda raster även i andra tillämpningar än QGIS, då får man göra om rasterfilerna till 3-band 8-bit i stället. Precis som är standard i GeoPackage.
Efter att bara ha använt raster i PostGIS ett kort tag så vet jag inte direkt om det finns så många fördelar med det när man är få användare. PostGIS med vektordata är en helt annan sak då man kan använda ST-kommandon för att bearbeta och manipulera dessa data otroligt mycket. Hur omfattande man kan använda ST-kommandon för raster har jag ännu inte hunnit kontrollera. Är man många som skall komma åt rasterdata så kan jag tänka mig att det finns fördelar med PostGIS raster, men är man själv så tycker jag att raster i GeoPackage är enklare och mera integrerat i QGIS.