[prev in list] [next in list] [prev in thread] [next in thread]
List: fdo-users
Subject: RE: [fdo-users] new King.SpatiaLite FDO Provider
From: Traian Stanev <traian.stanev () autodesk ! com>
Date: 2010-09-01 20:31:05
Message-ID: D20FC5C02CA4AB41891CFE76D91C57A97072D42FC0 () ADSK-NAMSG-02 ! MGDADSK ! autodesk ! com
[Download RAW message or body]
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@lists.osgeo.org [mailto:fdo-users-bounces@lists.osg=
eo.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 provid=
er is designed for performance and OGC simple features alignment, especiall=
y relative to FDO/FGF geometry access, while the Spatialite provider is des=
igned 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 format=
s and trying to encompass both the RFC16 format and libspatialite in a sing=
le provider would, IMO, lead to considerable limitations and I'm guessing s=
ome pretty ugly code.
Jason
On 1 September 2010 07:26, Traian Stanev wrote:
Although Autodesk has modified the sqlite engine inside the FDO provider, t=
he 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 prev=
ents such interoperability, it would be considered a major bug.
The reason the spatial index is not built into the sqlite database is becau=
se 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 meas=
ured it personally, people have told me that the spatial index in the FDO p=
rovider 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 queri=
es, there has been some work to enable that in the SQLite FDO provider as w=
ell.
As far as regular queries, the FDO provider is measurably and significantly=
faster than the SQLite core engine by itself. Overall, I think the databas=
e format specified in RFC16 is superior in that it corresponds closely to t=
he OGC SQL spec and performs well, but then again I am a little bit biased.
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:x="urn:schemas-microsoft-com:office:excel" \
xmlns:p="urn:schemas-microsoft-com:office:powerpoint" \
xmlns:a="urn:schemas-microsoft-com:office:access" \
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" \
xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" \
xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" \
xmlns:b="urn:schemas-microsoft-com:office:publisher" \
xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" \
xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" \
xmlns:odc="urn:schemas-microsoft-com:office:odc" \
xmlns:oa="urn:schemas-microsoft-com:office:activation" \
xmlns:html="http://www.w3.org/TR/REC-html40" \
xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" \
xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" \
xmlns:Repl="http://schemas.microsoft.com/repl/" \
xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" \
xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" \
xmlns:ppda="http://www.passport.com/NameSpace.xsd" \
xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" \
xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" \
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" \
xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" \
xmlns:udc="http://schemas.microsoft.com/data/udc" \
xmlns:xsd="http://www.w3.org/2001/XMLSchema" \
xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" \
xmlns:ec="http://www.w3.org/2001/04/xmlenc#" \
xmlns:sp="http://schemas.microsoft.com/sharepoint/" \
xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" \
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \
xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" \
xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" \
xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" \
xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" \
xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" \
xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" \
xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" \
xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" \
xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" \
xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" \
xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" \
xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" \
xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" \
xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" \
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=WordSection1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Jason,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Traian<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> \
fdo-users-bounces@lists.osgeo.org [mailto:fdo-users-bounces@lists.osgeo.org] <b>On \
Behalf Of </b>Jason Birch<br> <b>Sent:</b> Wednesday, September 01, 2010 4:25 PM<br>
<b>To:</b> FDO Users Mail List<br>
<b>Subject:</b> Re: [fdo-users] new King.SpatiaLite FDO \
Provider<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>Hey Traian,<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<p class=MsoNormal>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.<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Jason<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>On 1 September 2010 07:26, Traian Stanev wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
fdo-users mailing list
fdo-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users
--===============1268432984==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic