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

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

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
<[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]

On Fri, Jan 21, 2011 at 11:53 PM, Lance Norskog <[EMAIL PROTECTED]> 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.

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 <[EMAIL PROTECTED]> wrote:

> On Fri, Jan 21, 2011 at 11:53 PM, Lance Norskog <[EMAIL PROTECTED]> 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.