<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] DESIGN: R-Trees (fwd) -->
<!--X-From-R13: pynjerapNphc.uc.pbz -->
<!--X-Date: Thu, 28 Aug 1997 00:53:06 +0000 -->
<!--X-Message-Id: 199708280051.RAA09907#xsvr3,cup.hp.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: Pine.LNX.3.91.970824165454.19820M-100000@uni-corn.demon.co.uk -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] DESIGN: R-Trees (fwd)</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:clawrenc#cup,hp.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00786.html">Previous</a>
| <a href="msg00788.html">Next</a>
]
Thread:
[ <a href="msg00712.html">Previous</a>
| <a href="msg00701.html">Next</a>
]
Index:
[ <A HREF="author.html#00787">Author</A>
| <A HREF="#00787">Date</A>
| <A HREF="thread.html#00787">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] DESIGN: R-Trees (fwd)</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] DESIGN: R-Trees (fwd)</LI>
<LI><em>From</em>: <A HREF="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</A></LI>
<LI><em>Date</em>: Wed, 27 Aug 97 17:42:22 -0700</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
In <<A HREF="msg00712.html">Pine.LNX.3.91.970824165454.19820M-100000#uni-corn,demon.co.uk</A>>, on
08/24/97
at 06:14 PM, Greg Munt <greg#uni-corn,demon.co.uk> said:
>I should have known better, than to post this to rgma. I guess I
>won't try too hard at being constructive there, anymore.
RGMA is a breeding ground for list members. The list is a refuge from
RGMA...
<kof>
>Sigh.
>The R-Tree is a model for representing spatial data. I'm considering an
>R-Tree as the basis for some kind of co-ordinate system.
>My understanding of the R-Tree model:
Yup, you;'ve basically got it, and rephrased the definition I'm about
to quote below. Note that this by no means ilterates all the
different forms of trees or data storage structures for spatial data.
Scour the Stony Brook page for a while for a better grasp on that one.
Note: My first preference is for R*-Trees. Conceptually I like them.
They *feel* elegant to me. Hving been working with them for a while
however, as beautiful as the ability is to dynamically generate new
rectangles as queries demand them, I'm starting to dislike the clutter
than inevitably develops. I've yet to think of a decent approach for
using this feature of R*-Trees for a very dynamic world where the
object density, the query rate and the number of sources of queries
may be all high.
VP-Trees are starting to look attractive especially when a
neighborhood concept is mapped against their partitions.
I too still have to spend my time going thru Stony Brook on this.
--<cut>--
From <A HREF="http://www.cs.cuhk.hk/~drsam/methods.html:">http://www.cs.cuhk.hk/~drsam/methods.html:</A>
What is R-Tree
A R-Tree, proposed by Antonin Guttman[1], is an index structure for
point and spatial data at the same time. Insert, delete and search can
be intermixed without periodic reorganization. It uses a tuple to
represent a spatial data in the database. In order to retrieve the
data, each tuple has a unique identifier, tuple-identifier. At the
leaf node of a R-Tree, it has index record that can reference the
spatial data. The index record is (I, tuple-identifier). I is an
n-dimensional rectangle and it is the bounding rectangle of the
spatial data indexed. This rectangle is also known as minimal bounding
rectangle, MBR. and each entry in tuple-identifier is the upper and
lower bounds, [upper, lower], of the rectangle along the dimension.
Non-leaf nodes contain entries (I, childnode-pointer) where I is the
minimal rectangle bounding all the rectangles in the lower nodes'
entries. Childnode-pointer is the pointer to a lower node in the
R-Tree. Let M and m<=M/2 be the maximum and minimum number of entries
can be filled into one node respectively.
Properties of R-Tree
A R-Tree satisfies the following properties:
A R-Tree is a height balance tree and all leaves are on the same
level.
Root node has at least two children unless it is the leaf node.
Every non-leaf node contains between m and M entries unless it is
the root.
For each entries (I, childnode-pointer) in a non-leaf node, I is
the smallest rectangle that spatially contains all rectangles in
its child nodes.
Every leaf node contains between m and M index records unless it
is the root.
For each index record (I, tuple-identifier) in a leaf node, I is
the smallest rectangle that spatially contains the n-dimensional
data object represented by the indicated tuple.
R*-Tree
The R-tree is based on a heuristic optimization. The optimization
criterion is to minimize the area of each enclosing rectangle in the
inner nodes. R*-Tree which incorporates a combined optimization of
area, margin and overlap of each bounding rectangle in the inner nodes
was proposed in [6]. For slightly higher implementation cost, it
outperforms the existing R-Tree variants.
Minimizing the area covered by a bounding rectangle should
minimize the dead space. This will improve performance since
decisions which paths have to be traversed, can be taken on higher
level
Minimizing the overlap between bounding rectangles decreases the
number of paths to be traversed.
Minimizing the margin of a bounding rectangle will make the
rectangle more quadratic. It is because for fixed area, the object
with the smallest margin is the square. Quadratic rectangles can
be packed easily and thus building a smaller rectangle.
VP-Tree
Conventional spatial index structures divide the multi-dimensional
vector space into partitions which have approximately the same number
of data points as each other. It facilitates in finding the nearest
neighbor of a given query point because it is only necessary to touch
a small number of partitions. Most partitioning methods are based on
absolute coordinate values of the vector space. R-Tree and R*-Tree
described before use this type of partitioning method. The structures
partitioned in this way are useful for queries based on absolute
coordinates, like range queries. However, in general, it does not
maintain any distance information, such as distance between points
within a partition and the partition's boundaries. Since this
information is critical in pruning the search space for
nearest-neighbor search, index structures using partitioning methods
based on absolute coordinate are thus not so useful for
multi-dimensional nearest-neighbor search.
Nearest-neighbor search by definition is to find out one point with
minimum point-to-point distance from a given query point, so it is
natural to use partitioning method based on relative distance rather
than absolute coordinate values. Vantage-Point tree, or VP-Tree,
method was proposed by Peter N.Yianilos. It uses the partitioning
method based on relative distance and aims for handling
multi-dimensional nearest neighbor search.
As mentioned before, VP-Tree method bases the partitioning on the
relative distances among the data points, rather than their absolute
coordinate values. It also bases on a particular vantage point.
Actually, vantage point is nothing special but a point selected from a
vector space, or a set of data points. However, the choice of vantage
point plays an important role in the performance of indexing
algorithm.
--<cut>--
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------------(*) Internet: clawrenc#cup,hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00712" HREF="msg00712.html">DESIGN: R-Trees (fwd)</A></STRONG>
<UL><LI><EM>From:</EM> Greg Munt <greg#uni-corn,demon.co.uk></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00786.html">Re: [MUD-Dev] Re:</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00788.html">Re: [MUD-Dev] Character evolution</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00712.html">DESIGN: R-Trees (fwd)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00701.html">[MUD-Dev] Character evolution</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00787"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00787"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Character evolution</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="01166" HREF="msg01166.html">Re: [MUD-Dev] Character evolution</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 09 Sep 1997, 06:01 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00724" HREF="msg00724.html">Inebriation</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Tue 26 Aug 1997, 00:06 GMT
<LI><strong><A NAME="00721" HREF="msg00721.html">Comments on MUDs from Shadists</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Mon 25 Aug 1997, 18:43 GMT
<LI><strong><A NAME="00712" HREF="msg00712.html">DESIGN: R-Trees (fwd)</A></strong>,
Greg Munt <a href="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</a>, Sun 24 Aug 1997, 22:41 GMT
<UL>
<LI><strong><A NAME="00787" HREF="msg00787.html">Re: [MUD-Dev] DESIGN: R-Trees (fwd)</A></strong>,
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Thu 28 Aug 1997, 00:53 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00701" HREF="msg00701.html">[MUD-Dev] Character evolution</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 21 Aug 1997, 17:52 GMT
<LI><strong><A NAME="00699" HREF="msg00699.html">Re:</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Thu 21 Aug 1997, 16:54 GMT
<UL>
<LI><strong><A NAME="00702" HREF="msg00702.html">Re: [MUD-Dev] Re:</A></strong>,
Richard Woolcock <a href="mailto:KaVir#dial,pipex.com">KaVir#dial,pipex.com</a>, Thu 21 Aug 1997, 18:01 GMT
</LI>
<LI><strong><A NAME="00704" HREF="msg00704.html">[MUD-Dev] Character evolution</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 21 Aug 1997, 19:12 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>