Actually that's just with the DistanceQueryBuilder that needs the precision boolean (wheither to do just a bounding box or also filter on radius), the original name of the project was locallucene, to me local and spatial are 2 completely different things.
- Local is a search from point x within y miles. (hence the radius filter) - Spatial on the other hand is well everything else. I have yet to update the repository with that code, but a working example of what I see spatial as is http://www.knowledgenowsystems.com/polySpatialSolrUI/ The polygon tool works better than the line tool, you have to double click the link to get it to kick off a search. But essentially it's capable of taking almost arbitrary shapes and just doing convex hull searching or line string searching. Future work would include sorting based upon proximity to a point, so you don't just get a bag of results back, you can say starting at point x give me all the closest ones along this line or within this shape (trajectory sort? in my mind), then an edge proximity search would be closest to this line / vertex. After that I think determining sub-shapes, where your search vertexes cross each other, determine the point of intersection and create smaller shapes from the pieces around it. There's a whole bunch more i plan on getting in there. Including a new SRID based on beer mat diagrams with Ryan on having a prefixed id, that doesn't require additional fields, and can stop descending once a shape has been fully enveloped, reducing the number of terms within an index. On Wed, Dec 30, 2009 at 4:01 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > Right, NRQ is able to translate any requested range into the union > (OR) of brackets (from the trie) created during indexing. > > Can spatial do the same thing, just with 2D instead of 1D? Ie, > reconstruct any expressible shape (created at query time) as the union > of some number of grids/tiers, at finer & finer levels, created during > indexing? > > Spatial, today, seems to do this, except it must also do "precise" > filtering on each matching doc, because some of the grids may contain > hits outside of the requested shape. > > In fact, NRQ could also borrow from spatial's current approach -- ie, > create the union of some smallish number of coarse brackets. Some of > the brackets will fall entirely within the requested range, and so > require no further filtering, while others will fall part inside / > part outside of the requested range, and so will require precise > filtering. If NRQ did this, it should have much fewer postings to > enum, at the cost of having to do precise filtering on some of them > (and we'd have to somehow encode the orig value in the index). > > Mike > > On Tue, Dec 29, 2009 at 8:42 PM, Yonik Seeley > <yo...@lucidimagination.com> wrote: > > On Tue, Dec 29, 2009 at 7:13 PM, Marvin Humphrey <mar...@rectangular.com> > wrote: > >> ... but for this algorithm, different rasterization resolutions need not > >> proceed by powers-of-two. > > > > Indeed - one way to further generalize would be to use something like > > Lucene's trie-based Numeric field, but with a square instead of a > > line. That would allow to tweak the space/speed tradeoff. > > > > -Yonik > > http://www.lucidimagination.com > > >
