Eigentlich habe ich mich immer gescheut, Rasterdaten in einer Datenbank zu halten. Was sollte das im “normalen” Betrieb bringen. Hochoptimierte Rasterdaten im Filesystem waren ja auch ok. Trotzdem, irgendwas kribbelte, man sollte es wenigstens mal testen. Immerhin könnte es den Filesystem-Mount sparen (erst recht in verschiedenen Netzwerke und Domains) und man kann auch Rasterdaten via SQL abfragen und ggf. verändern. Klingt dann doch gut, musste ich testen. Und das hab ich dann getan:

1. Mit QGIS aus Dutzenden von Kacheln mit “Raster / Sonstiges / Virtuelles Raster generieren …” ein VRT bilden (Tipp vom Kollegen, nachdem ich mit raster2pgsql mit -d und -a nicht wirklich glücklich wurde)
2. dann raster2pgsql (GDAL) auf die VRT-Datei
3. psql mit der *.sql-Datei und ab in die Datenbank

z. B. so:

raster2pgsql -s 25832 -b 1,2,3 -N 0 -I -l 2,4,8,16,32,64 -d -M ./alle.vrt -C -r -F raster_hal.2020 -t 256x256 >temp_start.sql

psql -d mikee. -f ./temp_start.sql

Ausgeführt und die Ergebnisse sind wirklich bemerkenswert, nur noch ein Connect zur Datenbank, den brauche ich für die Vektordaten sowieso, kein Netzlaufwerk mehr nötig, Performance 1A, siehe [1]!

Nachteil momentan: die DB-ist noch ziemlich groß. Tests mit (meinen) hochkomprimierten Daten schlugen fehl [2]. Das Verhältnis von Roh- zu komprimierten Daten ist momentan 7:1 (14 GByte vs. 2 GByte) Wer also Tipps hat, gern in den Kommentaren oder auf der Liste [2], ich warte drauf, oder jage ich einem Phantom hinterher 😉

[1] … https://www.youtube.com/watch?v=NUkigcBTkfY&feature=youtu.be&vq=hd1080p60
[2] … https://lists.fossgis.de/pipermail/fossgis-talk-liste/2021-February/011086.html
[3] … https://postgis.net/docs/using_raster_dataman.html
[4] … https://gdal.org/drivers/raster/postgisraster.html
[5] … https://digibib.hs-nb.de/file/dbhsnb_thesis_0000002241/dbhsnb_derivate_0000002867/Bachelorarbeit-Kaselow-2019.pdf