[OSM-talk] (no subject)

[Nick Hill]

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 ?

Hi Raphael

I haven't got a holy cow or any investment in B-tree or R-tree 
implementations.

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 
discussion.

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 
implementation.