Hi Andrew

I'm afraid Sphinx only handles single address points for documents, so  
either you stick with your primary address lat/lng, or have the index  
defined on Address (yes, I know, it's not that intuitive), and then  
group results by member_id (an attribute defined for the address).  
This ensures only one result per member.

This would be a bit of a pain to set up, because there's sorting  
addresses within groups and sorting the actual groups, but it could be  
feasible, perhaps?

-- 
Pat

On 11/08/2009, at 7:51 AM, Andrew Lippert wrote:

>
> FYI - I am using :through with a hash on the index and it works
> brilliantly. Terrific job with the implementation, Pat (and team)!
>
> Fall back here is to skip the multiple address search and stick with
> the primary address lat/long if necessary. It just isn't ideal for our
> needs.
>
> On Aug 10, 11:48 pm, Andrew Lippert <[email protected]> wrote:
>> You are correct. The index is on Member. The search actually provides
>> full text capabilities on all the attributes of a member with the
>> result set limited by the geo portion of the query. So, you can find
>> all the members with 'Real Estate Agent' in their title or  
>> description
>> fields within X miles of your current location (25 miles of Seattle,
>> for example). Ideally, the search is on Member with the constraint
>> being the distance from the Addresses. I'd really hate to lose the
>> flexibility of the current index and query - the configuration was
>> drop dead simple and elegant. Turning it around would be a bit
>> cumbersome and counterintuitive.
>>
>> Andrew
>>
>> On Aug 10, 8:41 pm, James Healy <[email protected]> wrote:
>>
>>
>>
>>> I assume your index is defined on your Member class?
>>
>>> How about moving the index to the Address class? That way a geo  
>>> search
>>> will return Address instances and you can grab the member by  
>>> walking the
>>> objects.
>>
>>> I'm not sure that help with returning distinct Member's, but it  
>>> might
>>> still be a step in the right direction.
>>
>>> -- James Healy <jimmy-at-deefa-dot-com>  Tue, 11 Aug 2009 13:37:27  
>>> +1000
>>
>>> Andrew Lippert wrote:
>>
>>>> Here's one that has me stumped:
>>
>>>> Members has_many Businesses has_many Addresses (geo coded).
>>
>>>> I'd like to be able to do a geo search on members within a  
>>>> distance of
>>>> an origin point. I have successfully implemented the search using a
>>>> rolled up primary_address lat and long (rolled up to the member
>>>> record). However, that doesn't quite address the need. Ideally, the
>>>> search index would include a row for each member/business/address
>>>> which I could then do a geo search against. I would then like to
>>>> restrict the returned search result set to distinct instances of  
>>>> the
>>>> matching members. This would allow me to display the single member
>>>> record even if the geo search included two associated addresses for
>>>> the member to business to address associations.
>>
>>>> Here's a real example: One member has a business located in Seattle
>>>> and a second business located in Portland. I'd like to search for  
>>>> all
>>>> members within 25 miles of Seattle and return the member. Then do a
>>>> search within 500 miles of Seattle (which would match both address
>>>> records) but return a single instance of the member.
>>
>>>> Any idea on how to configure this index and Sphinx query?
>>
>>>> Thanks for any assistance,
>>
>>>> Andrew Lippert
>>>> CTO Biznik
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/thinking-sphinx?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to