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

[Bborie Park]

On Fri, Nov 30, 2012 at 8:51 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 30, 2012 at 08:43:36AM -0800, Bborie Park wrote:
>> On Fri, Nov 30, 2012 at 8:34 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
>
>> > If it is possible, then storing the two hard-coded float-point numbers
>> > of real spatial extent of the whole raster table coverage would do the trick,
>> > and without touching headers of individual rasters in rows.
>>
>> We could do that and thus behave like the regular_blocking constraint
>> which does no actual constraining.  Though I'd rather just store the
>> "true" data extent as a geometry instead of having to compute it from
>> numbers.
>
> +1
>
>> All this can be done for 2.1.  I don't believe this can be done for
>> 2.0 as it would be introducing 3 new constraint management functions
>> and modifications to AddRasterConstraints() and
>> DropRasterConstraints().
>
> Maybe there could be a couple new functions instead of modifications
> of the two existing ones. But I still don't understand how it worked
> before the regression was introduced. How did the original extent ever
> get into raster_columns ? Didn't raster2pgsql take care of that ?
>

The original extent was computed by unioning the tiles' convex hulls
when adding that constraint. raster2pgsql just added the necessary
calls to AddRasterConstraints().

For each raster constraint (or set for scale) I have three non-user
helper functions

add constraint
drop constraint
get info from constraint

Above those helper functions are AddRasterConstraints() and
DropRasterConstraints() for use by end users.

Thinking more about it, I won't add this "data_extent" constraint to
AddRasterConstraints() but have all the underlying functions since it
requires additional info that only a loader or manual entry by user
would have easy access to.

-bborie