[postgis-devel] automatic BVOL on spatial columns

[strk at refractions.net]

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/