[postgis-devel] About BOXES

[Paul Ramsey]

On Fri, Nov 25, 2011 at 11:14 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 25, 2011 at 10:52:36AM -0800, Paul Ramsey wrote:
>> 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.
>
> I like the plan. I'll take care of the topogeometry part.
>
>> 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).
>
> BOX() seems a good representation for our new type, what do you think ?
> The SRID we could append at the end, which probably gives less parsing
> problems. But I'd love to see some real parsers code to see what they do.

geometry::bbox -> 'BOX()' ? not
geometry::bbox -> 'BBOX()' ?

I mean, I guess it works OK, it's just another quirk in a long list of quirks.

> Another big question is: will it be float or double ?

Double.

> I don't care, as long as it's the same that you find in a geometry cache :)
> Rationale is the cast from Geometry to BBox (or Envelope?) must be _fast_.

An argument in favour of accepting the double-box branch.

p.

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