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

[Traian Stanev]

It's a waste of space to store BBOX. It would cost at least 32 bytes per feature, not counting the indexes.

Also, you can easily compute the bounding box and add those 4 columns very quickly when you need them, given that SQLite is pretty fast to read from. Indexing on the 4 BBOX columns would make spatial queries have to compute the intersection of the results of 4 tree searches. SQLite is fast, but it's not *that* fast.

Anyway, the nice thing about this format is that you can create the BBOX columns anyway, and use them. The FDO provider will not be using it though, for performance reasons.


Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth, GEOGRAF A/S
Sent: Tuesday, March 25, 2008 7:12 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite

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<mailto: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/256ae0c6/attachment-0001.html