[postgis-users] st_equals strangeness

[Mark Cave-Ayland]

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