Distance in sunspot 1.2

12 views
Skip to first unread message

Ionatan Wiznia

unread,
Nov 10, 2010, 12:21:58 PM11/10/10
to Sunspot
Hi! I'm trying to use sunspot in a project I'm working on, and I have
a few questions/problems:
1) When I query with something like: with(:coordinates).near(36.8365,
-2.4606, :precision => 6) the distance is not being sent in the
response from solr.
2) As I understand, that spatial query is transalted to: "fl=*
+score&start=0&q=coordinates_ss:eyw381bhpv79^1.0+OR
+coordinates_ss:eyw381bhpv7*^0.0625+OR
+coordinates_ss:eyw381bhpv*^0.00391+OR
+coordinates_ss:eyw381bhp*^0.000244+OR
+coordinates_ss:eyw381bh*^0.0000153+OR
+coordinates_ss:eyw381b*^0.000000954+OR
+coordinates_ss:eyw381*^0.0000000596&wt=ruby&fq=type:PostalCode&rows=30".
Is this using the solr-spatial-light plugin? As far as I read the
spatial plugin expects de spatial parameter.
3) I need to do something that I don't know if is possible. Each of my
documents have the coordinate and a radius. Is it possible to query
all documents whose distance from a given point is less than that
radius? (aka all the documents that enclose this point in it's
radius).

I'm using sunspot 1.2 with the solr-spatial-light-0.0.6.jar
Thanks in advance!

Mat Brown

unread,
Nov 10, 2010, 12:37:08 PM11/10/10
to ruby-s...@googlegroups.com
Howdy,

1) Sunspot 1.2 no longer uses solr-spatial-light, but instead uses a
geohash matching query to take advantage of Solr's fulltext
capabilities for spatial search. This approach does not yield
distances at all, so your best bet is to just do the calculations at
the application layer.
2) See above -- 1.2 no longer uses solr-spatial-light
3) Not with Sunspot's existing capabilities, although you may be able
to hand-roll something using geohashes that does what you need.

Mat

> --
> You received this message because you are subscribed to the Google Groups "Sunspot" group.
> To post to this group, send email to ruby-s...@googlegroups.com.
> To unsubscribe from this group, send email to ruby-sunspot...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ruby-sunspot?hl=en.
>
>

Ionatan Wiznia

unread,
Nov 10, 2010, 1:13:31 PM11/10/10
to Sunspot
Ok, just to clarify something.
It appears that the new implementation of the location type,
translates that to a geohash. I don't see how solr-spatial-light can
use this data, I think it only accepts trie doubles for lat lng.
If I specify a lat and lng field (not with the location type) and I
query directly to solr with something like: "q=*:*&spatial={!
radius=0.9}lat:36.8365,lng:-2.4606" it seems to work fine. The
distances are returned and the filter seems to work OK. Also, if I use
the method used by 1.2 (with the geohashes) and add &spatial=lat:
36.8365,lng:-2.4606 seems to retrieve the distances, although I'm not
sure if this is OK or not.
So the question is, what is the problem here? Should I use an earlier
and more stable version of sunspot, maybe 1.1?

Ionatan Wiznia

unread,
Nov 10, 2010, 1:24:30 PM11/10/10
to Sunspot
Sorry, just read your message...
So...
Is this implementation better or worse than using the plugin? Why the
change?
Can I query with a bounding box (all points inside a box)?

Mat Brown

unread,
Nov 10, 2010, 1:24:54 PM11/10/10
to ruby-s...@googlegroups.com

Sorry if my previous email wasn't clear. Sunspot 1.2 made a conscious decision to stop using solr-spatial-light because we determined that the plugin has serious performance problems at scale. Instead, it uses a geohash-based spatial search that relies only on Solr's built-in fulltext search capabilities; this is considerably more performant and has the added bonus of allowing result scoring to account for both fulltext relevance and geographical proximity in searches that include both components.

Geohash search is not without its downsides: in particular, distance-based filtering and ordering is approximate and can behave badly in edge cases. Nick Zadrozny is working on refining the geohash query logic to take care of the edge cases, but geohash-based search will necessarily never be completely accurate. It is performant at scale precisely because it does not actually calculate distances from the search origin to each document in the index; that's why you no longer get distances with your search results.

So what you're seeing is "not a bug, it's a feature". It's a feature that isn't without its tradeoffs, but I felt (and the Sunspot community largely agreed) that the tradeoffs were worth getting good performance at scale; relying only on core Solr features; and gaining the ability to mix fulltext and spatial considerations when scoring results.

Mat

Reply all
Reply to author
Forward
0 new messages