<br><br><span class="gmail_quote">On 4/22/07, <b class="gmail_sendername">Robert (Jamie) Munro</b> <<a href="mailto:rjmunro@arjam.net">rjmunro@arjam.net</a>> wrote:</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>(see wikipedia about r-trees: <a href="http://en.wikipedia.org/wiki/R-tree">http://en.wikipedia.org/wiki/R-tree
</a>)</blockquote><br>
<br>
I am the person who originally wrote this wikipedia article - this was
one subject I knew anything about (that had no wikipedia article),
having spent several weeks reading the original paper and implementing
it.<br>
<br>
In fact the only reason that I implemented the rtree algorithm, was
because the existing spatial search algorithm we were using (in sql
server, as I recall) was<br>
<br>
   WHERE Latitude BETWEEN a AND b AND Longitude BETWEEN c AND d.<br>
<br>
I think I'm running the risk of preaching to the choir here, but this
will not scale to a large number of users, and it won't scale to a
large amount of data. It certainly will not scale to both.<br>
<br>
I would like to do some doing, rather than just talking (actually
mostly reading). So... what I propose to do is to create a test suite
that stresses the database, simulating current and future loads, to
enable us to find the best solution to the spatial indexing problem.
(Possibly in the future, it might help in fixing the data model
problems also)<br>
<br>
I'm not proposing to define the actual tests, or the actual fixes here
and now - more just to float the idea of a structured and standardised
test suite and check that noone else is doing something similar.<br><br>(How long do we have before the current server collapses under the load?)<br>
<br>
Cheers, Aled.