Thread: BUG #5889: "Intersects" for polygons broken

BUG #5889: "Intersects" for polygons broken

From
"Konrad Garus"
Date:
The following bug has been logged online:

Bug reference:      5889
Logged by:          Konrad Garus
Email address:      konrad.garus@gmail.com
PostgreSQL version: 8.4
Operating system:   Linux
Description:        "Intersects" for polygons broken
Details:

&& operator seems to be broken for polygons whose bounding boxes intersect:

select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1))';
 ?column?
----------
 t
(1 row)

It reportedly is different in 9.0
(http://stackoverflow.com/q/5015233/277683)

Docs could do better job explaining what types each of the geometry operator
supports, and whether intersecting polygons support nonconvex polygons as
well, or only uses bounding box as criteria.

Re: BUG #5889: "Intersects" for polygons broken

From
Tom Lane
Date:
"Konrad Garus" <konrad.garus@gmail.com> writes:
> && operator seems to be broken for polygons whose bounding boxes intersect:

> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1))';
>  ?column?
> ----------
>  t
> (1 row)

This is fixed as of 9.0; see the release notes at
http://www.postgresql.org/docs/9.0/static/release-9-0.html
which say

    Correct calculations of "overlaps" and "contains" operations for polygons (Teodor Sigaev)

    The polygon && (overlaps) operator formerly just checked to see
    if the two polygons' bounding boxes overlapped. It now does a
    more correct check. The polygon @> and <@ (contains/contained
    by) operators formerly checked to see if one polygon's vertexes
    were all contained in the other; this can wrongly report "true"
    for some non-convex polygons. Now they check that all line
    segments of one polygon are contained in the other.

            regards, tom lane

Re: BUG #5889: "Intersects" for polygons broken

From
Konrad Garus
Date:
2011/2/16 Tom Lane <tgl@sss.pgh.pa.us>:
> "Konrad Garus" <konrad.garus@gmail.com> writes:
>> && operator seems to be broken for polygons whose bounding boxes interse=
ct:
>
>> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1)=
)';
>> =A0?column?
>> ----------
>> =A0t
>> (1 row)
>
> This is fixed as of 9.0; see the release notes at
> http://www.postgresql.org/docs/9.0/static/release-9-0.html
> which say
>
> =A0 =A0 =A0 =A0Correct calculations of "overlaps" and "contains" operatio=
ns for polygons (Teodor Sigaev)
>
> =A0 =A0 =A0 =A0The polygon && (overlaps) operator formerly just checked t=
o see
> =A0 =A0 =A0 =A0if the two polygons' bounding boxes overlapped. It now doe=
s a
> =A0 =A0 =A0 =A0more correct check. The polygon @> and <@ (contains/contai=
ned
> =A0 =A0 =A0 =A0by) operators formerly checked to see if one polygon's ver=
texes
> =A0 =A0 =A0 =A0were all contained in the other; this can wrongly report "=
true"
> =A0 =A0 =A0 =A0for some non-convex polygons. Now they check that all line
> =A0 =A0 =A0 =A0segments of one polygon are contained in the other.

Thank you. How about the point of more informative docs that would
explain supported types, automatic conversions and all such caveats
(also for 8.3 and 8.4)?

--=20
Konrad Garus

Re: BUG #5889: "Intersects" for polygons broken

From
Robert Haas
Date:
On Wed, Feb 16, 2011 at 10:33 AM, Konrad Garus <konrad.garus@gmail.com> wro=
te:
> 2011/2/16 Tom Lane <tgl@sss.pgh.pa.us>:
>> "Konrad Garus" <konrad.garus@gmail.com> writes:
>>> && operator seems to be broken for polygons whose bounding boxes inters=
ect:
>>
>>> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1=
))';
>>> =A0?column?
>>> ----------
>>> =A0t
>>> (1 row)
>>
>> This is fixed as of 9.0; see the release notes at
>> http://www.postgresql.org/docs/9.0/static/release-9-0.html
>> which say
>>
>> =A0 =A0 =A0 =A0Correct calculations of "overlaps" and "contains" operati=
ons for polygons (Teodor Sigaev)
>>
>> =A0 =A0 =A0 =A0The polygon && (overlaps) operator formerly just checked =
to see
>> =A0 =A0 =A0 =A0if the two polygons' bounding boxes overlapped. It now do=
es a
>> =A0 =A0 =A0 =A0more correct check. The polygon @> and <@ (contains/conta=
ined
>> =A0 =A0 =A0 =A0by) operators formerly checked to see if one polygon's ve=
rtexes
>> =A0 =A0 =A0 =A0were all contained in the other; this can wrongly report =
"true"
>> =A0 =A0 =A0 =A0for some non-convex polygons. Now they check that all line
>> =A0 =A0 =A0 =A0segments of one polygon are contained in the other.
>
> Thank you. How about the point of more informative docs that would
> explain supported types, automatic conversions and all such caveats
> (also for 8.3 and 8.4)?

