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

Bborie Park dustymugs at gmail.com
Fri Nov 30 08:24:07 PST 2012

On Fri, Nov 30, 2012 at 8:16 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 30, 2012 at 08:07:57AM -0800, Bborie Park wrote:
>> >
>> > Couldn't (or doesn't) a constraint contain the original extent ?
>> > The same information that you would have put into the raster_column field.
>> >
>> It could be done as a constraint... a constraint that does not enforce
>> anything.  The problem with constraints that don't enforce anything is
>> that they're static and may go out of date...
> It could also constraint: all raster tiles  must be covered bu that extent.
>> There are a whole set of constraints present...
>> srid
>> extent
> ^^^ so there's one already ?

Yes. This is a constraint enforcing that all tiles are within the
maximum extent for the table. A "true" data extent constraint would be
something else though that would be hard to enforce due to probable
performance issues.

>> width/height
>> scaleX/scaleY
>> skewX/skewY
>> alignment
>> number of bands
>> pixel type of each band
>> in-db/out-db of each band
>> The proposed addition of attributes is the correct solution but when
>> can we implement said solution?  Can we take advantage of the
>> "version" variable in the serialized raster to make a change,
>> particularly if we maintain support for prior versions?
> You mean the change in the serialized value ? Really ?
> 16*2 bits enforced on all values for a "corner" case ?

You're correct to question whether or not this is even worth making a
serialized format change.  I'd much rather see a format change for
ticket #2111.

You can minimize (or in some cases eliminate) the amount of padding
that is done by wisely using tile sizes that leave little or no
remainder (raster width / tile width or raster height / tile height).


More information about the postgis-devel mailing list