[postgis-devel] Regular raster blocking (was: Real extent feature lost after metadata as views)

[Mateusz Loskot]

On 6 December 2012 19:20, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>> Well this is false.. It is not because tiles are of the same size that they cover all
>> the extent without leaving gaps or overlaps.
>>
>> So we might want to replace the second condition (which becomes useless) by:
>>
>> 2) There should be no overlaps or gaps in the global coverage.
>
> The "all upper left corner on the same grid" become useless only if we do not allows gaps...
>
> I'm fine with not allowing gaps but the original definition was allowing missing tiles.
> How is this different from "gaps"?

I differentiate it this way:
1) A missing tile is denoted as NULL in raster column of a tuple.
2) A gap is non-NULL value for a tile, but tile is smaller than grid
cell it occupies
  (it is a local gap, if you like, within context of a coverage cell,
not of global extent).

Missing tiles should be easy to handle in queries with
ST_MakeEmptyRaster of NODATA for pixels NULL tiles.

> This is why I think we should not allow any kind of gaps: gaps created by tiles of the same size aligned on a grid
> larger than the blocksizes and gaps created by missing tiles.
>
> If some tiles become missing (because some application DELETEd it), then regular_blocking becomes false...

I agree the 2) type of gaps shouldn't be allowed.
However, I have no strong opinion on disallowing the 1) missing tiles.
If I remember correctly, we discussed it as storage optimisation in
case there is large
number of NODATA-only tiles, they wouldn't be stored, to avoid waste
of storage space.
If clients can't cope with NULL tiles, they could generate NODATA
tiles on fly adjusting their SQL queries.
But, it may be important to remember such empty tiles wouldn't be
indexed, would they?

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