[postgis-devel] [WKT Raster] Regular blocking in gdal2wktraster.py

[Pierre Racine]

Hi Chris, Thanks for your inputs.

>I would say that there is no good reason to create the smaller tiles.
>Space is the only reason I can imagine, and the tile size should already
>be small enough that relative to the overall data, the wasted space on
>the edges is not significant.

I might want to create smaller tiles because:

-the size of my source images do not fit the blocking size I want in the DB  AND
-I will afterward want to append more tiles that would overlap if I fill small tiles with nodatavalues AND
-my application does not care about regular blocking

>If you do create small tiles, then it creates additional problems when
>you later want to add to your raster with another image file ... either
>the smaller bits stay there and throw off the relative tiling of the
>next pieces, 

No, since every tiles is georeferenced. The next image tiles will not throw off anything.

or you must remove the existing little tiles and copy their
>data to larger "regular size" tiles in order to append to the raster.

This is just if you need to stick to regular blocking.

>My feeling is there there is no reason to support non-regular blocking
>within the database, but instead we should support loading the database
>from non-regular (and possibly overlapping) tiles, forcing regularity
>within the database. The raster is defined to have a fixed blocking
>grid, and in order to put things into the database they must be re-tiled
>according to this grid.

In WKT raster each row is an independent raster (contrary to Oracle GeoRaster). We support non-regular blocking (i.e. variable-size tiles) to efficiently rasterize geometry columns (one feature = one raster) and easily implement vector/raster operations. We also have constraints to ensure regular blocking in case users need it. We support both worlds because both worlds have pros and cons for specific applications.

>While I recognize that the database itself cannot use the regular
>blocking to optimize its access to the data, external applications which
>are aware of the fact that the data is stored regularly within the
>database CAN optimize, by requesting data in chunks that match the db
>storage. Depending on the level of the application, it could ask the DB
>to crop the tiles and give it a single raster for the entire region of
>interest, or it could ask the DB for all of the tiles that overlap the
>region of interest... and perhaps cache them within the application, or
>align it's own internal blocking with the DB's.

From my point of view regular blocking is optional. It is a specific way of a more general way to store tiles. Does applications like Google Earth profit from regular blocking? Why is it better to query for regular blocked tiles in chunks than just querying for tiles with a proper SQL query and display them as independent raster forming a layer? This is the way vector layer works and nobody complains.

Pierre