| | 287 | All these arrangements are possible, and as for a geometry layer which can be implicitly topological or not, PostGIS WKT Raster does not impose one over the other (even though types c) and d) and f) are the most practical for a GIS analyst). The fact that users of a database might (contrary to a raster file format) add or delete rows (or “tiles”) in a table, along with the fact that we must support variable-sized tiles (for vector to raster conversion), makes it very difficult to enforce a certain type of configuration. |
| | 288 | |
| | 289 | '''Regularly Blocked Table''' |
| | 290 | |
| | 291 | You can inform PostGIS that the raster layer you are loading meets certain useful criteria by adding the –k option to the gdal2wktraster.py Python loader. This will set the "regular_blocking" attribute of the raster_columns table to true. It implies that: |
| | 292 | |
| | 293 | 1. All loaded tiles have the same width and height, |
| | 294 | 2. All tiles do not overlap and their upper left corners follow a regular block grid, |
| | 295 | 3. The global extent of the layer is rectangular and not rotated. |
| | 296 | |
| | 297 | Some blocks (or tiles) can be missing in a regularly blocked table. Missing tiles are assumed to be filled with the proper nodata value for each band as determined in the raster_columns table. |
| | 298 | |
| | 299 | This regular tiling (or regular blocking) is expected from arrangements c) d) and e) in figure 1. PostGIS WKT Raster provides this mechanism because raster applications are often optimized to deal with these arrangements. There is, however, no mechanism to enforce (constrain) these criteria and, as mentioned above, adding, modifying or deleting a row from the table might break this regular blocking, and the regular_blocking attribute will not be automatically updated. |
