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

Mateusz Loskot mateusz at loskot.net
Fri Nov 30 10:24:01 PST 2012

On 30 November 2012 18:08, dustymugs <dustymugs at gmail.com> wrote:
> On 11/30/2012 09:21 AM, Mateusz Loskot wrote:
>> On 30 November 2012 17:18, Sandro Santilli <strk at keybit.net> wrote:
>>> On Fri, Nov 30, 2012 at 05:16:40PM +0000, Mateusz Loskot wrote:
>>>> On 30 November 2012 17:11, Sandro Santilli <strk at keybit.net> wrote:
>>>>> On Fri, Nov 30, 2012 at 09:03:54AM -0800, Bborie Park wrote:
>>>>>> The original extent was computed by unioning the tiles' convex hulls
>>>>>> when adding that constraint. raster2pgsql just added the necessary
>>>>>> calls to AddRasterConstraints().
>>>>> This conflicts with what Mateusz said, right ?
>>>>> Or did I miss anything ?
>>>> There are two loaders behind single name :)
>>>> raster2pgsql (the current version, implemented in C)
>>>> raster2pgsql.py (formerly known as gdal2wktraster.py, deprecated)
>>>> That is why I used past tense in my explanation, to indicate "how it
>>>> used to be".
>>>> I wrote the gdal2wktraster.py (raster2pgsql.py) only and it was in
>>>> pre-view/constraints times.
>>> Ouch. So, which package ships which version ?
>>> Are the two loaders compatible under every other aspect ?
>> AFAIK, raster2pgsql.py has only been shipped in pre-2.0 alpha/beta versions.
>> So, the stable released version was always the raster2pgsql written in C.
>> The raster2pgsql.py is deprecated now, so it's no longer maintained.
> Steering the conversation back on track.

It has never left the track, AFAIK.
Finding our bearings about where and when things have changed
is important to confirm if it is a regression or not, thus when it must be fixed
or when it should be improved.

If the problem I'm reporting is a regression, then it should be fixed in 2.0.1.
If it is not, despite I'd like to see it in 2.0.1, it likely will make
it to 2.1.0.

The thing is that first version(s) of PostGIS Raster spec and implementation
has not been officially released, but published as betas. Then, before
release in
PostGIS 2.0.0 the spec has changed, so the implementation.
I just want to emphasize, that line of the spec version decided before 2.0.0
should not be discarded, despite its implementation hasn't been
officially released.
The pre-2.0.0 PostGIS Raster has lived for more than 2 years,
it has been used for more than 2 years and clients like GDAL have been
implemented on that basis. Finally, it included important compromises.

Some complementary discussion with Sandro is available
in the #postgis IRC logs from today.

> So are we all in agreement
> that the correct solution is to add a new constraint "data_extent" which
> will indicate the table's maximum extent in which data is present?

Either to add new constraint, or to correct what the current extent represents.
Juggling two extents may be confusing (two extents?). What you think?

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

More information about the postgis-devel mailing list