[postgis-devel] About BOXES

Sandro Santilli strk at keybit.net
Fri Nov 25 11:14:04 PST 2011


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.

Another big question is: will it be float or 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_.

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html



More information about the postgis-devel mailing list