Hi Michaël, Yes I talked with Marios and the Java implementation is far from the C one, he also gave me some advice to go on with the job but I have had no time to do anything.
About having the index in memory... I agree with you that big dbms don't load it in memory to work (not fully at least). For example I think you can read from the root to one leave with on disk access for each "level" storing in memory only the contents of the node being read. I'm sure there are better improvements. Also, I think that those disk accesses are very small (in most of the cases) compared with the speed up obtained by using an index in an algorithm... Fernando On 9/28/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > > Hi Fernando, > > I have tried to use Marios Hadjieleftheriou's java implementation of > RTree a few years ago. > It seemed to me that it was a complete library (with capabilities to > persist the tree structure and many other options). > The library was quite difficult to use compared to JTS's quadtree and > RTree, but had more options. > The author is going on developping a C++ version but seems to have > stopped the java version. > I'm not a database specialist and I can't understand how a full index > can be held in a database and always accessed for queries without > killing performance. That's why I imagined that the tree structure had > to be held in memory. But I'm sure there are solutions as other > non-spatial indexes are usually held in the database and just improve > performance :-) . > > Hope we'll get a chance to incorporate GDBMS into OpenJUMP. > > Michaël > > > Fernando Gonzalez a écrit : > > > Maybe this is of your interest. Here > > <http://geosysin.iict.ch/irstv-trac/> (sorry the page is not available > > this weekend) we are developing an interface to manage different data > > sources called GDMS. We have been able to work with shapefiles very > > efficiently (in time and in memory consumption). It will be released > > the 12th of October with access to Shapefile, postGIS and more > > formats. I think it's worth to give it a try. > > > > In this project we also want to have a spatial index to increase > > performance and we currently use Quadtree (that's why I am in this > > list). For big data sets have the index in memory is not the best > > solution so we want a disk based implementation. We have tried to > > serialize the Quadtree to disk > > <http://lists.jump-project.org/pipermail/jts-devel/2007-June/001958.html > > > > but the result is ssssslooooow and you need it in memory when you use > it. > > > > Now we are looking for a index based implementation. We don't know yet > > if it will be a solution from scratch or reusing some code. So far I > > have only found this > > < > http://www.rtreeportal.org/index.php?option=com_content&task=view&id=17&Itemid=32 > >. > > No ready-to-use work I think. > > > > Summarizing: in gdms we have nothing but in two months we will have > > memory friendly implementation. The interface will be pretty like > > indexes in JTS. I'm interested in any work in this direction so don't > > hesitate to contact me. > > > > greetings, > > Fernando > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >jts-devel mailing list > >[email protected] > >http://lists.refractions.net/mailman/listinfo/jts-devel > > > > > > _______________________________________________ > jts-devel mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jts-devel >
_______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
