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

Mateusz Loskot mateusz at loskot.net
Fri Nov 30 09:02:24 PST 2012

On 30 November 2012 16:51, 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 ?

Yes, it would take care of that.

1) It simply read extent of the source raster from GDAL, raster2pgsql.py:859
2) Then, it wrote the extent to raster_columns intact, raster2pgsql.py:860
3) Finally, for every tiles it read from GDAL, it calculated a) if
padding is necessary
and b) how much padding to add, then c) it burned some padding with NODATA,
and eventually d) wrote padded tiles

So, the 1+2 step was independent to 3 step.

Currently, the step 1+2 is gone, instead the extent is calculated on-fly
for whatever is written in 3 step.

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

More information about the postgis-devel mailing list