Hi Dirk,
The RPT field type can be used for distance sorting/boosting but it’s a
memory pig when used as-such so don’t do it unless you have to. You only
have to if you have a multi-valued point field. If you have single-valued,
use LatLonType specifically for distance sorting.
Your sample query doesn’t parse correctly for multiple reasons. You can’t
put a query into the sort parameter as you have done it. You have to do
sort=query($sortQuery) asc&sortQuery=… or a slightly different equivalent
variation. Lets say you do that… still, I don’t recommend this syntax when
you simply want distance sort — just use geodist(), as in: sort=geodist()
asc.
If you want to use this syntax such as to sort by recipDistance, then it
would look like this (note the filter=false hint to the spatial query
parser, which otherwise is unaware it shouldn’t bother actually
search/filter):
sort=query($sortQuery) desc&sortQuery={!geofilt score=recipDistance
filter=false sfield=geometry pt=51.3,12.3 d=1.0}
If you are able to use geodist() and still find it slow, there are
alternatives involving using projected data and then with simply euclidean
calculations, sqedist():
https://wiki.apache.org/solr/FunctionQuery#sqedist_-_Squared_Euclidean_Distance
~ David Smiley
Freelance Apache Lucene/Solr Search Consultant/Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Feb 24, 2015 at 6:12 AM, <dirk.thalh...@bkg.bund.de> wrote:
> Hello,
>
> we are using solr 4.10.1. There are two cores for different use cases with
> around 20 million documents (location descriptions) per core. Each document
> has a geometry field which stores a point and a bbox field which stores a
> bounding box. Both fields are defined with:
> <fieldType name="t_geometry"
> class="solr.SpatialRecursivePrefixTreeFieldType"
>
>
> spatialContextFactory="com.spatial4j.core.context.jts.JtsSpatialContextFactory"
> geo="true" distErrPct="0.025" maxDistErr="0.00009"
> units="degrees" />
>
> I'm currently trying to add a location search (find all documents around a
> point). My intention is to add this as filter query, so that the user is
> able to do an additional keyword search. These are the query parameters so
> far:
> q=*:*&fq=typ:strasse&fq={!geofilt sfield=geometry
> pt=51.370570625523,12.369290471603 d=1.0}
> To sort the documents by their distance to the requested point, I added
> following sort parameter:
> sort={!geofilt sort=distance sfield: geometry
> pt=51.370570625523,12.369290471603 d=1.0} asc
>
> Unfortunately I'm experiencing here some major performance/memory
> problems. The first distance query on a core takes over 10 seconds. In my
> first setup the same request to the second core completely blocked the
> server and caused an OutOfMemoryError. I had to increase the memory to 16
> GB and now it seems to work for the geometry field. Anyhow the first
> request after a server restart takes some time and when I try it with the
> bbox field after a requested on the geometry field in both cores, the
> server blocks again.
>
> Can anyone explain why the distance needs so much memory? Can this be
> optimized?
>
> Kind regards,
>
> Dirk
>
>
