Hi, the baisc idea of the Relational R-tree is to map the hierarchical relationship between the R-tree nodes to a (father, son) relation where a b-tree is on father. You can the traverse the relation preferable using recursive SQL, if not available, you have to do it on your own. The Idea of the Relational Quadtree is to select the Quad numbers according to a space filling curve,e.g. z-values. Then again you can use ordinary SQL.
----- Ursprüngliche Mail ---- Von: Noel Frankinet <[EMAIL PROTECTED]> An: sqlite-users@sqlite.org Gesendet: Donnerstag, den 18. Mai 2006, 09:50:56 Uhr Betreff: Re: AW: [sqlite] Re: spatial sqlite anyone ? Martin Pfeifle wrote: >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 > > > Not me, Thank you for the article, If I get the key from the quadtree/rtree index, what is the way to get the data while staying "on top" of sqlite ? If can see the following schema: select data according to normal sql rule (all the non spatial rules) then filter it spatailly (that's what I do now, simple bbox filtering, no indice). I would prefer the other way around, use spatial index, get a subset (a key set ?) then apply sql alphanumerical filter. Do you know a way to do that in sqlite ? Best regards >----- 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. > > > > -- Noël Frankinet Gistek Software SA http://www.gistek.net
