Is solr 4.0 ready for prime time? (or other ways to use geo distance in search)

[Alex Thurlow <al...@blastro.com>]

Hi all,
     I've been using solr 1.4 and it's working great for what I'm 
doing.  However, I'm now finding a need to filter results by location.  
Searching around, I see that the distance functions are implemented in 
solr 4.0, but there's no full release yet.

So my question is, is solr 4.0-dev ready to be used in prime time?  My 
other option would appear to be using the cartesian distance, which 
isn't totally accurate, but it probably good enough for my purposes.  
Something like including this in my filter query: 
sum(pow(sub(input_latitiude,stored_latitude),2),pow(sub(input_longitude,stored_longitude),2))<degrees 
distance filter

What's anyone else out there using?

Thanks in advance,
Alex

Re: Is solr 4.0 ready for prime time? (or other ways to use geo distance in search)

[Estrada Groups <es...@gmail.com>]

I tried to build yeaterdays svn trunk of 4.0 and got massive failures... The Hudson zipped up version seems to work without any issues. Has anyone else seem this build issue on the Mac? I guess this also has to do with Grants recent poll...

Adam


On Jan 22, 2011, at 6:34 AM, Robert Muir <rc...@gmail.com> wrote:

> On Fri, Jan 21, 2011 at 11:53 PM, Lance Norskog <go...@gmail.com> wrote:
>> The Solr 4 branch is nowhere near ready for prime time. For example,
>> within the past week code was added that forces you to completely
>> reindex all of the documents you had. Solr 4 is really the "trunk".
>> The low-level stuff is being massively changed to allow very big
>> performance improvements and new features.
> 
> Changing the index format is not a sign of instability, we did this to
> improve performance. So, changing the index format is in no way a bad
> sign, nor indicative of whether or not the trunk is good for
> production use.
> 
> You aren't forced to re-index all your documents if you are riding
> trunk -- its your decision to make that tradeoff when you type 'svn
> update'. If you want stability you can take a snapshot (e.g. nightly
> build), and just stick with it.

Re: Is solr 4.0 ready for prime time? (or other ways to use geo distance in search)

[Robert Muir <rc...@gmail.com>]

On Fri, Jan 21, 2011 at 11:53 PM, Lance Norskog <go...@gmail.com> wrote:
> The Solr 4 branch is nowhere near ready for prime time. For example,
> within the past week code was added that forces you to completely
> reindex all of the documents you had. Solr 4 is really the "trunk".
> The low-level stuff is being massively changed to allow very big
> performance improvements and new features.

Changing the index format is not a sign of instability, we did this to
improve performance. So, changing the index format is in no way a bad
sign, nor indicative of whether or not the trunk is good for
production use.

You aren't forced to re-index all your documents if you are riding
trunk -- its your decision to make that tradeoff when you type 'svn
update'. If you want stability you can take a snapshot (e.g. nightly
build), and just stick with it.

Re: Is solr 4.0 ready for prime time? (or other ways to use geo distance in search)

[Lance Norskog <go...@gmail.com>]

The Solr 4 branch is nowhere near ready for prime time. For example,
within the past week code was added that forces you to completely
reindex all of the documents you had. Solr 4 is really the "trunk".
The low-level stuff is being massively changed to allow very big
performance improvements and new features.

Solr 3.x is intended as a "stable" version: bug fixes, not much
mutation, ports of features that are proofed out on the trunk. It is
good enough for production use.

On Fri, Jan 21, 2011 at 1:37 PM, Markus Jelsma
<ma...@openindex.io> wrote:
> Hi,
>
> You can use Solr 1.4.1 and a third party plugin [1]. It does a pretty good job
> in spatial search. You could also try the Solr 3.1 branch which also has some
> spatial features on-board. It, however, does not return computed distances but
> can filter and sort using the great circle algorithm or a bounding box and also
> covers the problem of the poles.
>
> I would migrate to the 3.1 branch first and see how 4.0 behaves when it is
> being released and got a few bugfix updates.
>
> [1]: http://blog.jteam.nl/2010/12/22/ssp-2-0/
>
> Cheers,
>
>> Hi all,
>>      I've been using solr 1.4 and it's working great for what I'm
>> doing.  However, I'm now finding a need to filter results by location.
>> Searching around, I see that the distance functions are implemented in
>> solr 4.0, but there's no full release yet.
>>
>> So my question is, is solr 4.0-dev ready to be used in prime time?  My
>> other option would appear to be using the cartesian distance, which
>> isn't totally accurate, but it probably good enough for my purposes.
>> Something like including this in my filter query:
>> sum(pow(sub(input_latitiude,stored_latitude),2),pow(sub(input_longitude,sto
>> red_longitude),2))<degrees distance filter
>>
>> What's anyone else out there using?
>>
>> Thanks in advance,
>> Alex
>



-- 
Lance Norskog
goksron@gmail.com

Re: Is solr 4.0 ready for prime time? (or other ways to use geo distance in search)

[Markus Jelsma <ma...@openindex.io>]

Hi,

You can use Solr 1.4.1 and a third party plugin [1]. It does a pretty good job 
in spatial search. You could also try the Solr 3.1 branch which also has some 
spatial features on-board. It, however, does not return computed distances but 
can filter and sort using the great circle algorithm or a bounding box and also 
covers the problem of the poles.

I would migrate to the 3.1 branch first and see how 4.0 behaves when it is 
being released and got a few bugfix updates.

[1]: http://blog.jteam.nl/2010/12/22/ssp-2-0/

Cheers,

> Hi all,
>      I've been using solr 1.4 and it's working great for what I'm
> doing.  However, I'm now finding a need to filter results by location.
> Searching around, I see that the distance functions are implemented in
> solr 4.0, but there's no full release yet.
> 
> So my question is, is solr 4.0-dev ready to be used in prime time?  My
> other option would appear to be using the cartesian distance, which
> isn't totally accurate, but it probably good enough for my purposes.
> Something like including this in my filter query:
> sum(pow(sub(input_latitiude,stored_latitude),2),pow(sub(input_longitude,sto
> red_longitude),2))<degrees distance filter
> 
> What's anyone else out there using?
> 
> Thanks in advance,
> Alex