[postgis-devel] Boxes cache and type (was: Caching Double-based Boxes)

Sandro Santilli strk at keybit.net
Fri Nov 25 01:16:02 PST 2011


On Fri, Nov 25, 2011 at 09:09:09AM +0100, Nicklas Avén wrote:
> > When I left, I remember we had a RECHECK issued in place.
> > Is the RECHECK still there ? If it is, the presence of index
> > shouldn't change the view on reality.
> 
> There is no RECHECK when we are talking about knn and ordering. 

Ok.

> SELECT id, ST_Distance(a, b), a<->b FROM 

I now realize this is a non-issue really.
ST_Distance is checking realdistance, while <-> is checking
distance between the center of the bounding box.

The fact that the center of a bounding box of a point may not
be exactly the point is not a problem, to me.
If a microunit error is critical for your application you're
likely choosing your units in a wrong way and shouldn't rely
on bounding-box based computations anyway.

Since we're at it, I would add that I don't even care if we
always use float-based bounding boxes, as long as we are
consistent about it (and wouldn't require a dump/reload).

I think it'd be important to brainstorm about this now as
next step is I'd like to see a BBOX first class types coming
out which would then be used to represent bounding boxes of
all our spatial types (geometry, geography, topogeometry,
raster) and could then be used as key into the index as as
the only valid operand for bounding-box oriented operators 
(&&, <->, <#>, $>, $<, $@, ...) and functions (st_extent?).

Such new type might greatly simplify the code in that every
spatial type would only need to provide an implicit cast
to the new type in order to get all the operators and
indexing support w/out code duplication.

--strk; 

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



More information about the postgis-devel mailing list