[postgis-users] st_equals strangeness

[Chris Hermansen]

I may be the only one, but I'm not following.

If geom_a and geom_b are different but have the same bbox, the predicate returns false, which is what's wanted, no?

If geom_a and geom_b are equal and their bboxes are different, well surely that is not possible...

So what is the problem with the bbox pre-test?
------Original Message------
From: Mark Cave-Ayland
Sender: postgis-users-bounces at postgis.refractions.net
To: PostGIS Users Discussion
ReplyTo: PostGIS Users Discussion
Subject: Re: [postgis-users] st_equals strangeness
Sent: Jan 9, 2010 01:35

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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


Chris Hermansen        chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.840.4625
Timberline Natural Resource Group · www.timberline.ca
401 · 958 West 8th Avenue  · Vancouver BC · Canada · V5Z 1E5