[postgis-devel] [PostGIS] #2122: [raster] Real extent feature lost after metadata as views

[Mateusz Loskot]

On 1 December 2012 16:03, Sandro Santilli <strk at keybit.net> wrote:
> On Sat, Dec 01, 2012 at 12:20:13AM +0000, Mateusz Loskot wrote:
>
>> Blocking is a generic technique, almost equally important
>> as pyramids. We can't simply ignore it.
>
> Sorry if I ask it again (I think I didn't get an answer to that):
> is padding _necessary_ to implement "blocking" ?
>
> In other words, is it really a problem if tiles exist which are
> _smaller_ than the "official" tile size ? Why do you need NODATA
> values rather than just NO values at all ?
>
> I'm probably missing something but really can't see that need.
>
> I'm trying to understand this because having no padding at all
> would solve the issue, in that the computed extent could be same
> as the original extent...

If padding is not necessary, it would make blocksize_x|y actually
represent max_blocksize_x|y, where smaller block sizes are allowed.
Despite technically possible tohandle, it would complicate things though.
Is actual blocksize < max_blocksize_x|y allowed only along the right and
the bottom edge?

GDAL requires the same blocksize for all tiles in a GDALRasterBand

http://www.gdal.org/classGDALRasterBand.html#af2ee6fa0f675d7d52bc19f826d161ad6

I doubt it's possible for GDAL to cope with mixed blocksize.

In GDAL driver for PostGIS Raster, there is currently an explicit check
that the "blocks" all have the same size, to imply regular blocking:

http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L561

If mixed tile sizes are detected then the block size is never set,
and GDAL assumes a blocksize of overall width of raster tiles * 1 row.
Querying this could be woefully slow.

http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/postgisraster/postgisrasterdataset.cpp#L637

The padding is a technique that was introduced to fulfil requirement of regular
grid without gaps, teeth or any kind of irregularities.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net