<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:m="http://schemas.microsoft.com/office/2004/12/omml" 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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite</title>
<style>
<!--
/* Font Definitions */
@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;}
/* 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;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</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=Section1>
<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:10.0pt;font-family:"Arial","sans-serif"'>Yes,
we can have some code that generates a spatial index which is serialized
alongside the .db file. The same code that OGR uses for Shape would likely work
equally well for SQLite (when fitted with an interface to read geometry from
SQLite rather than SHP).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>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>
<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-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Jason Birch<br>
<b>Sent:</b> Wednesday, March 19, 2008 12:21 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div id=idOWAReplyText96368>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>Heh.</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>I
guess it doesn't really matter to me whether this is implemented at
the provider's discretion or is specified as part of the format, as
long as it's done in a way that the .db files can be used as-shipped. I'm
hoping that this can be an operational format that is easily interchanged, like
SHP. SHP's indices are provider-specific too, so I guess it's not a huge
issue.</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Frank
mentioned that on-the-fly indexing isn't a good fit with
short-lifetime programs like MapServer when in CGI mode, but I guess that
a tool could be delivered with the OGR provider to create and persist an
index in the database, which could then be used for reading by the OGR
provider. I think there's already something like this for shapefiles in
MapServer?</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>I
think I like that X/Y implementations are not stored in the geometry_columns
table. Doesn't make it required for the specification, but helps out FDO
users that may want to map simple X/Y columns. Kind-of like the position
of W3C geometry within the GeoRSS spec.</span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Jason</span><span
style='font-size:10.0pt;color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div class=MsoNormal align=center style='text-align:center'>
<hr size=2 width="100%" align=center>
</div>
<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"'> Traian Stanev<br>
<b>Subject:</b> RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite<br>
</span><span style='font-size:10.0pt'><br>
The conversion between WKB and FGF is not expensive at all, but it does add up
if you are reading a million features in a hurry.<br>
<br>
Adding spatial index to SQLite would be like jamming a helicopter into the
proverbial Miata, and expecting some sort of an improvement. :-)<br>
<br>
If this is an interchange format, why do you need to store a spatial index in
there? It would only make the file bigger? Spatial indexes are very fast to
generate on the fly, so why carry one around with you? It would also force a
single spatial index algorithm on people, which they have to implement on
clients that wish to use it -- using a spatial index implies quite a bit of
client code that knows how to make sense out of it. It makes more sense to have
one persisted when the database is not as mobile as SQlite is. I'm not trying
to be a naysayer, just want to understand the reasoning behind having an integrated
spatial index.<br>
<br>
Oh, I just updated the RFC to reflect the geomtry_columns and spatial_ref_sys
thing.<br>
<br>
Traian</span><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>