Hi, I think the simplest solution would be to put a spatial index on top of the B-tree, that's what e.g. Oracle does in their Spatial Cartridge. Basically you store the index data in relations and index these relations by B-trees. In this case, you do not have to change the core code of SQLite. You can already do this now. Nevertheless, it would be nice, if SQlite supports somehow the "extensible indexing interface". So, you ask a spatial query and in the background the system uses the index data stored in relations. We have done a lot of research on that topic. To get acquainted to the basic idea, you might have a look at "The Paradigm of Relational Indexing: A Survey". In my opinion, a direct integration of a spatial index is of course preferable, but who is going to do that? Best Martin
----- Ursprüngliche Mail ---- Von: George Ionescu <[EMAIL PROTECTED]> An: sqlite-users@sqlite.org Gesendet: Donnerstag, den 18. Mai 2006, 08:28:39 Uhr Betreff: [sqlite] Re: spatial sqlite anyone ? Hello dear Noel, hello all sqlite users, a spatial extension for sqlite would be nice, although I think that replacing the indexing scheme (e.g. replace the current b-tree with a quad-tree or another spatial index) is alot of work. Just some questions / thoughts: 1. How would you handle indexing? Would you replace completely the btree with a spatial index (the hardest thing to do)? And if so, btree indexing would still be available or not? 2. Go for GEOS's STRTree. It's the fastest spatial index I could find (I did some research awhile ago on open-source solutions regarding spatial indexes). 3. You might want to take a look at SpatialIndex (http://u-foria.org/marioh/spatialindex/). The library is pretty clever designed and it supports RSTAR-tree, MVR-tree and TPR-tree. The problem I found with this library was that it was slower than GEOS at the time I last checked. One of the features I like is that it allows persisting the index. This might be an intermediate solution: you could store the index as a blob in the database. It would not be very efficient (as efficient as replacing indexing) but it would be a place to start. 4. Another nice library who might do the job is CGAL (http://www.cgal.org/). I didn't benchmarked it mostly because GEOS suited my needs just fine, but how knows, it might be better than the ones I mentioned. George.
