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

[Mateusz Loskot]

On 6 December 2012 11:45, Sandro Santilli <strk at keybit.net> wrote:
> On Thu, Dec 06, 2012 at 11:26:57AM +0000, Mateusz Loskot wrote:
>> On 3 December 2012 18:27, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>
>> > In this case we would just have to modify the "All loaded tiles have the same width and height" regularly blocked rule for
>> > " All loaded tiles have the same width and height. Right most and bottom tiles can be smaller"
>> > and applications would just have to be able to deal with that fact and the original extent could be preserved (by not padding).
>>
>> That sounds like an acceptable solution.
>> It seems to be similar to what we've discussed with Sandro.
>
> That discussion is still open:
>
> Mateusz :
>>Sandro :
>>>Mateusz :
>>>> Sandro :
>>>> > No, I think it should be allowed everywhere
>>>>
>>>> Then, we no longer discuss blocking in a regular grid.
>>>
>>> It'd be a regular-constrained grid
>>
>> I don't understand what you mean.
>> Constraint how?
>
> These are, I belive, the assumptions a reader might want to
> make once block dimensions are defined:
>
>  - Every tile is in exactly _one_ block
>  - No block contains more than _one_ tile
>
> Need anything more ?

- Tiles have the same size
- Tiles can be missing (implicitly filled with NODATA)

These are the characteristics of different arrangements we've discussed
in the specification(s).

> Why the distinction between internal and rightmost/bottom blocks ?

Your suggestion allows partially missing tiles in the middle of tiled coverage.
List of some possible situations that need to be considered:
Spatial extent for the tiled coverage is calculated, and it represents
a real extent.
Spatial extent of partial tile in the middle of coverage is smaller
than extent of coverage grid cell,
leaves gap in extent. Gap in extent is different to gap in data.
If partial tiles are allowed, one may ask why larger tiles shouldn't be and it
raises question about relevance of the overlapping constraint.

Pierre's suggestion, which I described max_blocksize_x, seems to be reasonable
and intuitive specification yet doesn't leave too much room for interpretation.
Less room for interpretation should also work well for better interoperability..

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