Hello David,
thanks for your answer. In the meantime I found the memory hint too in
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#Sorting_and_RelevancySo
Maybe we switch to LatLonType for this kind of searches. But the RPT is also
needed as we want to support search by arbitrary polygons.
I'm also able to use the sort=geodist() asc. This works well when I modify the
parameters to:
q=*:*&fq=typ:strasse&fq={!geofilt}&sfield=geometry&pt=51.370570625523,12.369290471603&d=1.0&sort=geofilt()
asc
Kind regards,
Dirk
Tue, 24 Feb 2015 19:42:03 GMT, david.w.smi...@gmail.com> wrote:
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
>
>
