I think moving the RTree to the generic collections would not be too hard. I saw Saikat showed interested in doing this himself.
Saikat, contact me off-list for further details on what I think could be done to make this port. On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen <pd_aficion...@hotmail.com>wrote: > > Peter, I totally agree. Having the Rtree index removed of spatial > dependencies in graph-collections should be our first priority. Once that is > done we can focus on the other issues. > Which doesn't mean we should stop discussing future improvements like > setting up comparators (or something to that extent) that can be reusable, > but we shouldn't try to get that up before Rtree is in graph-collections. > Niels > > > From: peter.neuba...@neotechnology.com > > Date: Wed, 29 Jun 2011 21:10:15 +0200 > > To: user@lists.neo4j.org > > Subject: Re: [Neo4j] neo4j-graph-collections > > > > Craig, > > just gave you push access to the graph collections in case you want to > > do anything there. > > > > Also, IMHO it would be more important to isolate and split out the > > RTree component from Spatial than to optimize it - that could be done > > in the new place with targeted performance tests later? > > > > Cheers, > > > > /peter neubauer > > > > GTalk: neubauer.peter > > Skype peter.neubauer > > Phone +46 704 106975 > > LinkedIn http://www.linkedin.com/in/neubauer > > Twitter http://twitter.com/peterneubauer > > > > http://www.neo4j.org - Your high performance graph > database. > > http://startupbootcamp.org/ - Öresund - Innovation happens HERE. > > http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. > > > > > > > > On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen > > <pd_aficion...@hotmail.com> wrote: > > > > > > Craig, > > > Would it be possible to merge your work on Amanzi with the work the Neo > team has done on the Btree component that is now in neo4j-graph-collections, > so we can eventually have one implementation that meets a broad variety of > needs? > > > Niels > > > > > >> Date: Wed, 29 Jun 2011 15:34:47 +0200 > > >> From: cr...@amanzi.com > > >> To: user@lists.neo4j.org > > >> Subject: Re: [Neo4j] neo4j-graph-collections > > >> > > >> I have previously used two solutions to deal with multiple types in > btrees: > > >> > > >> - My first index in 2009 was a btree-like n-dim index using > generics to > > >> support int[], long[], float[] and double[] (no strings). I used > this for > > >> TimeLine (long[1]) and Location (double[2]). The knowledge about > what type > > >> was used was in the code for constructing the index (whether a new > index or > > >> accessing an existing index in the graph). > > >> - In December I started my amanzi-index (on > > >> github<https://github.com/craigtaverner/amanzi-index>) > > >> that is also btree-like, n-dimensional. But this time it can index > multiple > > >> types in the same tree (so a float, int and string in the same > tree, instead > > >> of being forced to have all properties of the same type). It is a > re-write > > >> of the previous index to support Strings, and mixed types. This > time it does > > >> save the type information in meta-data at the tree root. > > >> > > >> The idea of using a 'comparator' class for the types is similar, but > simpler > > >> than the idea I implemented for amanzi-index, where I have mapper > classes > > >> that describe not only how to compare types, but also how to map from > values > > >> to index keys and back. This includes (to some extent) the concept of > the > > >> lucene analyser, since the mapper can decide on custom distribution > of, for > > >> example, strings and category indexes. > > >> > > >> For both of these indexes, you configure the index up front, and then > only > > >> call index.add(node) to index a node. This will fit in well with the > new > > >> auto-indexing ideas in neo4j. > > >> > > >> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen > > >> <pd_aficion...@hotmail.com>wrote: > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > At this moment Btree only supports the primitive datatype long, > while Rtree > > >> > only supports the datatype double. For Btree it makes sense to at > least > > >> > support strings, floats, doubles and ints too. Use cases for these > data > > >> > types are pretty obvious and are Btree backed in (almost) every > RDBMS > > >> > product around.I think the best solution would be to create > Comparator > > >> > objects wrapping these primitive data types and store the class name > of the > > >> > comparator in root of the index tree. This allows users to create > their own > > >> > comparators for datatypes not covered yet. It would make sense > people would > > >> > want to store BigInt and BigDecimal objects in a Btree too, others > may want > > >> > to store dates (instead of datetime), fractions, complex numbers or > even > > >> > more exotic data types. > > >> > Niels > > >> > > From: sxk1...@hotmail.com > > >> > > To: user@lists.neo4j.org > > >> > > Date: Tue, 28 Jun 2011 22:43:24 -0700 > > >> > > Subject: Re: [Neo4j] neo4j-graph-collections > > >> > > > > >> > > > > >> > > I've read through this thread in more detail and have a few > thoughts, > > >> > when you talk about type I am assuming that you are referring to an > > >> > interface that both (Btree,Rtree) can implement, for the data types > I'd like > > >> > to understand the use cases first before implementing the different > data > > >> > types, maybe we could store types of Object instead of Long or > Double and > > >> > implement comparators in a more meaningful fashion. Also I was > wondering > > >> > if unit tests would need to be extracted out of the spatial > component and > > >> > embedded inside the graph-collections component as well or whether > we'd > > >> > potentially need to write brand new unit tests as well. > > >> > > Craig as I mentioned I'd love to help, let me know if it would be > > >> > possible to fork a repo or to talk in more detail this week. > > >> > > Regards > > >> > > > > >> > > > From: pd_aficion...@hotmail.com > > >> > > > To: user@lists.neo4j.org > > >> > > > Date: Wed, 29 Jun 2011 01:35:43 +0200 > > >> > > > Subject: Re: [Neo4j] neo4j-graph-collections > > >> > > > > > >> > > > > > >> > > > As to the issue of n-dim doubles, it would be interesting to > consider > > >> > creating a set of classes of type Orderable (supporting <, <=, >, >= > > >> > operations), this we can use in both Rtree and Btree. Right now > Btree only > > >> > supports datatype Long. This should also become more generic. A > first step > > >> > we can take is at least wrap the common datatypes in Orderable > classes. > > >> > > > Niels > > >> > > > > > >> > > > > Date: Wed, 29 Jun 2011 00:32:15 +0200 > > >> > > > > From: cr...@amanzi.com > > >> > > > > To: user@lists.neo4j.org > > >> > > > > Subject: Re: [Neo4j] neo4j-graph-collections > > >> > > > > > > >> > > > > The RTree in principle should be generalizable, but the > current > > >> > > > > implementation in neo4j-spatial does make a few assumptions > specific > > >> > to > > >> > > > > spatial data, and makes use of spatial envelopes for the tree > node > > >> > bounding > > >> > > > > boxes. It is also specific to 2D. We could make a few > improvements > > >> > first, > > >> > > > > like generalizing to n-dimensions, replacing the recursive > search > > >> > with a > > >> > > > > traverser and generalizing the bounding boxes to be simple > > >> > double-arrays. > > >> > > > > Then the only thing left would be to decide if it is ok for it > to be > > >> > based > > >> > > > > on n-dim doubles or should be generalized to more types. > > >> > > > > > > >> > > > > On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal < > > >> > sxk1...@hotmail.com>wrote: > > >> > > > > > > >> > > > > > I would be interested in helping out with this, let me know > next > > >> > steps. > > >> > > > > > > > >> > > > > > Sent from my iPhone > > >> > > > > > > > >> > > > > > On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen < > > >> > pd_aficion...@hotmail.com> > > >> > > > > > wrote: > > >> > > > > > > > >> > > > > > > > > >> > > > > > > A couple of weeks ago Peter Neubauer set up a repository > for > > >> > in-graph > > >> > > > > > datastructures: > https://github.com/peterneubauer/graph-collections > > >> > . > > >> > > > > > > At this time of writing only the Btree/Timeline index is > part of > > >> > this > > >> > > > > > "component". > > >> > > > > > > In my opinion it would be interesting to move the Rtree > parts of > > >> > > > > > neo-spatial to neo4j-graph-collections too. > > >> > > > > > > I looked at the code but don't feel competent to seperate > out > > >> > those > > >> > > > > > classes that support generic Rtrees from those classes that > are > > >> > clearly > > >> > > > > > spatial related. > > >> > > > > > > Is there any enthusiasm for such a project and if so, who > is > > >> > willing and > > >> > > > > > able to do this? > > >> > > > > > > Niels > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > _______________________________________________ > > >> > > > > > > Neo4j mailing list > > >> > > > > > > User@lists.neo4j.org > > >> > > > > > > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > > > > > > >> > > > > > _______________________________________________ > > >> > > > > > Neo4j mailing list > > >> > > > > > User@lists.neo4j.org > > >> > > > > > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > > > > > >> > > > > _______________________________________________ > > >> > > > > Neo4j mailing list > > >> > > > > User@lists.neo4j.org > > >> > > > > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > > > >> > > > _______________________________________________ > > >> > > > Neo4j mailing list > > >> > > > User@lists.neo4j.org > > >> > > > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > > >> > > _______________________________________________ > > >> > > Neo4j mailing list > > >> > > User@lists.neo4j.org > > >> > > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > >> > > > >> > _______________________________________________ > > >> > Neo4j mailing list > > >> > User@lists.neo4j.org > > >> > https://lists.neo4j.org/mailman/listinfo/user > > >> > > > >> _______________________________________________ > > >> Neo4j mailing list > > >> User@lists.neo4j.org > > >> https://lists.neo4j.org/mailman/listinfo/user > > > > > > _______________________________________________ > > > Neo4j mailing list > > > User@lists.neo4j.org > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
