Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of billnbell@gmail.com
 designates 209.85.214.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=LzLf/7dlIr/FFtc5nNocVUWvZhYB3OFHd2/00DTvxBpczhZ0CsrIguWwX9HF4MgVP7
         +kPwZyZsUVgJ6DXN872Mu0Wy6ZZSFPN09JyQ86497+Rlqvs5n3y1IHDU1CFRZxDpqXwU
         N2bwCX5Cafs3KBeLOCWV4uYpv3zrLHWdyf5ZA=
MIME-Version: 1.0
In-Reply-To: <AANLkTimyJ4P4FVfRmmKznhVdiKM=VrsGP=zDZ33WR9RZ@mail.gmail.com>
References: 
 <504122126.13861.1301139125895.JavaMail.tomcat@hel.zones.apache.org>
	<AANLkTin1EN_xukpxrntgp3RTmvWiwr7CcTewviNYqHv6@mail.gmail.com>
	<AANLkTinN37k-iipj1OGHaNLXTnUgCQNgo7_D=8R1_ByV@mail.gmail.com>
	<AANLkTikWgnxK4yypCxL_7ZsqmhFfNOQ3LWOL-UcoqW7C@mail.gmail.com>
	<AANLkTi=80Du1zy95qFyLzXsvOULKCQynL2Md4DHB1jbQ@mail.gmail.com>
	<AANLkTik6W7+SjLossrWrO=EpBP+Lts2RX_Oemf_4r0kj@mail.gmail.com>
	<AANLkTik3cSnc8ey3MDURz8BP0mEMuiFEsK2o5T+L2ku3@mail.gmail.com>
	<AANLkTimyJ4P4FVfRmmKznhVdiKM=VrsGP=zDZ33WR9RZ@mail.gmail.com>
Date: Sat, 26 Mar 2011 22:19:26 -0600
Message-ID: <AANLkTin+hjgTvkSF1_PCpMupbK-vkidEFqAY-nK0sfd3@mail.gmail.com>
Subject: Re: [jira] [Commented] (SOLR-2155) Geospatial search using geohash
 prefixes
From: William Bell <billnbell@gmail.com>
To: dev@lucene.apache.org
Cc: Chris Male <gento0nz@gmail.com>, yonik@lucidimagination.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
Lucene.

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
points.

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.

Bill


On Sat, Mar 26, 2011 at 7:19 PM, Chris Male <gento0nz@gmail.com> wrote:
>
>
> On Sun, Mar 27, 2011 at 7:30 AM, Yonik Seeley <yonik@lucidimagination.com=
>
> wrote:
>>
>> On Sat, Mar 26, 2011 at 2:17 PM, Ryan McKinley <ryantxu@gmail.com> 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. =C2=A0To be frank, the sp=
atial
>> > support in solr is pretty hairy -- it works for some use cases, but is
>> > not extendable and quite basic. =C2=A0Calling 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 an=
d
> Lucene's spatial support, not block either. =C2=A0As you say, having a mo=
dule 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 fir=
st
> 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). =C2=A0Sounds like something that really doe=
s need
> to be openly discussed.
>
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Chris Male | Software Developer | JTeam BV.| www.jteam.nl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org