[fdo-internals] FDO RFC 16 - FDO Provider for SQLite

[Traian Stanev]

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).


Traian



From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, March 19, 2008 12:21 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite

Heh.

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.

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?

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.

Jason

________________________________
From: Traian Stanev
Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite

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.

Adding spatial index to SQLite would be like jamming a helicopter into the proverbial Miata, and expecting some sort of an improvement. :-)

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.

Oh, I just updated the RFC to reflect the geomtry_columns and spatial_ref_sys thing.

Traian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080319/deacd4f4/attachment.html