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 subshapes, 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 <
lucene@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
> <yonik@lucidimagination.com> wrote:
> > On Tue, Dec 29, 2009 at 7:13 PM, Marvin Humphrey <marvin@rectangular.com>
> wrote:
> >> ... but for this algorithm, different rasterization resolutions need not
> >> proceed by powersoftwo.
> >
> > Indeed  one way to further generalize would be to use something like
> > Lucene's triebased Numeric field, but with a square instead of a
> > line. That would allow to tweak the space/speed tradeoff.
> >
> > Yonik
> > http://www.lucidimagination.com
> >
>
