Thank you for the excellent explanation David. My use case is in the signal processing area. I have a wave that is in time domain & it is converted to frequency domain on 8 different bands (FFT) ie, an 8D point. The question for me is "If I have a set of waves (8D points) in the database and I have a lookup wave, what is the best match ?"
On Sat, May 11, 2013 at 10:42 PM, David Smiley (@MITRE.org) < dsmi...@mitre.org> wrote: > 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. >
