[fdo-users] new King.SpatiaLite FDO Provider

[Jason Birch]

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/8c2a8f4f/attachment-0001.html