[OSM-talk] (no subject)
nick at nickhill.co.uk
Thu Apr 27 00:05:27 BST 2006
Raphael Jacquot wrote:
> dblasby at openplans.org wrote:
>> Typically, if your geometries are "large" (ie. lots of points), then
>> your index will be highly efficient. If your geometries are
>> single-points (and no other columns in the table), then your index size
>> will be about the same size as your table size.
> AH ha... straight from the horse's mouth
> now, does my approach make any sense ?
I haven't got a holy cow or any investment in B-tree or R-tree
If the tests I have carried out so far showed R-trees to perform more
efficiently with GPX (GPS point) data, we wouldn't be having this
The fact is that the tests I have carried out so far with geometric
point types using an R-tree index is less practical for large databases
than b-trees using integer lat/lon.
I will perform more tests, and if I find an R-tree implementation which
which would clearly be more efficient for large databases, in real world
scenarios, than a b-tree can be, I will be glad to join you as a member
of the R-tree club.
I hope we can co-operate on this. I appreciate the design of R-tree
indexes, and feel they can be a good solution. But I will not jump to
the conclusion that they are the solution without first loading up a
large database and hammering it with queries, next to a good b-tree
More information about the talk