[postgis-devel] About BOXES

[Paul Ramsey]

Yeah, I see that now. The only highly backward compatible solution is
to leave all those types in place, with minimal support functions and
casts into the "new better" box, and warnings on instantiation to try
and drive folks away from them.

So, BBOX will come into being, it will have an SRID, and some support
functions, and casts for all the other types that I understand (I
don't understand topogeometry yet). The old boxes will still exist.

Backward compatiblity issue: what does ST_Extent() return? The problem
is if people are parsing the output, they expect whatever it returns
to have a text representation of 'BOX()' (the old box2d
representation).

P.

On Fri, Nov 25, 2011 at 10:21 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 25, 2011 at 09:27:46AM -0800, Paul Ramsey wrote:
>> On Fri, Nov 25, 2011 at 8:50 AM, Sandro Santilli <strk at keybit.net> wrote:
>
>> >  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?
>
> Won't work with 2002 syntax:
>
>  WHERE the_geom && 'BOX3D(90900 190900, 100100 200100)'::box3d
>
> box3d: type not found
>
> --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
>