Re: Polygons passed to poly_overlap have 0 pts when

From: "Kenneth Chan" <kkchan(at)technologist(dot)com>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Polygons passed to poly_overlap have 0 pts when
Date: 2002-05-29 14:44:53
Message-ID: 20020529144453.46127.qmail@iname.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hmmm, the very simple example didn't expose the issue probably because it has only two rows of data and the index is not being used.

For poly_contain, I guess one alternative is to use the result of the box_contain test and not proceed to the point_inside test if one of the poly->npts == 0.

Ken

----- Original Message -----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Tue, 28 May 2002 23:29:08 -0400
To: "Kenneth Chan" <kkchan(at)technologist(dot)com>
Subject: Re: [HACKERS] Polygons passed to poly_overlap have 0 pts when column is indexed using rtree

> ... Turned out that npts of the
> polygon retrieved from the table is 0 (the other polygon is a constant
> and its attributes are correct). I suspect the “feature” might
> affect other functions that uses polygons->npts like poly_contain.
> Would anyone happens to know the identity of the “offending”
> function might be? TIA

It appears that the issue is not rtree itself, but the rt_poly_union
and rt_poly_inter functions, which produce "polygons" that have only
bounding boxes. Not sure whether that should be considered erroneous
or not. The dummy polygons are evidently used as internal node keys
in the rtree.

regards, tom lane

--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-29 16:07:21 Re: Null values in indexes
Previous Message Jan Wieck 2002-05-29 14:38:37 Re: Null values in indexes