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

Nicklas Avén nicklas.aven at jordogskog.no
Fri Nov 25 01:38:47 PST 2011


> The fact that the center of a bounding box of a point may not
> be exactly the point is not a problem, to me.
Fair enough

> 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.
> 
just to clearify:
In my example I posted in last post, the difference is 0.3 meters! It is
no microunits we are talking about.

The result is also that the ordering is wrong. You don't get the nearest
point when you expect it. 

I have no application where this matters and I don't know if anyone has.
I think it is more a question of being aware of it and informing that
PostGIS knn queries might give the wrong answer even if Postgresql knn
will give the right answer on the same dataset, just like the much
slower st_distance way of doing it. 



> 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?).

Is this along the line to only store the boxes once?

/Nicklas




More information about the postgis-devel mailing list