[fdo-internals] FDO RFC 16 - FDO Provider for SQLite
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
>> 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.
More information about the fdo-internals