[postgis-devel] lwgeom->bbox

Paul Ramsey pramsey at opengeo.org
Mon Oct 31 13:29:53 PDT 2011

On Sun, Oct 30, 2011 at 11:43 PM, Sandro Santilli <strk at keybit.net> wrote:

> Then we'd have to always compute it, whatever we're going to do
> with it, even for subcomponents (each edge of a multiline).

Well, for the objects we're not currently already computing it
(points) that's not a big deal, but I can see how subcomponents might
be an issue. But I recall that Nik had to fight with this a bit in his
work since he needed to compute boxes before he could get started with
his distance routines...


> I'd rather add an interface to fetch box which would either get you
> the cached one or create one on demand, and another to know if it's
> already cached, in case you want to only deal with it in that case.
> Wasn't there such interface already ?

Yeah, you're right lwgeom_add_bbox() does basically what we want
(though perhaps it should have an optional flag or a _deep variant
that would box-ify all subcomponents too).

Instead of doing the above I've re-named the gserialized_get_gbox_p to
gserialized_read_gbox_p, and make gserialized_get_gbox_p actually do
the try-to-read-then-calculate-if-necessary steps. I also bulked up
gserialized_read_gbox_p a little to handle points and two-point lines
without requiring the lwgeom-creation step.


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

More information about the postgis-devel mailing list