[fdo-users] new King.SpatiaLite FDO Provider

[Traian Stanev]

Hi Jason,

There is nothing wrong with either provider. Having more choices is always good. I just wanted to explain and clarify some of the choices made in the Autodesk provider.

Traian


From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, September 01, 2010 4:25 PM
To: FDO Users Mail List
Subject: Re: [fdo-users] new King.SpatiaLite FDO Provider

Hey Traian,

So I guess it would be fair to say in a nutshell that the FDO SQLite provider is designed for performance and OGC simple features alignment, especially relative to FDO/FGF geometry access, while the Spatialite provider is designed for compatiblitiy with the existing Spatialite format and underlying capabilities.

When it comes down to it, although the RFC16 spec and the Spatialite format both use the SQLite database engine, they are essentially different formats and trying to encompass both the RFC16 format and libspatialite in a single provider would, IMO, lead to considerable limitations and I'm guessing some pretty ugly code.

Jason

On 1 September 2010 07:26, Traian Stanev wrote:

Although Autodesk has modified the sqlite engine inside the FDO provider, the file format has not changed since RFC 16, i.e. it is fully interoperable with external sqlite tools. If something is broken in the format that prevents such interoperability, it would be considered a major bug.

The reason the spatial index is not built into the sqlite database is because the provider builds it on the fly when opening the FDO connection. This does not prevent you from storing an extra column with extents in case you also want to do bbox queries yourself for example. Although I have not measured it personally, people have told me that the spatial index in the FDO provider outperforms the sqlite R-Tree, in addition to not taking any extra space in the file, like the R-Tree does.

IMO, the SpatiaLite geometry format is a hack that relies on magic bytes in blobs to determine if something is a geometry. It is also *very* bulky for small geometries like points. As far as SQL passthrough of geometric queries, there has been some work to enable that in the SQLite FDO provider as well.

As far as regular queries, the FDO provider is measurably and significantly faster than the SQLite core engine by itself. Overall, I think the database format specified in RFC16 is superior in that it corresponds closely to the OGC SQL spec and performs well, but then again I am a little bit biased.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20100901/2392eb11/attachment-0001.html