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

Bborie Park dustymugs at gmail.com
Fri Nov 30 09:06:02 PST 2012

On Fri, Nov 30, 2012 at 9:02 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
> 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
> Sweet!
>>> 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
> http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/python/raster2pgsql.py#L859
> 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
> http://trac.osgeo.org/postgis/browser/trunk/raster/scripts/python/raster2pgsql.py#L772
> 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.

Information for constraints should always be calculated in the
database when possible instead of in the loader.  It's the only way to
ensure that constraints can be changed over time.

More information about the postgis-devel mailing list