[postgis-devel] automatic BVOL on spatial columns
strk at refractions.net
strk at refractions.net
Wed Jan 5 04:06:36 PST 2005
I've added AUTOCACHE_BBOX support
(COMPUTE_BBOX strategy==FOR_COMPLEX_GEOMS)
in PG_LWGEOM_construct() and pglwgeom_serialize().
During the process I've fixed a bug in collect(geom,geom)
failing to drop BBOX and SRID in input geoms before constructing
outer. Also the collect(geom,geom) and collect_garray(geom[])
now also use strategy WHEN_SIMPLE computing the union of all
input geometries' bboxes if available.
The BBOXCACHE_BEHAVIOURS doc has been updated.
Leftouts are functions marked in the document as using **SRL**
and *EXP*.
--strk;
On Fri, Dec 31, 2004 at 02:09:06PM +0100, strk at refractions.net wrote:
> Last mail for this year..
> I've started cleaning up the code so to improve the use of a
> single (or a couple) of entry points for serializzation.
> InteriorRingN, GeometryN and ExteriorRing have been migrated
> to LWG serializzation method, as a side-effect InteriorRingN
> and ExteriorRing have been made OGC-strict (require POLYGON
> input).
>
> I plan to continue with the cleanup and later introduce
> bbox caching strategies in the serializer function(s).
>
> Happy new year.
> --strk;
>
> On Fri, Dec 31, 2004 at 01:01:13PM +0100, strk at refractions.net wrote:
> > I've added in the repository a report of all functions returning
> > a geometry. For each function the bbox cache strategy is documented
> > and also the output construction mean. We have different means of
> > output construction:
> >
> > Custom (the functions internally create the output geom)
> > Serialized (the function use PG_LWGEOM_construct)
> > - this is always applicable to Custom as it -
> > - takes an already serialized object in input -
> > LWGEOM (the cleanest and easier way)
> >
> > I've enforced a single entry point for LWGEOM construction, so
> > every function using the LWGEOM way will have a single entry
> > point for output creation. This won't help for strategies NOT
> > based on output geometry.
> >
> > Please take a look at the document (BBOXCACHE_BEHAVIOURS).
> > More later (or next year).
> >
> > --strk;
> >
> > On Fri, Dec 31, 2004 at 09:41:11AM +0100, strk at refractions.net wrote:
> > > On Thu, Dec 30, 2004 at 01:28:03PM -0800, Paul Ramsey wrote:
> > > >
> > > > What won't be quick? The code or the implementation of the code?
> > > > P
> > >
> > > I was referring to the implementation (serializers are
> > > recursive function, so *every* function needs to take
> > > the caching strategy into consideration somehow (or
> > > all serializers will need another argument stating wheter
> > > or not it is a top-level geometry or not).
> > >
> > > The code will be slower whenever the box is computed for
> > > intermediate geometries even if not needed.
> > >
> > > For example:
> > >
> > > SELECT summary(buffer(convexhull(
> > > simplify(<polygon>, 1)), 1));
> > >
> > > That query would compute bbox for the <polygon>, for the
> > > simplified polygon, for the convexhull, and for the buffered
> > > geom (4 times), when at the end the cache won't be used
> > > at all.
> > >
> > > --strk;
> > >
> > > >
> > > > strk at refractions.net wrote:
> > > >
> > > > >On Thu, Dec 30, 2004 at 10:00:21AM -0800, Paul Ramsey wrote:
> > > > >
> > > > >>Sounds good and simple to me, good stuff!
> > > > >>
> > > > >>P
> > > > >
> > > > >
> > > > >Good. I'll take that path then.
> > > > >Note that it won't be a quick operation (see report on the
> > > > >various functions and their bbox cache behaviour.
> > > > >
> > > > >--strk;
> > > > >
> > > > >
> > > > >>strk at refractions.net wrote:
> > > > >>
> > > > >>
> > > > >>>I've made canonical, (E)WKT and (E)WKB and GEOS input methods
> > > > >>>call a function returning wheter it's worth to cache bbox, and
> > > > >>>add it accordingly. None of this methods will face the problem
> > > > >>>of wheter to drop an existing cache, as transport formats do
> > > > >>>not contain that information. GEOS Geometry could potentially
> > > > >>>store an Envelope, but that's not automatically converted by
> > > > >>>the existing converters.
> > > > >>>
> > > > >>>Note that many geometry editors decide wheter or not to
> > > > >>>add a bbox cache to their return based on other heuristics.
> > > > >>>Some of them add a bbox if its input geom does have a cache
> > > > >>>already ( transform, translate, reverse, simplify, segmentize ),
> > > > >>>some always avoid a bbox computation ( collect, addpoint ).
> > > > >>>
> > > > >>>To make this behaviour consistent every function returning
> > > > >>>a geometry should call the heuristic functions and explicitly
> > > > >>>cache a bbox when the conditions match.
> > > > >>>
> > > > >>>Still I'm convinced that the user should have more control
> > > > >>>over this aspect, more specifically she should decide when
> > > > >>>exactly to compute it in a chain of calls, to improve performace.
> > > > >>>Users willing to have this finer control can set AUTOCACHE_BBOX
> > > > >>>to 0 in Makefile.config. In this case internal functions should
> > > > >>>compute a bbox only if that is a simple operation (ie: does not
> > > > >>>require a scan of the geometry points). The implemented trigger
> > > > >>>would be then useful to ensure that tables used for frequent
> > > > >>>selects always have a bbox cached.
> > > > >>>
> > > > >>
> > > > >>
> > > > >>_______________________________________________
> > > > >>postgis-devel mailing list
> > > > >>postgis-devel at postgis.refractions.net
> > > > >>http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > > > >
> > > > >
> > >
> > > --
> > >
> > > For standing up against patentability of software,
> > >
> > > Thank You, Poland!
> > >
> > > Read the intervention: http://kwiki.ffii.org/ConsPolon041221En
> > > Send your thanks: thankyoupoland.info
> > > Read/do more: http://www.noepatents.org/
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> > --
> >
> > For standing up against patentability of software,
> >
> > Thank You, Poland!
> >
> > Read the intervention: http://kwiki.ffii.org/ConsPolon041221En
> > Send your thanks: thankyoupoland.info
> > Read/do more: http://www.noepatents.org/
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
> --
>
> For standing up against patentability of software,
>
> Thank You, Poland!
>
> Read the intervention: http://kwiki.ffii.org/ConsPolon041221En
> Send your thanks: thankyoupoland.info
> Read/do more: http://www.noepatents.org/
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
--
For standing up against patentability of software,
Thank You, Poland!
Read the intervention: http://kwiki.ffii.org/ConsPolon041221En
Send your thanks: thankyoupoland.info
Read/do more: http://www.noepatents.org/
More information about the postgis-devel
mailing list