[fdo-internals] FDO RFC 16 - FDO Provider for SQLite
Traian Stanev
traian.stanev at autodesk.com
Tue Mar 18 18:25:59 EDT 2008
That proposal sounds reasonable.
Traian
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch [Jason.Birch at nanaimo.ca]
Sent: Tuesday, March 18, 2008 5:20 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite
I don't think that it needs to be either/or.
As Frank proposed, I would prefer to see a solution that allows the user
to specify the following in geometry_columns table:
FGF
WKB12
WKT12
And then allow storage of any one of these in the database as the
"native" format for any given table.
The overhead is that all implementations of this SQLite geo-database
would have to support these formats, but this would allow optimisation
for FDO/MapGuide with FGF, for standardisation with WKB (I would suggest
only supporting SFS 1.2 WKB), or for ease of access with WKT.
I am hesitant about any solution that requires special dlls for
accessing the SQLite database at this point...
Jason
-----Original Message-----
From: Mateusz Loskot
Subject: Re: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite
My positions are:
1. If we focus only on implementation of the FDO Provider for SQLite,
then I think that FGF is a better choice than WKT/WKB because it will
not require FGF<->WKB translations. Format translations are potential
performance bottlenecks.
2. If we came to the conclusion that it's better to implement more
universal solution, then WKB format is reasonable choice.
Potentially, there is a chance for development of universal solution
without loosing max of performance. The option is to follow OGC SFS and
common implementations like PostGIS or MySQL. Simply, we should be able
to extend SQLite with OGC SFS functions: AsBinary and AsText
Then, following schemes would be possible:
1. Return FGF as native format, equivalent to PostGIS EWKB
SELECT the_geom FROM table:
2. Request WKB
SELECT AsBinary(the_geom) FROM table;
3. Request WKT
SELECT AsText(the_geom) FROM table;
Following this concept, it could be even possible to implement AsEWKT
and AsEWKB to gain some level of compatibility with PostGIS.
Why I'm saying such option is possible?
From version 3.3.6, SQLite supports loadable extension modules
providing additional SQL functions:
http://www.sqlite.org/cvstrac/wiki?p=LoadableExtensions
"Additional functions may be written in C and added to the database
engine using the sqlite3_create_function() API."
http://www.sqlite.org/lang_expr.html
http://sqlite.org/capi3ref.html#sqlite3_create_function
Short example about creating custom functions:
http://souptonuts.sourceforge.net/readme_sqlite_tutorial.html
http://souptonuts.sourceforge.net/code/myfuncpp.cc.html
Greetings
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
More information about the fdo-internals
mailing list