[fdo-internals] FDO RFC 16 - FDO Provider for SQLite

Mateusz Loskot mateusz at loskot.net
Wed Mar 19 11:43:55 EDT 2008

Traian Stanev wrote:
> Mateusz Loskot wrote:
>> Traian Stanev wrote:
>>> If this is an interchange format, why do you need to store a spatial
>>> index in there?
>> I've probably missed the "interchange" word in the RFC.
>> I understood the RFC is about using SQLite in similar manner as MySQL
>> or Shapefiles, etc.
> I was replying to Jason who was hoping to use it as an interchange format.

I got it.

>>> It would only make the file bigger? Spatial indexes
>>> are very fast to generate on the fly, so why carry one around with
>>> you?
>> I'm not sure it's really fast, but won't argue.
> It depends on the quality of the index and the amount of preprocessing
> you have done on the arrangement of the features in the table to exploit
> spatial locality.

Absolutely, you are right.

>> The advantage of built-in index is potentially faster querying
>> if the index is bound to SQL engine.
>> I see another advantage in integrity of the overall solution:
>> SQLite + spatial functions + spatial index
>> and implementation of drivers and providers may be simpler.
> Yes, a spatial index would make sense if SQLite's engine was extended to
> support spatial operations. I am not attempting to do this in this RFC
> but the possibility will be there to do this in the future.


> Making SQLite
> spatial would involve work with the SQLite author, since it would need to be
> integrated into the SQLite codebase.

Yes, I agree.
BTW, I've read Mr. Richard Hipp offers r-tree implementation for 
commercial clients of the SQLite.

Mateusz Loskot

More information about the fdo-internals mailing list