[postgis-users] st_equals strangeness

[Paragon Corporation]

 Mark,

I have to agree with Chris on this.  Not following you.  The bbox pretest is
just in there to use a spatial index.  So in the box3d32 float case, the box
is slightly bigger than it should be.

It would seem to me that if two geometries are equal, they would both have
the same oversized bbox, so why is this a problem?

It would seem to me to be only an issue if two geometries that are the same
some how end up with box3d32s that are different, how would this ever
happen?

Thanks,
Regina

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Chris
Hermansen
Sent: Saturday, January 09, 2010 3:24 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] st_equals strangeness

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