[postgis-devel] About BOXES

[Paul Ramsey]

Here's a third idea,

On Fri, Nov 25, 2011 at 8:50 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 25, 2011 at 08:39:48AM -0800, Paul Ramsey wrote:
>> On Fri, Nov 25, 2011 at 8:18 AM, Sandro Santilli <strk at keybit.net> wrote:
>
>> > Can we get rid of them all ? Why not ?
>>
>> There are use cases for boxes, so keeping one makes sense. There are
>> also uses of boxes embedded in client code, as you note index queries
>> were documented against a 'BOX3D' example for a very long time, even
>> when the index ops themselves were happening in GEOMETRY.
>>
>> The case for BOX3D is that it's a known external interface. The case
>> against it is that it has no SRID. We could upgrade the backend
>> storage for BOX3D to support SRID and enrich the text representation
>> with the "SRID=999;" hack. That would have the advantage of not adding
>> yet more boxes, and the disadvantage of keeping the odd "BOX3D" name
>> for what might sometimes be a 2D and sometimes a 4D box.
>
> Another idea:
>
>  1) keep BOX3D but deprecate it
>    (have it raise WARNING messages on canonical input...)

Or, add the new BBOX type, drop the BOX3D, but retain 'BOX3D(...)'
input as a valid alternate input syntax?

>  2) add a new type to which BOX3D implicitly cast
>    ( and returned by ST_Srid(BOX3D) )
>
> This could solve the name issue.
> Then:
>
>  3) drop all the other boxes (save gidx, being internal)
>  4) have st_extent return the new type
>
> And maybe, if entusiasm gets you:
>
>  5) have bbox-oriented operators be defined on the new type
>  6) provide implicit casts from each type to the new bbox type
>  7) drop loads of operators duplication
>
> --strk;
>
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>