Hi Kiran. The often-forgotten PointType field type can be configured to hold a variable number of dimensions. See the "dimension" attribute of the field type's configuration in the example schema. This field type is really just a kind of a macro field type for a configurable number of numeric fields. To do a range search you could do: myPointField:[x1,y1,z1 TO x2,y2,z2] (3 dimensional). This works identically to AND'ing together a series of range searches on number fields you explicitly configure. If the space you want to search isn't a simple set or ranges on the dimensions, then you might be stuck or at least forced to code a solution, but the scalability of any solution is very unlikely to be very scalable (i.e. if you have a ton of data this may be a problem). There are some function-queries (AKA ValueSources) that compute special distance calculations in N-dimensional space: http://wiki.apache.org/solr/FunctionQuery#dist dist(), hsine() and sqedist() can take a PointType or you can configure each numeric field individually and reference them as seen on the wiki. One key limitation of PointType (and LatLonType) is that it does not support multi-valued fields (no multiple values for any dimension per document).
You linked to info on "K-D Trees". Lucene internally at its essence has *one* index scheme, which is a sorted list of bytes (often tokenized words in text but can be any bytes) that map to a list of document ids. There are a class of trees in computer science called a "Trie" AKA "PrefixTree" that are fundamentally based on just sorted keys. http://en.wikipedia.org/wiki/Trie Lucene's single-dimensional numeric range fields are in fact tries; they can store a variable number of single-dimensional values per document. For 2-dimensional spatial, there is the SpatialPrefixTree abstraction with Geohash and QuadTree implementations. These support not just indexing Points but any Spatial4j shape, which is approximated to the grid. Supporting an N-dimensional Trie would require writing a custom SpatialPrefixTree. The spatial RecursivePrefixTreeStrategy has spatial search algorithms that use a SpatialPrefixTree but makes no assumptions about the dimensionality of the tree or related shapes, so no change there (pretty cool, I think). You would need to implement some N-dimensional Spatial4j shapes. An n-dimensional Point -- trivial. A multi-dimensional range shape (i.e. a square or cube or ...) is not hard. Anything more complex in N dimensions is going to get hard fast. Finally, there needs to be a way to parse this shape, which for a custom hack could simply be a Solr QParser but longer term would be Spatial4j's not yet finished extensible WKT parser. That was probably more info than you care for but someone else may read this and find it interesting. Kiran, I'm curious, what do you want an n-dimensional field for? p.s. A new SpatialPrefixTree implementation is slated to be developed this summer as part of the Google Summer of Code (GSOC). I hadn't planned to add N-dimensionality to the feature list. It could be a stretch-goal maybe. https://issues.apache.org/jira/browse/LUCENE-4922 ~ David Kiran Jayakumar wrote > Hi, > > Does Solr support multi dimensional spatial search ? > > http://en.wikipedia.org/wiki/K-d_tree > > Thanks ----- Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Multi-dimensional-spatial-search-tp4062515p4062646.html Sent from the Solr - User mailing list archive at Nabble.com.
