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

[Bborie Park]

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.