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

[Sandro Santilli]

On Fri, Nov 30, 2012 at 09:06:02AM -0800, Bborie Park wrote:
> 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.

I disagree. In this case the constraint is _part_ of the database.
You can always change a constraint however you want.

--strk;