On Thu, Jun 17, 2010 at 4:41 AM, Nitro <[email protected]> wrote: > 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
Are you talking about opaque blob storage or tree nodes using containers? The structure of an R-Tree has some resemblance to physical reality and Python access to it could be very useful. Cheers, -- Sean Gillies Programmer Institute for the Study of the Ancient World New York University _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
