Howard, thanks for your answer!
Am 17.06.2010, 03:57 Uhr, schrieb Howard Butler <[email protected]>:
I'd like to create a custom storage manager for rtree 0.6.0 on Windows
which saves the page data in a database (ZODB).
Here are the funcs I need:
http://svn.gispython.org/svn/spatialindex/spatialindex/trunk/src/storagemanager/MemoryStorageManager.h
.
How to do this on the C++ side:
- Create a "generic storage manager" class in libspatialindex
- This "generic storage manager" is very simple: it takes three function
pointers for the load/store/deleteByteArray functions. It just calls these
function pointers.
- On the python side I use ctypes to create these functions pointers (
http://docs.python.org/library/ctypes.html#callback-functions ). Then I
instantiate a "generic storage manager" object and pass these function
pointers to it.
- Now when GenericStorageManager::loadByteArray is called, it calls the
function pointer which will end up in python where I can do anything I
want with the data.
I am not very keen on maintaining my own branch of libspatialindex.
If I supply the generic storage manager (which is even simpler than the
MemoryStorageManager and it does not introduce any dependencies) as well
as the required ctypes code, are you willing to include this into the
mainline distribution? It might be useful for other people as well as you
can interface with any python storage.
I know a bit about libspatialindex's storage managers, and I don't know
squat about ZODB internals. I would estimate a boatload of time and
money to do this, as there are many unknown unknowns, in rumsfeldian
parlance. If you're serious about it, I would bone up on ZODB or hunt
down a ZODB jock and get them up to speed on libspatialindex. It's
going to be easier to find help that way than learning up a
spatialindexing guy on ZODB.
I'm pretty sure I know how to hook this up with ZODB. It's quite simple
actually and would allow ZODB to get spatial indices. For rtree users this
means you can store arbitrary python objects indexed by their location in
a remotely accessible, transactional database. With the implementation
proposed above it would be just as easy to hook up with MySQL or any other
kind of database or storage.
What does storing index pointers and pages in ZODB get you that the file
storage mechanism by itself doesn't, and is it really worth that cost?
It's hard to explain this in a single sentence or two. ZODB is an object
database and I gain many advantages from this. The cost is not that big at
all.
My naive view is that it only gets you single file storage, but with
bulk loading now available through Python, I think you can treat the
index file(s) as throw away for the most part (easily recreateable
without too much cost). Another giant dragon is libspatialindex still
has a few thread safety issues, and if threading is an issue in ZODB,
you're going to run into them. In short, do you *really* want this? ;)
I don't use threading at this stage and don't intend to at this point. If
I should ever need threading, I am going to put locks around any calls to
libspatialindex/rtree.
So yes, I really want this! :-)
-Matthias
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
