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

[Mateusz Loskot]

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.

Understood.

> 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.

Greetings
-- 
Mateusz Loskot
http://mateusz.loskot.net