George Ionescu wrote:
Hello Noel,
Hello George
I'm reposting this message because I have the feeling that you missed the
original one.
I don't plan to replace the normal indexing, I plan to have a set of
function to create a (memory ?) index. But how do I retrieve the data
without doing a select where rowid = xxx ?
If you're going to create a memory index, than this will be no sqlite
spatial index extension: I'm already doing this now by selecting records
from a table and creating an in-memory spatial index.
the question is how to select in a table when you have a set of keys, I
think that I have a path now, but I have to check that
I don't know whether by coincidence or not, dr. Hipp has just published a
wiki page regarding Virtual Tables which might do the trick, and although
it's in very incipient stage (e.g. proposal) it sounds interesting. Go check
it out at http://www.sqlite.org/cvstrac/wiki?p=VirtualTables.
yes we need temporary table for that, that was the missing link, I'll
check what virtual table is, but I suppose that it has to do with the
TABLE() sql statement.
I must confess that I'm a little tired right now and I cannot see the
Virtual Table's application in Spatial Indexes :-) Perhaps tomorrow morning
my luck will change and I'll be enlightened.
And another think, regarding your second wannado:
2 - to be able to load and exchange data from WKT (well know text
format) and binary (shape file for instance)
I don't know / think whether this extension should / must be able to read an
ESRI shape. You should design your extension carefully with a pluggable way
of doing readers/writers. This way, if anyone needs to work with a special
format he/she could write it if it doesn't exist.
I was saying that because I already do it, using shapelib, and shape
files are a de facto standard.
I'm saying that because, for example, I've chosen to use an SVG-style
notation for storing my gis elements.
George.
--
Noël Frankinet
Gistek Software SA
http://www.gistek.net
