[postgis-users] The operator && is not overlapsoperatorbasedonthe OGC SF SQL

[Darko Androsevic]

I understood you perfectly. Thanks.

I agree that one should rename it to MBR_intersects and use your notation:
g1 && g2 <==>  intersects ( envelope(g1) , envelope(g2) )

which I expressed using the sentence:
"&&" follows the OGC's intersect operator semantics on geometries' *bounding
boxes*.

Anyway, I also found in docs the other operators like &<, &>,... which I do
not understand especiallyt what means left (e.g. from center of masses, from
the most left bbox point,...), right and how one can use them....
Are they using index?



Just one more point.
You said that:
> This means that if one has only bounding boxes geometries then this is
valid
> "geom && candidate" <=> "geom && candidate AND intersects(geom,candidate)"

No, this isnt correct.


I would say that it is correct since, in this case, there are only "bounding
boxes geometries" or maybe I have not said it correctly :) the geometries
that satisfy the following:
envelope(geom) = geom
envelope(candidate) = candidate
then this is true
"geom && candidate" <=> "geom && candidate AND intersects(geom,candidate)"
<=> intersects(geom,candidate)
<=> intersects(enveloe(geom), envelope(candidate))

Cheers,
Darko


-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net]On Behalf Of David
Blasby
Sent: Wednesday, August 18, 2004 10:56 AM
To: PostGIS Users Discussion
Subject: Re: RE: [postgis-users] The operator && is not
overlapsoperatorbasedonthe OGC SF SQL


> This means that if one has only bounding boxes geometries then this is
valid
> "geom && candidate" <=> "geom && candidate AND intersects(geom,candidate)"

No, this isnt correct.


You are absolutely correct, the "&&" is poorly named.  This is for
historical reasons (the && operator was defined as "overlaps" by the
original postgresql geometry types).  It would be better named
something like "MBR_intersects".
A documentation change should be made so this is more clear and doesnt
conflict with the OGC named relationship.

g1 && g2 <==>  intersects ( envelope(g1) , envelope(g2) )

The "&&" is extreamly useful because its (1) fast and (more
importantly) (2) indexed.

Most of the time, you will do your query like this:

SELECT ... FROM ... WHERE the_geom && <geometry/bbox> AND <geometry op>;

The && is indexed (so its really fast) and will return an
"approximate" solution (all geometries whose bounding box intersects
the "search geometry's bounding box").

When you provide the "AND <geometry op>" portion, you refine the
approximate solution to the exact solution.  For example, "AND
touches(the_geom, <geom>)" or "AND intersect(the_geom,<geom>)".

Since pulling millions of geometries off the disk is slow, and the
geometry operations are computationally intensive using the index
speeds things up!

 NOTE: there are some situations where using "&&" isnt appropriate.
For example, "AND disjoint(the_geom,<geom>)" isnt going to be
effective because the "&&" approximate solution isnt correct.

Use "&&" when
 geometry_op(the_geom,<geom>)  ==> intersects(envelope(the_geom),
envelope(<geom>))

dave
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users