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

[Mateusz Loskot]

On 6 December 2012 16:40, Pierre Racine <Pierre.Racine at sbf.ulaval.ca> wrote:
>> > 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 ?
>
> These two are already taken care by other existing constraints:
>
> -"Every tile is in exactly _one_ block" is implied by the fact that each tile has its UL corner on the block grid AND no tile can be larger than max_blocksize_x AND no tile can be taller than  max_blocksize_y. Actually I propose to make it even more restrictive. See below.
>
> -"No block contains more than _one_ tile" is implied by the fact that "All tiles must be non-overlapping"

I agree.

>> 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..
>
> I would actually make it more restrictive removing the possibility to accept smaller tiles anywhere:
>
> " All loaded tiles have the same width and height. Right-most tiles can have their width smaller than max_blocksize_x and bottom tiles can have their height smaller than max_blocksize_y. Only the right-most, bottom tile of a coverage can have its width smaller than max_blocksize_x AND its height smaller than max_blocksize_y ".

I agree on that, sounds perfect.

> Why not accept smaller tiles anywhere? Because then the concept of regularly blocked becomes so loose that it gradually lose most of its meaning.

That's right.

> Where is the last effective definition of "regularly tiled" so we build a "definitive", unambiguous definition. Is it the one in http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationFinal01 ?

I think that is the one we agreed on after first round of discussions.
Then, post-beta and pre-release changes resulted in this
http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking02
but I'm not sure how up to date is this one.
For example, it says "the constraint is purely information", where
in the current manual for PostGIS 2.0 we have included plans for real
constraint in future.

> I must say that I'm more open to the concept of regularly blocking now that it is in an automatically generated constraint-based view. Hopefully we are fixing the last inconsistency.

I'm glad about the outcome too.

> To answer the question: "What about the constraints planned for the regular blocking mode? Are we going to keep this plan up?"
> I would not see the point of removing it if we spend so much effort to define it if this was your question.

Yes, I agree. That's what I aimed to confirm.

> If your question is "Are we going to make it a dynamic constraint - or properly constraint it?"
> I guess yes as this will be possible as soon as we have the proper functions.

And that is what I aimed to confirm too, so both answers answer my
both questions.

> Are we going to beat the record for the longest thread?

At least, we have a chance :)

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