Paul Ramsey wrote:
Well, that brings us to the API level, no? Because operators have
meanings in index (32-bit) terms. Should all our operators have 64-bit
rechecks? Should some of them? Should '=' just get a special
treatment, because we have such an in-grained understanding of what
that symbol connotes, and other symbols be left as pure index ops?
P
What should happen is that only the operators listed in the GiST
operator class and within bounding box checks should use BOX2DFLOAT4s.
You cannot use them to check negatives, i.e. for something lies outside
of the bounding box because with an inflated bounding box you will have
a slightly larger area than reality; hence any geometries between the
true bounding box and the inflated bounding box will not appear in your
result.
I'm beginning to think that we should consider re-benchmarking 64-bit
floats for PostGIS 2.0 because it would solve so many of these corner
cases, plus with accurate bounding boxes we can implement algorithmic
shortcuts based upon !within to speed up some algorithms.
The problem with ST_Equals() is fairly obvious looking at it though:
CREATE OR REPLACE FUNCTION ST_Equals(geometry,geometry)
RETURNS boolean
AS 'SELECT $1 ~= $2 AND _ST_Equals($1,$2)'
LANGUAGE 'SQL' IMMUTABLE STRICT;
$1 ~= $2 checks for BOX2DFLOAT4 equivalence, and so two non-identical
double-precision geometries can produce the same inflated bounding box
here. I believe this part should be removed from the function.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
