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

[Mateusz Loskot]

On 30 November 2012 15:07, Bborie Park <dustymugs at gmail.com> wrote:
> [...]
>
> It pads the right-most and bottom tiles.
>
> For example, let us say you have a 100 x 100 raster and you want to
> tile it by 21 x 21...
>
> raster2pgsql -t 21x21 my100x100raster.tif
>
> The loader will create 25 tiles with 9 tiles having padding. When
> tiling, the loader processes from the upper-left corner so the padding
> occurs on the right and bottom edge of the raster.

Yes, here is old post I quickly announced the padding support in the first
loader version, with visual ASCII art included:

http://lists.osgeo.org/pipermail/postgis-devel/2009-May/005629.html

> As for adding more to the serialized format, I'm hesitant to do so at
> this stage.  When are we allowed to make changes to the serialized
> format?  I was under the impression that it had to be a major version
> change.

I have similar concern, but see my pitch below.

> It is on the todo list to be able to prevent tiles from being padded
> (so some tiles will have different width and height) but then this
> would violate the regular blocking rule of all tiles having the same
> width and height.

That's right.

In either case, there is a breakage in backward compatibility,
either on the conceptual side or implementation.

Now, here is my pitch:
The final version of regular blocking specification we worked out was sound,
non-intrusive and easy to understand. It was implemented and worked well.
Making changes to the specification now to catch up (or cover) the regression
due to raster_columns being a view is not a good idea. It would be a change
in PostGIS Raster feature set, confusing to user, making certain important
use-cases impossible or badly perform.
Users would easier accept non-complex technical change in a format
specification, than change in a whole concept and features behaviour.
It is unclear what "at this stage" actually means as PostGIS Raster is a young
project and it's safe to assume it hasn't been widely applied yet by developers
working with it at level of implementing clients. So, I hoped we still have
time to 'break' API backward compatibility. If not know, then when.

> Part of the issue is that when the python loader was in use,
> raster_columns was a table and raster columns only had one constraint
> (SRID).  With raster_columns being a constraint-based view, the extent
> value for each table's raster column is based upon the maximum extent
> constraint.

That's right, that's why I pointed we have overlooked this issue.
There is no way to mkae the views store manually specified
extent, so the only feasible option is to update the serialised format.

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