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

[Kenneth, GEOGRAF A/S]

I just re-read the RFC.

What are your reasons for not storing BBOX releated data in the data table?

I would suggest adding four columns, like minx, maxx, miny, max (perhaps 
name them via. the geometry_columns table?).
With that approach, and index on the pairs would move the BBOX query 
load/optimization into the DBMS.
BBOX queries are simple, and does not require reading the actual column 
data.

Your extended spatial index algorithm might read these values to produce 
the search tree.

Another suggestion, would be to store the search tree in a blob column.
That would enable a much faster load of data.

To avoid the requirement that all data updaters know the algorithm, it 
might be legal to just clear the BLOB data on updates.

I wrote a short paper on a similar mechanism some time ago, with a friend:
http://www.hexad.dk/opensource/spatialdbms.pdf


Regards, Kenneth, GEOGRAF A/S



Traian Stanev skrev:
>
> Hello,
>
>  
>
> I just posted FDO RFC #16. Fresh off the virtual presses (printed on 
> 100% recycled electrons, for you green-minded folks):
>
>  
>
> http://trac.osgeo.org/fdo/wiki/FDORfc16
>
>  
>
>  
>
> Thanks,
>
> Traian
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080325/4127ed29/attachment.html