I’ve been playing with some nice amount of pixels using WKT Raster engine recently. Today, I tiled the japan.tif (gdalinfo output is here) using 3 different sizes of tile block. All the work was done using gdal2wktraster.py loader available from WKT Raster repository. Below, I included more interesting numbers which may be helpful for others who will decide to juggle rasters in PostGIS database.
Tiling schemes applied on japan.tif file:
Using natural block size reported by GDAL gives 700 tiles, 14000 x 20 pixels each:
gdal2wktraster.py -r japan.tif -t japan -o japan.sql -k
Using block size 100 x 100 pixels gives 140 x 140 = 19600 tiles:
gdal2wktraster.py -r japan.tif -t japan_100 -o japan_100.sql -k -m 100x100
Using block size 200 x 200 pixels gives 70 x 70 = 4900 tiles:
gdal2wktraster.py -r japan.tif -t japan_100 -o japan_200.sql -k -m 200x200
Sizes of all .sql text files produced are close to 1.2 GB. The timing for gdal2wktarster falls to around 40 minutes on Ubuntu 8.10 (i386) running under VirtualBox 2.with assigned single CPU core of Intel Xeon 3.2 GHz and 1024 MB RAM (host machine: 4 x Intel Xeon 3.2 GHz with 16 GB RAM). psql loads single table in about 6 minutes:
psql -d japan -f japan_100.sql
Interestingly, memory usage during processing WKT Raster by gdal2wktraster.py (Python run-time) seems not high (10-20%) and was on constant level of ~85 MB. However, 100% of CPU power was being eaten. It’s got me interested in comparing these results vector-brother of gdal2wktraster, to the shp2pgsql from PostGIS.
