lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Bell <>
Subject Re: [jira] [Commented] (SOLR-2155) Geospatial search using geohash prefixes
Date Sun, 27 Mar 2011 04:19:26 GMT
Maybe I am too close to this issue and not looking at global
implications like you are....

SOLR-2155 seems fairly close to "good to go". There are a couple open
issues that David Smiley has been asking for input on.
I would recommend we answer those questions, and commit it. Then we
can look at modules, etc.

If a rewrite was on the works, a committer should have said something
a LONG time ago. Like back in October or something. Are we talking
redesign or refactoring? I think core spatial things should remain in

Even though Spatial support in 3.1 is basic it is stable, and VERY
fast. We ran regression tests and the performance was 10-100x faster
than the plugin solution of Solr Spatial from Patrick. Whatever fancy
support for polygons, etc we support it needs to be even faster than
what we have with 3.1.

What I like about this patch more than anything is the support for
multiple-lat longs per document. I have several clients who need this
feature. For example, one doctor with multiple offices. It would be
nice if a committer would work with David Smiley to get this done.

1. We would like to know if the pole issue can be solved and how.
2. We would like to know the best way to support the multi lat long
(without the copy happening) and get the values from multigeodist(). I
have pushed up a good example, and I would like someone to please
comment and maybe even show me some code to do that. There has been
some discussions on this issue - my solution uses VS and it is fast.
There might be faster and more simple ways to handle the N number of

On another note, it is frustrating when David and I put in some time
on this, and it sits out there with us "begging" for a committer to
assist, and then when Grant starts discussions, it is summarility
discarded with a new design without any input from the original
contributors? Is this how we want to do things here?

We should have Grant or Yonik work with David to get this patch done,

Then we can discuss Spatial V2 and the design of it.


On Sat, Mar 26, 2011 at 7:19 PM, Chris Male <> wrote:
> On Sun, Mar 27, 2011 at 7:30 AM, Yonik Seeley <>
> wrote:
>> On Sat, Mar 26, 2011 at 2:17 PM, Ryan McKinley <> wrote:
>> >>>
>> >>> No, the question is: what justification is there for adding spatial
>> >>> support to solr-only, leaving lucene with a broken contrib module,
>> >>> versus adding it where it belongs and exposing it to solr?
>> >>
>> >> There need not be any linkage to lucene to improve a Solr feature.
>> >> If you disagree, we should vote to clarify - this is too important
>> >> (and too much of a negative for Solr).
>> >>
>> >
>> > I don't think there is *requirement* to move the core spatial stuff to
>> > lucene, but I think there is huge benefit to both communities if
>> > things have as few dependencies as possible.  To be frank, the spatial
>> > support in solr is pretty hairy -- it works for some use cases, but is
>> > not extendable and quite basic.  Calling it 'distance' seems more
>> > appropriate then 'spatial'
>> Having something basic that works (and has a clean enough high level
>> HTTP interface) was clearly a win for Solr users.
>> Of course a more fully featured spatial module would be a win for
>> everyone, but that's ignoring the more generic issue at hand here:
>> a patch that improves Solr's spatial
>> should not be blocked on the grounds that it does not improve Lucene's
>> spatial enough.
> I don't think we need to see it that way, we want to improve both Solr and
> Lucene's spatial support, not block either.  As you say, having a module is
> a win for everyone, Solr and Lucene alike, so it seems obvious that we
> should go down that path and the code in SOLR-2155 would make a great first
> addition.
>> Likewise, the ridiculous notion that "Queries don't belong in Solr"
>> needs to be put to rest.
> Issues in and around this seem to be coming up a lot these days (I'm
> thinking FunctionQuerys too).  Sounds like something that really does need
> to be openly discussed.
>> -Yonik
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Chris Male | Software Developer | JTeam BV.|

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message