Re: Fixing r-tree semantics

From: "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <bwhite(at)frognet(dot)net>
Cc: <teodor(at)sigaev(dot)ru>, <oleg(at)sai(dot)msu(dot)su>, <pgsql-hackers(at)postgresql(dot)org>, "'PostGIS Development Discussion'" <postgis-devel(at)postgis(dot)refractions(dot)net>
Subject: Re: Fixing r-tree semantics
Date: 2005-06-24 07:04:47
Message-ID: 9EB50F1A91413F4FA63019487FCD251D113405@WEBBASEDDC.webbasedltd.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> What needs more discussion is that it seems to me to make sense to extend
the standard
> opclasses to handle the four Y-direction operators comparable to the
X-direction
> operators that are already there, that is "above", "below", "overabove",
and
> "overbelow".

As part of PostGIS (http://postgis.refractions.net), I submitted a patch a
while back to add additional Y-direction operators to the code which is a
slightly modified version of rtree_gist (and yes, the PostGIS implementation
will suffer from the same issues you've found with the existing R-tree
implementations).

The operators I went for were as follows:

A &<| B - true if A's bounding box overlaps or is below B's bounding
box
A |&> B - true if B's bounding box overlaps or is above B's bounding
box
A <<| B - true if A's bounding box is strictly below B's bounding
box
A |>> B - true if A's bounding box is strictly above B's bounding
box

Since the rtree_gist implementation and operators were 2D, my thoughts were
to use another op-class only if the indexing were upgraded to 3D. So with
this in mind, I created the following new GiST strategies:

#define RTOverBelowStrategyNumber 9
#define RTBelowStrategyNumber 10
#define RTAboveStrategyNumber 11
#define RTOverAboveStrategyNumber 12

This is basically what you are suggesting but with a | instead of a ^ in the
operator name (my original choice was to try and use } to indicate the
positive sense of the Y-axis but this was not accepted as a valid operator
character which is why I changed to |).

It would be harder for us to change these operators since they already
exist, but then again it would be useful from a maintenance point of view to
keep the strategy numbers and operators the same across both
implementations. Of course strategy numbers are just used internally so
these aren't such a big issue - it's more the choice of operators that would
be useful to agree on.

Kind regards,

Mark.

------------------------
WebBased Ltd
17 Research Way
Tamar Science Park
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023
W: http://www.webbased.co.uk

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-06-24 13:00:08 Re: Server instrumentation patch
Previous Message Pavel Stehule 2005-06-24 05:43:32 Re: Function's LEAST, GREATEST and DECODE (Oracle vararg