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

dustymugs dustymugs at gmail.com
Fri Nov 30 10:08:35 PST 2012


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.  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?

-bborie



More information about the postgis-devel mailing list