I found the R-Tree idea fascinating. Conceptually, this is exactly what I need. But indeed, my case is very simple: my dataset is not sparse, my tiles never overlap (for a given zoom factor), the number of tiles is still rather small, they are all rectangular and the same size (modulo edge effects).
So while the asymptotic behavior of the R-Tree is likely to be much better, I am more concerned with the behavior towards small data sizes... The other important criterion is ease of implementation. Thanks to the SQLite R-Tree extension, both ways seem equally easy. I guess I'll start with my initial idea of a 3 column index, and experiment with R-Tree a bit later. Thanks for your suggestions. Jean-Denis On 3 mai 2011, at 19:42, David Garfield wrote: > Actually, for what he wants, you don't need anything fancy. A simple > multi-column index is enough. > > The R-Tree is to allow queries of a sparse dataset, that might also > have overlaps. > > So: A simple index for your background imagery. An R-Tree index for > the features added on top of your background imagery. > > --David Garfield > > Enrico Thierbach writes: >> Hi, >> >> I think an R Tree is what you are after. >> >> http://www.sqlite.org/rtree.html >> >> /eno >> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