I think a lot of these things are already documented.  Aren't they?

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: BUG #5889: "Intersects" for polygons broken

From
Konrad Garus
Date:
http://www.postgresql.org/docs/current/static/functions-geometry.html

I wish it explained what arguments each of the operators accepts, and
whether any automatic conversions take place (like polygon to box in
that 8.3 issue).

What happens when I call ?# or ?- on a polygon and point? Two points? Open =
path?

Some of these are obvious, but others not so much.

2011/3/8 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Feb 16, 2011 at 10:33 AM, Konrad Garus <konrad.garus@gmail.com> w=
rote:
>> 2011/2/16 Tom Lane <tgl@sss.pgh.pa.us>:
>>> "Konrad Garus" <konrad.garus@gmail.com> writes:
>>>> && operator seems to be broken for polygons whose bounding boxes inter=
sect:
>>>
>>>> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,=
1))';
>>>> =A0?column?
>>>> ----------
>>>> =A0t
>>>> (1 row)
>>>
>>> This is fixed as of 9.0; see the release notes at
>>> http://www.postgresql.org/docs/9.0/static/release-9-0.html
>>> which say
>>>
>>> =A0 =A0 =A0 =A0Correct calculations of "overlaps" and "contains" operat=
ions for polygons (Teodor Sigaev)
>>>
>>> =A0 =A0 =A0 =A0The polygon && (overlaps) operator formerly just checked=
 to see
>>> =A0 =A0 =A0 =A0if the two polygons' bounding boxes overlapped. It now d=
oes a
>>> =A0 =A0 =A0 =A0more correct check. The polygon @> and <@ (contains/cont=
ained
>>> =A0 =A0 =A0 =A0by) operators formerly checked to see if one polygon's v=
ertexes
>>> =A0 =A0 =A0 =A0were all contained in the other; this can wrongly report=
 "true"
>>> =A0 =A0 =A0 =A0for some non-convex polygons. Now they check that all li=
ne
>>> =A0 =A0 =A0 =A0segments of one polygon are contained in the other.
>>
>> Thank you. How about the point of more informative docs that would
>> explain supported types, automatic conversions and all such caveats
>> (also for 8.3 and 8.4)?
>
> I think a lot of these things are already documented. =A0Aren't they?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



--=20
Konrad Garus

Re: BUG #5889: "Intersects" for polygons broken

From
Robert Haas
Date:
On Tue, Mar 8, 2011 at 3:20 PM, Konrad Garus <konrad.garus@gmail.com> wrote:
> http://www.postgresql.org/docs/current/static/functions-geometry.html
>
> I wish it explained what arguments each of the operators accepts, and
> whether any automatic conversions take place (like polygon to box in
> that 8.3 issue).
>
> What happens when I call ?# or ?- on a polygon and point? Two points? Open path?
>
> Some of these are obvious, but others not so much.

Hmm, yeah.  That looks like it could be improved.  It's certainly not
obvious to me what box * point means, for example, even though the
description says scaling/rotation.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: BUG #5889: "Intersects" for polygons broken

From
Bruce Momjian
Date:
Robert Haas wrote:
> On Tue, Mar 8, 2011 at 3:20 PM, Konrad Garus <konrad.garus@gmail.com> wrote:
> > http://www.postgresql.org/docs/current/static/functions-geometry.html
> >
> > I wish it explained what arguments each of the operators accepts, and
> > whether any automatic conversions take place (like polygon to box in
> > that 8.3 issue).
> >
> > What happens when I call ?# or ?- on a polygon and point? Two points? Open path?
> >
> > Some of these are obvious, but others not so much.
>
> Hmm, yeah.  That looks like it could be improved.  It's certainly not
> obvious to me what box * point means, for example, even though the
> description says scaling/rotation.

Would someone who uses these features please post changes and I will see
that get into the docs?  Thanks.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +