[fdo-users] new King.SpatiaLite FDO Provider

[Traian Stanev]

Hi Jason,

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.


Traian



> -----Original Message-----
> 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:34 AM
> To: FDO Users Mail List
> Subject: Re: [fdo-users] new King.SpatiaLite FDO Provider
> 
> There are a few differences as I understand it, and Haris can probably
> expand further.
> 
> First, yes, the SpatiaLite binary format is different from FGF, and
> cannot be read or written by the SQLite provider (which I believe can
> also read WKB/WKT).  SpatiaLite added a "Virtual FDO" mode and
> associated functions to read FDO-style SQLite, but I haven't tested
> recently and it may no longer work with recent changes to the FDO
> SQLite provider.
> 
> Second, the simple features metadata constructs (geometry columns,
> coordinate systems) are slightly different between the two formats and
> incompatible.
> 
> Third, Spatialite uses a built-in RTree-based spatial index, while the
> existing provider uses a different indexing mechanism.
> 
> Finally, all of the spatial functionality of the existing provider
> uses custom FDO code. The SpatiaLite provider uses SpatiaLite-native
> functionality, and complex spatial queries can be passed through as
> SQL.
> 
> Both providers have merit; the main benefits of the SpatiaLite
> provider are that it gives full interchange capabilities with the
> other implementers of SpatiaLite, which seems to be catching on well
> in the open source community, and that you have full spatial database
> capabilities in a file-based format.
> 
> Jason
> 
> 
> On 2010-09-01, Crispin_at_1Spatial <crispin.hoult at 1spatial.com> wrote:
> >
> > Haris,
> >
> > Can you say how this is different from the implementation of the
> OSGeo
> > SQLite provider?
> >
> > Is the FGF storage different to the Spatialite binary making the
> datasets
> > not sharable?
> >
> >  - thanks
> > --
> > View this message in context:
> > http://osgeo-org.1803224.n2.nabble.com/new-King-SpatiaLite-FDO-
> Provider-tp5480448p5485900.html
> > Sent from the FDO Users mailing list archive at Nabble.com.
> > _______________________________________________
> > fdo-users mailing list
> > fdo-users at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/fdo-users
> >
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users