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

[Pierre Racine]

>> How does it care?
>> Otherwise than setting regular_blocking to true?
>
>Through constraints set by AddRasterBlocking.
>It should work (not yet fully implemented) in similar way as PostGIS
>and GEOMETRY_COLUMNS restrict geometries to have common srid.

ok

>> Raster functions do not have a clue about the global relative structure
>> of a table of tile.
>
>They don't need to. We have metadata. RT functions are just tools
>used to enforce/assure some restrictions in some use cases.

ok

>> From my point of view, regular_blocking is just a flag telling
>> applications "he! this table is almost perfect and structured that way
>> (like a tiff file!), so you can take advantage of it... if you can..."
>
>No, RB is not just a flag. It's a flag + db-side infrastructure
>like metadata and constraints.

ok

>> Otherwise an application should load one tile at a time (using a proper
>> SQL query) as it does for a vector feature table. It is still not clear
>> to me how an application can really take advantage of regular blocking.
>> The way you access tiles in a database is very different than the way
>> you access tiles in a file.
>
>Basic one is similar to why Web Mapping uses tiles, simpler and faster
>rendering.

I agree that applications benefit from tiling but how do they benefit from regular blocking? Tiling and regular blocking are two different things. I understand that they come together in most image files format but this is a limitative constraint that we most go beyond to implement efficient not-necessarily-rectangular-coverage, one-image-per-row and vector-to-raster-conversion. WKT Raster is not just a file format, it is a class implementing raster/vector processing services. To efficiently implement these service we had to go beyond regular blocking constraints. Hence an application can not necessarily expect regular blocking. It would be nice but not very efficient in many cases.

>> Then, wasn't adding the -k option a bit reinventing the wheel?
>
>Yes, sort of, but the whole processing behind -k is based
>properties deducible automatically, so there is no need for
>user to input any parameters just -k.
>IOW, the whole process is automated.
>
>> You could have used gdal_retile.py to create a bunch of filesystem tiles
>> and import them with the wilcard. This is what I did when I first
>> imported my 3600 100x100 tiles three weeks ago.
>
>Note, that -k uses size of "natural" block which is provided by GDAL.

What are these "sizes of "natural" block"? If an image is not internally tiled, does GDAL retile it to "natural blocks"? "Natural" for GDAL is not necessarily "natural" for my purpose depending if I an building a desktop application, a web application or merely using WKT Raster to do vector/raster analysis (I can do amazing things with PostGIS that I can't do with ArcGIS. PostGIS is fast and handle very big datasets). I will probably want to retile my datasets to different tiles size until I find the size that make threatment as fast as it can be. ...like you save your JPEG files to a certain quality until you are happy with the way they look and the spead they download. For the moment I have no idea what will be the "best" tile size for my application.

Pierre