lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "patrick o'leary" <>
Subject Re: [spatial] Cartesian "Tiers" nomenclature
Date Wed, 30 Dec 2009 16:49:50 GMT
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
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 <> 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
> <> wrote:
> > On Tue, Dec 29, 2009 at 7:13 PM, Marvin Humphrey <>
> 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
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message