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

[dustymugs]

On 11/30/2012 10:24 AM, Mateusz Loskot wrote:
> 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?
> 

I'm fine with two extents as the extents represent different things.
The extent currently in place is the maximum spatial extent of the
table.  The extent being added is the maximum data extent (represented
spatially).

-bborie